Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Joseph S. Myers" <joseph@codesourcery.com>
To: Nick Clifton <nickc@redhat.com>
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
Date: Fri, 06 Jul 2007 20:21:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.64.0707062010110.1118@digraph.polyomino.org.uk> (raw)
In-Reply-To: <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


  parent reply	other threads:[~2007-07-06 20:21 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-06 18:06 Nick Clifton
2007-07-06 18:25 ` Mark Kettenis
2007-07-06 18:34   ` Daniel Jacobowitz
2007-07-06 19:36     ` Joel Brobecker
2007-07-06 20:55       ` Daniel Jacobowitz
2007-07-09  9:47         ` Nick Clifton
2007-07-09 17:25           ` Joel Brobecker
2007-07-06 20:21 ` Joseph S. Myers [this message]
2007-07-06 20:31   ` DJ Delorie
2007-07-09 13:59     ` Alexandre Oliva
2007-07-06 20:51   ` Mike Stump
2007-07-06 21:11     ` Mark Mitchell
2007-07-09 13:23       ` Alexandre Oliva
2007-07-09 15:11         ` Gerald Pfeifer
2007-07-09 16:41           ` Alexandre Oliva
2007-07-09 17:06             ` Corinna Vinschen
2007-07-09 17:56               ` Alexandre Oliva
2007-07-09 19:45                 ` Corinna Vinschen
2007-07-06 21:12   ` Russ Allbery
2007-07-11  1:56 ` Geoffrey Keating
2007-07-12 10:14   ` Nick Clifton
2007-07-12 10:16     ` Nick Clifton
2007-07-12 11:00     ` Geoffrey Keating
2007-07-12 11:30       ` Nick Clifton
2007-07-12 11:33         ` Andrew Haley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0707062010110.1118@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=binutils@sourceware.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=nickc@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox