This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Changing top level files and include/ files over to GPLv3


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]