This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Changing top level files and include/ files over to GPLv3
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, gdb-patches at sourceware dot org, binutils at sourceware dot org
- Date: Fri, 6 Jul 2007 20:21:25 +0000 (UTC)
- Subject: Re: Changing top level files and include/ files over to GPLv3
- References: <m3lkdtque7.fsf@redhat.com>
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
<http://sourceware.org/ml/binutils/2007-07/msg00057.html> sooner rather
than later. With regard to Ian's comment
<http://sourceware.org/ml/binutils/2007-07/msg00065.html>, 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