From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29769 invoked by alias); 22 Sep 2009 14:31:19 -0000 Received: (qmail 29726 invoked by uid 22791); 22 Sep 2009 14:31:19 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (80.101.103.228) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 Sep 2009 14:31:14 +0000 Received: from springer.wildebeest.org ([192.168.1.34]) by gnu.wildebeest.org with esmtp (Exim 4.63) (envelope-from ) id 1Mq6Oa-0000Yk-US; Tue, 22 Sep 2009 16:31:09 +0200 Subject: Re: [ANNOUNCEMENT] GDB 7.0 release process created From: Mark Wielaard To: Jonas Maebe Cc: Jim Ingham , gdb@sourceware.org In-Reply-To: <92D837F2-68E5-45E8-AB54-F133E7DB2CCA@elis.ugent.be> References: <20090920143231.GQ7961@adacore.com> <8ac60eac0909200802m45f2675epa6e56001af4b491@mail.gmail.com> <20090920152741.GR7961@adacore.com> <8ac60eac0909200914g39a2d471j601aebd995da1d02@mail.gmail.com> <20090920171154.GT7961@adacore.com> <20090920173607.GA18628@bromo.med.uc.edu> <8ac60eac0909201137h3b357f95hc9471ed186575c06@mail.gmail.com> <20090921043410.GA25454@adacore.com> <20090921125654.GA30075@bromo.med.uc.edu> <3D48AF75-6E1F-401C-8411-8388B7D893B9@elis.ugent.be> <20090921134617.GA30967@bromo.med.uc.edu> <187A0C0A-28B7-4A51-BE99-47C0F650C1F8@apple.com> <1253624335.20668.32.camel@springer.wildebeest.org> <92D837F2-68E5-45E8-AB54-F133E7DB2CCA@elis.ugent.be> Content-Type: text/plain Date: Tue, 22 Sep 2009 14:31:00 -0000 Message-Id: <1253629868.20668.42.camel@springer.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00288.txt.bz2 On Tue, 2009-09-22 at 15:29 +0200, Jonas Maebe wrote: > On 22 Sep 2009, at 14:58, Mark Wielaard wrote: > > > If the gdb binary as conveyed to the user depends on being > > codesigned by > > a particular authorization key, then that should be part of the > > corresponding source code that the user receives. So then the signing > > authorization keys would be available for any rebuild gdb binary that > > the user creates. > > Isn't that only as of GPLv3 and later? (the whole "Installation > Information" discussion) Apple's gdb is based on an old (GPLv2) fork. You would have to aks FSF legal for details of whether not offering part of the corresponding source code is allowed under GPLv2 vs GPLv3. But it seems obvious to me that if you cannot build a functionally equivalent working binary from the sources as provided, then you are not in compliance of offering the complete source code of the executable work. So I would assume the requirement to provide it to the user is equivalent under both versions. The GPLv3 text just makes it a bit more explicit that this is the intent it seems. Cheers, Mark