From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31092 invoked by alias); 1 Mar 2011 21:19:34 -0000 Received: (qmail 30919 invoked by uid 22791); 1 Mar 2011 21:19:33 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 01 Mar 2011 21:19:29 +0000 Received: (qmail 15263 invoked from network); 1 Mar 2011 21:19:27 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Mar 2011 21:19:27 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [PATCH v5] sim: bfin: new port Date: Tue, 01 Mar 2011 21:19:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-25-generic; KDE/4.6.0; x86_64; ; ) Cc: Mike Frysinger References: <201011152039.08285.vapier@gentoo.org> <201102221526.45398.vapier@gentoo.org> In-Reply-To: <201102221526.45398.vapier@gentoo.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201103012119.26255.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-03/txt/msg00047.txt.bz2 Hi Mike, On Tuesday 22 February 2011 20:26:44, Mike Frysinger wrote: > --- /dev/null > +++ b/sim/bfin/linux-fixed-code.h > @@ -0,0 +1,23 @@ > +/* DO NOT EDIT: Autogenerated. */ > +/* Fixed code region of Linux userspace starting at 0x400. Last produced > + from Linux-2.6.37 (not that the fixed code region changes often). */ > +static const unsigned char bfin_linux_fixed_code[] =3D { > +0x28, 0xe1, 0xad, 0x00, 0xa0, 0x00, 0x00, 0x20, (...) > +0xa4, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > +}; I was surprised to still see a binary blob in the code, and though this blog was generated from a different source, I also worry about it. :-( AINAL yadda yadda. =46rom the comment, this blob in question is a dump of code from the Linux kernel. In short, you're making the gdb sources include a piece of the Linux kernel. The whole Linux kernel as a single product is GPLv2. If that was indeed extracted from a Linux kernel's binary (either from a running system or from the object code), then from my understanding it is GPLv2 as well, and retains the original copyright of the Kernel, as (sic from the GPL FAQ) 'when a program translates its input into some other form, the copyright status of the output inherits that of the input it was generated from'. This seem to make that hunk in the patch not acceptable, as GPLv2 is incompatible with GPLv3. There's then the issue that since the blob is a GPLv2 binary, to distribute/convey it, per the GPL, we'd need to be able to provide the source it's generated from as well. And any scripts/instructions necessary to regenerate the autogenerated file. (It is also my understanding that when you distribute/convey object code, you must keep copyright notices intact, and I would assume that to mean that even these generated files should carry a copyright (and license) header.) Now this kernel code in question was probably (haven't checked) largely written by ADI, and as such ADI could probably contribute a standalone version of its source to the FSF under GPLv3, along with some script or makefile that compiles it with a bfin-gcc and then generates the blob array. Or you could write simple dumb replacement implementations of the interface instead? I don't know if there's some rule or exception in the GPL that applies here, and nullifies my concerns. I'd be happy to learn about it. I think that best would be for you to contact and get an educated answer from the FSF (Cc'ing me). --=20 Pedro Alves