From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3227 invoked by alias); 15 Jan 2007 11:38:00 -0000 Received: (qmail 3218 invoked by uid 22791); 15 Jan 2007 11:37:59 -0000 X-Spam-Check-By: sourceware.org Received: from Unknown (HELO elsdt-razorfish.arc.com) (194.202.198.226) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 15 Jan 2007 11:37:53 +0000 Received: from elsdt-razorfish.arc.com (localhost.localdomain [127.0.0.1]) by elsdt-razorfish.arc.com (8.12.11.20060308/8.12.11) with ESMTP id l0FBbnSU027698 for ; Mon, 15 Jan 2007 11:37:49 GMT Received: (from joernr@localhost) by elsdt-razorfish.arc.com (8.12.11.20060308/8.12.11/Submit) id l0FBbnE3027696 for cgen@sources.redhat.com; Mon, 15 Jan 2007 11:37:49 GMT Date: Mon, 15 Jan 2007 11:38:00 -0000 From: Joern Rennecke To: cgen@sources.redhat.com Subject: copyright issues for cgen-generated tools Message-ID: <20070115113749.GA27642@elsdt-razorfish.arc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Mailing-List: contact cgen-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00004.txt.bz2 We (ARC International) are currently evaluating the feasibility of using cgen to generate simulators and binutils for the ARCompact family of cores. The desired outcome is that the gdb sim simulator and binutils will be integrated into the FSF mainline tree. I understand that the FSF will requires copyright assignments for the contributed code before such a contribution is considered for integration. Obviously, we have the right to assign the code that we have written ourselves. However, the cgen framework and cpu files that are recommended as templates to writing your own cpu file (m32r is directly recommended, and I've also found relevant bits for features not covered in m32r.cpu in arc*.cpu, sh*.cpu sparc*.cpu and xstormy.cpu) are copyright Red Hat. I'm not sure to what extend the generated files are then copyright Red Hat. The Cgen license gives permission to use cgen output beyond the permissions of the GPL, but copyright assignment to the FSF certainly does go beyond that. Also, I'm not sure if the FSF requires the cgen source code to be assigned to them. It is the preferred source code to modify, but OTOH the requirements of the GPL are fulfilled by the cgen source code being available under a matching GPL license. Have the necessary assignments already been made when previous cgen-generated ports have been contributed to gdb / binutils? There are copies of some old cgen cpu files in the sourceware.org main tree which purport to be copyright FSF, but at the same time the master copies in the cgen repository don't carry any FSF copyright notices - I don't think any one is a clean-room reimplementation, so one of the Copyright lists must be wrong (either the FSF copyright notices in the main tree are plain wrong, or the copyright notices in the cgen tree are incomplete at best). Assuming the necessary copyright assignments have been made for previous ports, will I need to use a vintage cgen version - presumably the one used for the latest contributed port - in order to take advantage of these assignments so that the ARC port can be contributed to the FSF? Or can the necessary assignments for the newer code be made by Red Hat?