From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28377 invoked by alias); 6 Jul 2007 20:21:39 -0000 Received: (qmail 28354 invoked by uid 22791); 6 Jul 2007 20:21:37 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 06 Jul 2007 20:21:29 +0000 Received: (qmail 24894 invoked from network); 6 Jul 2007 20:21:27 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Jul 2007 20:21:27 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.63) (envelope-from ) id 1I6uIv-0000Pc-S5; Fri, 06 Jul 2007 20:21:25 +0000 Date: Fri, 06 Jul 2007 20:21:00 -0000 From: "Joseph S. Myers" To: Nick Clifton cc: gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org, binutils@sourceware.org Subject: Re: Changing top level files and include/ files over to GPLv3 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: 2007-07/txt/msg00115.txt.bz2 On Fri, 6 Jul 2007, Nick Clifton wrote: > Hi Guys, > > I would like to apply a patch to change the files that are shared by > the GCC, GDB and BINUTILS projects over to version 3 of the GNU > General Public License. (ie all the top level files except for > those that have a distinct project that owns them, plus all of the > files in the include/ directory tree). > > Are there any objections to me doing this, or any reasons for > holding off for a while ? In particular I was planning to change > the text inside the toplevel COPYING file to that of the GPLv3, so > that would mean that any file currently released under GPLv2 and > saying "see the file COPYING" would now be out of sync. Changing libiberty, which is shared between projects, would have the effect of changing all projects using it (bearing in mind that parts of libiberty are under the GPL and parts under the LGPL, and both should probably be updated at once). As such I suppose the copies of licences in the manuals should be updated when the common files are updated. In the GCC tree this means gcc/doc/include/gpl.texi and libiberty/copying-lib.texi. The former is *not* a direct copy of the standard FSF gpl.texi, it has local Texinfo changes to facilitate generating a gpl.7 manpage - and those must be merged in rather than discarded when gpl.texi is updated. There are six copies of COPYING and four of COPYING.LIB in the GCC tree. Of these, libjava/classpath/COPYING and libjava/libltdl/COPYING.LIB appear to come from imported components maintained elsewhere, and therefore should be updated as part of updates of those components from upstream. Fortunately --version output says "see the source for copying conditions" and so doesn't need to be changed. I do hope the FSF answer the backporting question sooner rather than later. With regard to Ian's comment , I think the issue is not so much backports to FSF release branches where it would be the FSF releasing under the licence of the old branch, as backports to the many different branches used by everyone distributing their own packaged stable versions of GPL free software. -- Joseph S. Myers joseph@codesourcery.com