RFH: GPLv3

[Mark Mitchell]

The GCC SC is still discussing a few of the finer points of the
transition to GPLv3.

However, here are the things that have now been decided:

1. The compiler proper (e.g., files used only in cc1, cc1plus, the
driver, etc.) should all be converted to GPLv3 ASAP.

Will someone (or someones) please volunteer to change the various files
that mention GPLv2 to mention GPLv3 instead, to change the COPYING file
in the gcc/ directory, and to look for other things that need to change?

2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit
backports from mainline to GCC 4.2.1, if necessary, to be downlicensed
to GPLv2, as part of that release.

3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.

It has not yet been decided what to do about files that are part of
run-time libraries and are covered by GPL/LGPL + exception. Therefore,
no changes to

It has also not yet been decided whether backports of bug-fixes from
GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1)
will result in the patched compilers being GPLv3. If you have thoughts
about that, you might wish to contact the FSF.

Thanks,

[Gabriel Dos Reis]

Mark Mitchell <***@codesourcery.com> writes:

| The GCC SC is still discussing a few of the finer points of the
| transition to GPLv3.

Thanks for the update!


[...]

| 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
| What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
| emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.

What a mess! (Sorry). Was the option of closing the GCC-4.2.x branch
considered, instead of releasing GCC-4.2.2 as GCC-4.3.2?

[...]

| It has also not yet been decided whether backports of bug-fixes from
| GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1)

We can make a final release from GCC-4.1.x and close it definitely.
We should strive for some kind of mononiticy in terms of release
series and licensing.

-- Gaby

[Richard Guenther]

Post by Gabriel Dos Reis
| The GCC SC is still discussing a few of the finer points of the
| transition to GPLv3.
Thanks for the update!
[...]
| 3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
| What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
| emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.
What a mess! (Sorry). Was the option of closing the GCC-4.2.x branch
considered, instead of releasing GCC-4.2.2 as GCC-4.3.2?

I agree, this looks like a mess (and it will definitely confuse users). Closing
the branch would be an option, but the tricky question what happens if
there are backports from mainline fixes to the (closed) branch as part of
vendor releases remains. (Likewise for the 4.1 branch)

I would definitely like to have a public statement from the FSF on this issue.

I suppose backporting your own fixes is a no-brainer, as you don't lose the
rights to re-license your own contributions, but without an official statement
from the FSF there will be still a lot of confusion on this issue.

Post by Gabriel Dos Reis
| It has also not yet been decided whether backports of bug-fixes from
| GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1)
We can make a final release from GCC-4.1.x and close it definitely.
We should strive for some kind of mononiticy in terms of release
series and licensing.

We can just close the branch. Though I expect vendors to continue to need
to maintain it for another 5+ years. Maybe we can get mutual agreement
from contributors to re-license their contributions to currently active branches
under GPL v2 as well and this way side-stepping the FSF on this matter.

Richard.

[Benjamin Smedberg]

Post by Richard Guenther

Post by Gabriel Dos Reis
| It has also not yet been decided whether backports of bug-fixes from
| GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1)
We can make a final release from GCC-4.1.x and close it definitely.
We should strive for some kind of mononiticy in terms of release
series and licensing.

We can just close the branch. Though I expect vendors to continue to need
to maintain it for another 5+ years. Maybe we can get mutual agreement
from contributors to re-license their contributions to currently active branches
under GPL v2 as well and this way side-stepping the FSF on this matter.

This sounds ideal, but I'm concerned a little bit about how this interacts
with the copyright assignment to FSF. When a contributor assigns copyright
to FSF, do they still have the right to license their changes separately?

- --BDS

- --

Benjamin Smedberg
Platform Guru
Mozilla Corporation
***@smedbergs.us
http://benjamin.smedbergs.us/

[Richard Kenner]

Post by Benjamin Smedberg
This sounds ideal, but I'm concerned a little bit about how this interacts
with the copyright assignment to FSF. When a contributor assigns copyright
to FSF, do they still have the right to license their changes separately?

Yes.

[Nick Clifton]

Hi Mark,

Post by Mark Mitchell
Will someone (or someones) please volunteer to change the various files
that mention GPLv2 to mention GPLv3 instead, to change the COPYING file
in the gcc/ directory, and to look for other things that need to change?

I volunteer.

Post by Mark Mitchell
It has not yet been decided what to do about files that are part of
run-time libraries and are covered by GPL/LGPL + exception. Therefore,
no changes to

to what ? :-) I assume that there is a missing part of that last
sentence which reads "these files will take place at the moment".

I think however that a small change to such files may be necessary. If
I change the contents of the COPYING file over to GPLv3, then I think
that it might be wise to create a new file - COPYING_v2 - which contains
the GPLv2 and which can be referred to in the copyright notice of files
which are still under the GPLv2.

Post by Mark Mitchell
It has also not yet been decided whether backports of bug-fixes from
GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1)
will result in the patched compilers being GPLv3. If you have thoughts
about that, you might wish to contact the FSF.

This is what the FSF had to say when I raised this issue with them for
the binutils project:

: Since the previous releases were licensed under GPLv2 or later, all
: maintainers need to do is upgrade their backport to GPLv3 or later --
: then they'll be able to incorporate patches that were never released
: under GPLv2.

Cheers
Nick

[Mark Mitchell]

Post by Nick Clifton
Hi Mark,

Post by Mark Mitchell
Will someone (or someones) please volunteer to change the various files
that mention GPLv2 to mention GPLv3 instead, to change the COPYING file
in the gcc/ directory, and to look for other things that need to change?

I volunteer.

Thank you!

Post by Nick Clifton

Post by Mark Mitchell
It has not yet been decided what to do about files that are part of
run-time libraries and are covered by GPL/LGPL + exception. Therefore,
no changes to

to what ? :-) I assume that there is a missing part of that last
sentence which reads "these files will take place at the moment".

Yes, that's correct. Sorry!

Post by Nick Clifton
I think however that a small change to such files may be necessary. If I change the contents of the COPYING file over to GPLv3, then I think that it might be wise to create a new file - COPYING_v2 - which contains the GPLv2 and which can be referred to in the copyright notice of files which are still under the GPLv2.

Good point! I'd suggest doing this first: make a COPYING_v2, then
update GPL/LGPL + exception things to point at it, then change COPYING
to v3 and update source files that say "v2 or later".

Please err on the side of caution; it will be harder to go back to V2 if
we accidentally make something V3 than it will be to go forward to V3 if
we miss something.

Thanks,

[Basile STARYNKEVITCH]

Post by Mark Mitchell
The GCC SC is still discussing a few of the finer points of the
transition to GPLv3.[...]

Good!

Here is my initial opinion on some point you asked; but please ignore it if it hurts somebody!

Post by Mark Mitchell
3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.

I find this surprising and a bit confusing! My first reaction (maybe not enough thought) is that most users don't care
much about GCC source code, only about its functionality (making an executable from C or C++ source code). I am not very
sure that a "minor" change on the GCC source code license should affect so significantly the version numbering.

Maybe it might be simpler for every one to keep the 4.2.2 number the same, while putting an emphasis in its README or
release notes about license version change.

In other words, for GCC and most of its users, the main freedom of the 4 freedoms in GPL is the right to use the GCC
compiler to compiles one's own stuff (even proprietary code). AFAIK this stays the same in GPLv2 and GPLv3.

Even if the license is changing, the ordinary user will very probably be able to mix (e.g. link) her object code
compiled by gcc-4.2.1 and her object code compiled what you call gcc-4.3.3 and what I would prefer calling gcc-4.2.2

But I am not a lawyer, nor a free license guru, so feel free to ignore my initial feelings on this. Do what you feel
best and a big thanks for your work!

Regards

[Doug Gregor]

Post by Basile STARYNKEVITCH

Post by Mark Mitchell
3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.

I find this surprising and a bit confusing! My first reaction (maybe not enough thought) is that most users don't care
much about GCC source code, only about its functionality (making an executable from C or C++ source code). I am not very
sure that a "minor" change on the GCC source code license should affect so significantly the version numbering.

I had the same reaction. A new major release of GCC implies new
features and other technical enhancements, not just a new license.
Just imagine the flood of user questions and complaints when they
download GCC 4.3, expecting to find their favorite new feature that
they were told would be in GCC 4.3, and "all I got was this crummy new
license." Shouldn't we at least have some carrot with this stick?

Could we ask the SC to reconsider the change in the GCC major version
numbering for GPLv3? Or, at the very least, explain why it is
important to change the major version number for a mere license
change?

Why not just change the license on mainline for the GCC 4.3 release
(whenever it happens), and leave GCC 4.2 as the last release series
using GPLv2?

- Doug

[David Edelsohn]

Doug> Could we ask the SC to reconsider the change in the GCC major version
Doug> numbering for GPLv3? Or, at the very least, explain why it is
Doug> important to change the major version number for a mere license
Doug> change?

To avoid confusion among GCC users who do not expect a bug fix
release to introuduce a new license.

David

[Ian Lance Taylor]

Post by David Edelsohn
Doug> Could we ask the SC to reconsider the change in the GCC major version
Doug> numbering for GPLv3? Or, at the very least, explain why it is
Doug> important to change the major version number for a mere license
Doug> change?
To avoid confusion among GCC users who do not expect a bug fix
release to introuduce a new license.

To pile on after my earlier message, I would say that the change in
license does not matter at all, not even a tiny bit, for gcc *users*.
It only matters for gcc *distributors*. And I think the vastly
smaller population of gcc distributors can be reached by appropriate
use of documentation and announcements.

Whereas the change in version numbering does matter for users.

Ian

[David Edelsohn]

Ian> To pile on after my earlier message, I would say that the change in
Ian> license does not matter at all, not even a tiny bit, for gcc *users*.
Ian> It only matters for gcc *distributors*. And I think the vastly
Ian> smaller population of gcc distributors can be reached by appropriate
Ian> use of documentation and announcements.

I completely agree that the license change does not matter in
reality, but reality is different than perception. Members of the GCC SC
have received feedback from users who are concerned.

Some end users need approval from their legal department for a
change of license of their software. This means that the users may need
legal approval for a bug fix because of the license change.

Also, for example see the way that Samba is handling the license
change.

David

[Ian Lance Taylor]

Post by David Edelsohn
Ian> To pile on after my earlier message, I would say that the change in
Ian> license does not matter at all, not even a tiny bit, for gcc *users*.
Ian> It only matters for gcc *distributors*. And I think the vastly
Ian> smaller population of gcc distributors can be reached by appropriate
Ian> use of documentation and announcements.
I completely agree that the license change does not matter in
reality, but reality is different than perception. Members of the GCC SC
have received feedback from users who are concerned.

We should address that concern as much as we can, but to me it does
not follow that we should change gcc versioning in a peculiar way. I
think that will cause more confusion than it will solve.

Post by David Edelsohn
Some end users need approval from their legal department for a
change of license of their software. This means that the users may need
legal approval for a bug fix because of the license change.

As far as I can see, that is going to be true whether or not we bump
the release number. If you can explain otherwise, I would love to
hear it.

Post by David Edelsohn
Also, for example see the way that Samba is handling the license
change.

Samba is simply bumping to 3.2.0. They aren't moving from 3.0.26 to
3.2.27.

If you want to release gcc 4.2.2, and then release gcc 4.3.0 from the
gcc 4.2 branch, and make mainline gcc the eventual gcc 4.4.0, I'm on
board with that. That is easy enough to understand and not too
difficult to implement. What I'm disagreeing with is moving from gcc
4.2.2 to gcc 4.3.3.

Ian

[David Edelsohn]

Ian> Samba is simply bumping to 3.2.0. They aren't moving from 3.0.26 to
Ian> 3.2.27.

Ian> If you want to release gcc 4.2.2, and then release gcc 4.3.0 from the
Ian> gcc 4.2 branch, and make mainline gcc the eventual gcc 4.4.0, I'm on
Ian> board with that. That is easy enough to understand and not too
Ian> difficult to implement. What I'm disagreeing with is moving from gcc
Ian> 4.2.2 to gcc 4.3.3.

I agree.

Let me try to stop some confusion and accusations right here. RMS
*did not* request or specify GCC 4.3.3 following GCC 4.2.2. That was a
proposal from a member of the GCC SC. The numbering of the first GPLv3
release was not a requirement from RMS or the FSF.

David

[Mark Mitchell]

Post by David Edelsohn
Let me try to stop some confusion and accusations right here. RMS
*did not* request or specify GCC 4.3.3 following GCC 4.2.2. That was a
proposal from a member of the GCC SC. The numbering of the first GPLv3
release was not a requirement from RMS or the FSF.

I don't particularly have a dog in the version number fight.

I think it's potentially surprising to have a "bug fix release" contain
a major licensing change -- whether or not it particularly affects
users, it's certainly a big deal, as witnessed by the fact that it's at
the top of the FSF's priority list! But, if there's a clear consensus
here, I'm fine with that.

[Brooks Moses]

Post by Mark Mitchell

Post by David Edelsohn
Let me try to stop some confusion and accusations right here. RMS
*did not* request or specify GCC 4.3.3 following GCC 4.2.2. That was a
proposal from a member of the GCC SC. The numbering of the first GPLv3
release was not a requirement from RMS or the FSF.

I don't particularly have a dog in the version number fight.
I think it's potentially surprising to have a "bug fix release" contain
a major licensing change -- whether or not it particularly affects
users, it's certainly a big deal, as witnessed by the fact that it's at
the top of the FSF's priority list! But, if there's a clear consensus
here, I'm fine with that.

It may be worth pointing out that this is going to happen anyway on the
distributed versions, if there are vendors still providing 4.1 (or 4.0)
with backported patches.

Better, IMHO, to have the FSF address the surprise rather than leave the
distributors to do it individually and haphazardly.

- Brooks

[Dave Korn]

Post by Ian Lance Taylor
If you want to release gcc 4.2.2, and then release gcc 4.3.0 from the
gcc 4.2 branch, and make mainline gcc the eventual gcc 4.4.0, I'm on
board with that. That is easy enough to understand and not too
difficult to implement. What I'm disagreeing with is moving from gcc
4.2.2 to gcc 4.3.3.

I agree with this sentiment. Go from 4.2.2->4.3.3 with no 4.3.{0-2}?
That's just incoherent.

cheers,
DaveK

[Janis Johnson]

Post by Ian Lance Taylor
If you want to release gcc 4.2.2, and then release gcc 4.3.0 from the
gcc 4.2 branch, and make mainline gcc the eventual gcc 4.4.0, I'm on
board with that. That is easy enough to understand and not too
difficult to implement. What I'm disagreeing with is moving from gcc
4.2.2 to gcc 4.3.3.

This would be similar to going from GCC 3.1.1 to GCC 3.2 when there
was a break in binary compatibility.

Janis

[Dave Korn]

Post by Janis Johnson

Post by Ian Lance Taylor
If you want to release gcc 4.2.2, and then release gcc 4.3.0 from the
gcc 4.2 branch, and make mainline gcc the eventual gcc 4.4.0, I'm on
board with that. That is easy enough to understand and not too
difficult to implement. What I'm disagreeing with is moving from gcc
4.2.2 to gcc 4.3.3.

This would be similar to going from GCC 3.1.1 to GCC 3.2 when there
was a break in binary compatibility.

Well, it would be more similar to going from 3.1.1 to 3.2.2 and never having
had a 3.2.0 or a 3.2.1 .....


cheers,
DaveK

[Janis Johnson]

Post by Dave Korn

Post by Janis Johnson

Post by Ian Lance Taylor
If you want to release gcc 4.2.2, and then release gcc 4.3.0 from the
gcc 4.2 branch, and make mainline gcc the eventual gcc 4.4.0, I'm on
board with that. That is easy enough to understand and not too
difficult to implement. What I'm disagreeing with is moving from gcc
4.2.2 to gcc 4.3.3.

This would be similar to going from GCC 3.1.1 to GCC 3.2 when there
was a break in binary compatibility.

Well, it would be more similar to going from 3.1.1 to 3.2.2 and never having
had a 3.2.0 or a 3.2.1 .....

I meant that Ian's suggestion of going from 4.2.1 to 4.3.0, instead
of to 4.3.3, is a good idea and is similar to going from 3.1.1 to 3.2.

Janis

[Doug Gregor]

Post by David Edelsohn
Doug> Could we ask the SC to reconsider the change in the GCC major version
Doug> numbering for GPLv3? Or, at the very least, explain why it is
Doug> important to change the major version number for a mere license
Doug> change?
To avoid confusion among GCC users who do not expect a bug fix
release to introuduce a new license.

I agree with Ian on this one... to users, the new license just doesn't
matter. It needs to be prominently stated in the release nodes, in the
README, etc., but it's the technical changes that matter to GCC users.

It seems obvious to me that it would be easiest to just move today's
mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. We
could then either cut off the GCC 4.2 branch entirely or leave it
GPLv2. Then there are no surprises for anyone.

- Doug

[David Edelsohn]

Doug> It seems obvious to me that it would be easiest to just move today's
Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. We
Doug> could then either cut off the GCC 4.2 branch entirely or leave it
Doug> GPLv2. Then there are no surprises for anyone.

Leaving released branches as GPLv2 is not an option. That
definitely would be the path of least surprise.

David

[Dave Korn]

Post by David Edelsohn
Doug> It seems obvious to me that it would be easiest to just move today's
Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. We
Doug> could then either cut off the GCC 4.2 branch entirely or leave it
Doug> GPLv2. Then there are no surprises for anyone.
Leaving released branches as GPLv2 is not an option.

What, even *closed* release branches?

cheers,
DaveK

[David Edelsohn]

Doug> could then either cut off the GCC 4.2 branch entirely or leave it
Doug> GPLv2. Then there are no surprises for anyone.

Post by David Edelsohn
Leaving released branches as GPLv2 is not an option.

Dave> What, even *closed* release branches?

The comment referred to GCC 4.2. GCC 4.2 branch may not remain
under GPLv2. GCC 4.1 branch may not remain under GPLv2. Closing the GCC
4.2 branch is impractical -- we must provide support until the next
feature release, currently called GCC 4.3.

Any patches backported to a release branch from mainline after
mainline is relicensed to GPLv3 will cause the branch to be subject to
GPLv3, unless the original author explicitly contributes the patch to the
branch under GPLv2.

David

[Richard Kenner]

Post by David Edelsohn
Any patches backported to a release branch from mainline after
mainline is relicensed to GPLv3 will cause the branch to be subject to
GPLv3, unless the original author explicitly contributes the patch to the
branch under GPLv2.

That doesn't seem an unreasonable requirement and if that's all that's
needed to keep the release branches under GPLv2, it seems worth the effort
to me.

[Bernd Schmidt]

Post by David Edelsohn

Post by David Edelsohn
Leaving released branches as GPLv2 is not an option.

Dave> What, even *closed* release branches?
The comment referred to GCC 4.2. GCC 4.2 branch may not remain
under GPLv2. GCC 4.1 branch may not remain under GPLv2. Closing the GCC
4.2 branch is impractical -- we must provide support until the next
feature release, currently called GCC 4.3.
Any patches backported to a release branch from mainline after
mainline is relicensed to GPLv3 will cause the branch to be subject to
GPLv3, unless the original author explicitly contributes the patch to the
branch under GPLv2.

I don't think that's true. Given that all copyrights are assigned to
the FSF, the FSF could license these changes as GPLv2+ (in 4.2) and
GPLv3+ (in 4.3 and up) without a problem. The original author's wishes
do not come into play.


Bernd

[David Edelsohn]

Bernd> I don't think that's true. Given that all copyrights are assigned to
Bernd> the FSF, the FSF could license these changes as GPLv2+ (in 4.2) and
Bernd> GPLv3+ (in 4.3 and up) without a problem. The original author's wishes
Bernd> do not come into play.

Wrong. The original author can license his or her own code to
others using different licenses.

David

[Richard Kenner]

Post by David Edelsohn
Bernd> I don't think that's true. Given that all copyrights are assigned to
Bernd> the FSF, the FSF could license these changes as GPLv2+ (in 4.2) and
Bernd> GPLv3+ (in 4.3 and up) without a problem. The original author's
Bernd> wishes do not come into play.
Wrong. The original author can license his or her own code to
others using different licenses.

Yes, but the claim was somewhat the opposite: since any assignments on
file were done when GPLv2 was current, one could argue that the author
has ALREADY consented to release their code under both GPLv2 and GPLv3
without any further approval.

I agree with that as well, but also see the point that once the patch has
been placed into a GPLv3 file, it's quite unclear what license would
result from a "backport" of the patch: in some sense, you'd have to start
from the original (GPLv2) patch and apply it to the branch rather than a
more conventional "backport". What a mess!

[Michael Eager]

Post by David Edelsohn
Bernd> I don't think that's true. Given that all copyrights are assigned to
Bernd> the FSF, the FSF could license these changes as GPLv2+ (in 4.2) and
Bernd> GPLv3+ (in 4.3 and up) without a problem. The original author's wishes
Bernd> do not come into play.
Wrong. The original author can license his or her own code to
others using different licenses.

Under the license assignment, both FSF and the author can
license the code under different licenses.

[David Edelsohn]

Bernd> I don't think that's true. Given that all copyrights are assigned to
Bernd> the FSF, the FSF could license these changes as GPLv2+ (in 4.2) and
Bernd> GPLv3+ (in 4.3 and up) without a problem. The original author's wishes
Bernd> do not come into play.

Quoting RMS:

"...I recognize that author of a bug fix can make it available under
GPLv2...."

David

[Daniel Jacobowitz]

I don't think that's true. Given that all copyrights are assigned to the FSF,
the FSF could license these changes as GPLv2+ (in 4.2) and GPLv3+ (in 4.3 and
up) without a problem. The original author's wishes do not come into play.

I believe the key point here is that the FSF does not wish to do so.

[Dave Korn]

Post by Dave Korn

Post by David Edelsohn
Doug> It seems obvious to me that it would be easiest to just move today's
Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3.
We Doug> could then either cut off the GCC 4.2 branch entirely or leave it
Doug> GPLv2. Then there are no surprises for anyone.
Leaving released branches as GPLv2 is not an option.

What, even *closed* release branches?

I've just read that again. I guess you're saying that option b) is not an
option so cutting it off would be a necessity. Pardon the noise.

cheers,
DaveK

[Benjamin Smedberg]

Post by David Edelsohn
Doug> It seems obvious to me that it would be easiest to just move today's
Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. We
Doug> could then either cut off the GCC 4.2 branch entirely or leave it
Doug> GPLv2. Then there are no surprises for anyone.
Leaving released branches as GPLv2 is not an option. That
definitely would be the path of least surprise.

Why is it not an option?

- --BDS

- --

Benjamin Smedberg
Platform Guru
Mozilla Corporation
***@smedbergs.us
http://benjamin.smedbergs.us/

[David Edelsohn]

Doug> It seems obvious to me that it would be easiest to just move today's
Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. We
Doug> could then either cut off the GCC 4.2 branch entirely or leave it
Doug> GPLv2. Then there are no surprises for anyone.

Post by David Edelsohn
Leaving released branches as GPLv2 is not an option. That
definitely would be the path of least surprise.

Ben> Why is it not an option?

Because the FSF says it is not an option. The FSF holds the
copyright and decides on the licensing.

David

[Richard Kenner]

Post by David Edelsohn
Because the FSF says it is not an option. The FSF holds the
copyright and decides on the licensing.

True, but RMS has been known to change his mind when people point out to him
the consequences of a decision.

[David Edelsohn]

Post by David Edelsohn
Because the FSF says it is not an option. The FSF holds the
copyright and decides on the licensing.

Richard> True, but RMS has been known to change his mind when people point out to him
Richard> the consequences of a decision.

The GCC SC has not been able to persuaded RMS so far.

David

[Benjamin Smedberg]

Post by David Edelsohn
Doug> It seems obvious to me that it would be easiest to just move today's
Doug> mainline over to GPLv3, and have every GCC release >= 4.3 be GPLv3. We
Doug> could then either cut off the GCC 4.2 branch entirely or leave it
Doug> GPLv2. Then there are no surprises for anyone.

Post by David Edelsohn
Leaving released branches as GPLv2 is not an option. That
definitely would be the path of least surprise.

Ben> Why is it not an option?
Because the FSF says it is not an option. The FSF holds the
copyright and decides on the licensing.

Obviously the FSF can relicense any code they want to GPL3... that doesn't
mean that this community couldn't decide to only accept patches to the
GCC4.2 branch that are licensed under the GPL2+.

- --BDS

- --

Benjamin Smedberg
Platform Guru
Mozilla Corporation
***@smedbergs.us
http://benjamin.smedbergs.us/

[Alexandre Oliva]

Post by Benjamin Smedberg
Obviously the FSF can relicense any code they want to GPL3... that doesn't
mean that this community couldn't decide to only accept patches to the
GCC4.2 branch that are licensed under the GPL2+.

This wouldn't change the fact that any upcoming release of GCC issued
by the FSF ought to be under GPLv3.

But yes, people could still backport patches into their own GPLv2
releases given the policy above. But having backporters ask for
permission from the authors or from the FSF sounds like a good
incentive for them to switch to GPLv3 to avoid the hassle.

[Gabriel Dos Reis]

David Edelsohn <***@watson.ibm.com> writes:

| >>>>> Doug Gregor writes:
|
| Doug> Could we ask the SC to reconsider the change in the GCC major version
| Doug> numbering for GPLv3? Or, at the very least, explain why it is
| Doug> important to change the major version number for a mere license
| Doug> change?
|
| To avoid confusion among GCC users who do not expect a bug fix
| release to introuduce a new license.

then, let's close the tree. It is far less confusing than the
proposed renaming scheme.

-- Gaby

[Dave Korn]

Post by Doug Gregor

Post by Basile STARYNKEVITCH

Post by Mark Mitchell
3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.

I find this surprising and a bit confusing! My first reaction (maybe not
enough thought) is that most users don't care much about GCC source code,
only about its functionality (making an executable from C or C++ source
code). I am not very sure that a "minor" change on the GCC source code
license should affect so significantly the version numbering.

I had the same reaction. A new major release of GCC

Ok, hadn't you better both stop right there. "Major" release?
"significantly" affect the version numbering? We're going from 4.2 to 4.3.
That's the MINOR release number that's changing.


cheers,
DaveK

[Doug Gregor]

Post by Dave Korn

Post by Doug Gregor
I had the same reaction. A new major release of GCC

Ok, hadn't you better both stop right there. "Major" release?
"significantly" affect the version numbering? We're going from 4.2 to 4.3.
That's the MINOR release number that's changing.

*Sigh*

We could haggle over terminology, and while you are technically right,
you've side-stepped the point.

Each GCC release series changes either the minor or the major version
number, but to users the effect is the same. New features come in, old
features are changed/fixed/deprecated/removed, and there is some
porting effort involved that is not there when the subminor/patchlevel
version changes within a release series. For C++ programmers, the
"minor" release of GCC 3.4 was a major porting effort, while the
"major" release of GCC 4.0 didn't affect their code much because most
of that work was in the middle-end that users don't see.

Hence, from a GCC user's perspective, each new release series is a
"major" release, because it indicates that things are going to change,
and they are probably going to have to port their code, retest, re-run
benchmarks, etc. That's "major" to them (us).

So, feel free to re-read my note from the perspective that a "major"
release is something that has an impact on users, and "minor" is
something that typically does not. But, please, let's not haggle over
terminology.

- Doug

[Basile STARYNKEVITCH]

Post by Dave Korn

Post by Doug Gregor

Post by Basile STARYNKEVITCH

Post by Mark Mitchell
3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.

I find this surprising and a bit confusing! My first reaction (maybe not
enough thought) is that most users don't care much about GCC source code,
only about its functionality (making an executable from C or C++ source
code). I am not very sure that a "minor" change on the GCC source code
license should affect so significantly the version numbering.

I had the same reaction. A new major release of GCC

Ok, hadn't you better both stop right there. "Major" release?
"significantly" affect the version numbering? We're going from 4.2 to 4.3.
That's the MINOR release number that's changing.

Agreed, but I believe remembering that linking object code compiled from C++ source by gcc-4.0 with object code compiled
from C++ source by gcc-4.1 (or maybe it was 4.1 & 4.2) failed in some corner cases. But perhaps my memory is wrong and I
might be confusing with gcc-3.4 vs gcc-4.0.

If all object code compiled by same major (but different minor) version of GCC is expected to be and almost always has
been compatible in the past (e.g. gcc-3.2 vs gcc-3.3 for example, or gcc-4.0 vs gcc-4.1) I retract my comment.

Still, I do believe that almost all my distant colleagues from CEA http://www.cea.fr/ (notably compiling their numerical
code for e.g. nuclear, astronomical or thermodynamical numerical computations) will find funny a version number change
from 4.2 to 4.2 only for the compiler license change. Most of them don't care about GPLv2 vs GPLv3 for the compiler,
they just want to compile their (sadly proprietary) numerical code (in Fortran or C++).

IMHO the only persons who really care about GPLv2 vs GPLv3 are open-source enthusiasts (and active open-source
contributors). Unfortunately, they are probably a minority in the huge set of GCC users: I believe that in all the
gcc-4.1 processes on the entire Earth which have been running yesterday july 11th 2007 from 0:00GMT to 23:59GMT, most of
them has been -on that day- compiling proprietary code, and even more of them don't care about the GPLv2 to GPLv3 change
in the GCC compiler, and won't understand a 4.2.2 -> 4.3.3 version string transition.

Very few of the developers I know which are using Linux and GCC are paid to develop open-source applications. Almost
everyone is compiling proprietary applications with GCC.

But I understand it is a very political trade-off to decide about GCC versioning scheme, so I leave it to people who
know. But since Mark Mitchell gently asked, I just gave my uninformed opinion, and I praise him and the whole SC for the
GPLv2 -> GPLv3 transition (which very probably means a lot of work for them).

Regards.

[Ian Lance Taylor]

Post by Mark Mitchell
2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit
backports from mainline to GCC 4.2.1, if necessary, to be downlicensed
to GPLv2, as part of that release.

I believe that we should make a clear statement with that release that
any future backport from a later gcc release requires relicensing the
changed files to be GPLv3 or later. I believe this is consistent with
the two different licensing requirements, and I believe it is feasible
if inconvenient for vendors who distribute patched gcc releases.

Post by Mark Mitchell
3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.

That seems really really confusing. I appreciate that the SC is
facing contradictory requirements. But I think there must be a better
solution. Moving from 4.2.1 to 4.3.3 will have us writing
explanations to users and distributors for the next five years.

My personal preference would be to acknowledge that for our users
there is no significant difference between GPLv2 and GPLv3. And we
should acknowledge that people backporting patches from later releases
are already going to have to relicense to GPLv3. Therefore, we should
simply change gcc 4.2.2 to be GPLv3. This is a lot of churn on the
branch, and I wish it were unnecessary, but presumably the FSF
requires it. I think that choice is the lesser evil.

The only people who may be discomfited by that choice are distributors
of gcc who are unwilling to distribute code licensed under GPLv3. But
for those people, renaming gcc 4.2.2 to gcc 4.3.3 will not help them
in any meaningful way. I think it will suffice to clearly announce
the licensing change in the documentation and announcements for both
gcc 4.2.1 (under GPLv2) and gcc 4.2.2 (under GPLv3).

And, of course, we should help any concerned distributors to
understand that, for gcc, GPLv3 does not impose any requirements that
were not already implicitly present in GPLv2. (I personally only know
of one potentially recalcitrant distributor, and, again, renaming gcc
4.2.2 to gcc 4.3.3 will not help them.)

Post by Mark Mitchell
It has not yet been decided what to do about files that are part of
run-time libraries and are covered by GPL/LGPL + exception. Therefore,
no changes to

I find this truncated sentence to be slightly ominous as I believe
there is only one plausible choice for those files: we must convert
them to be GPLv3/LGPLv3 + exception, where the exception is identical
or equivalent to the current one. Adding any restrictions to the
licensing of those files will cost us a significant portion of our
user base.

Post by Mark Mitchell
It has also not yet been decided whether backports of bug-fixes from
GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1)
will result in the patched compilers being GPLv3. If you have thoughts
about that, you might wish to contact the FSF.

I believe it will result in the patched compilers being GPLv3, and I
believe that is acceptable if inconvenient. If the FSF will grant a
dispensation here, that would be clearly helpful. But any such
dispensation would have to avoid opening a huge licensing hole for
anybody who wants to stick to GPLv2, to prevent them from simply
building a permanent branch of gcc 4.1 and backporting and relicensing
all future gcc changes.

Ian

[Richard Kenner]

Post by Ian Lance Taylor
My personal preference would be to acknowledge that for our users
there is no significant difference between GPLv2 and GPLv3.

I agree with this. I think renaming 4.2.2 to 4.3.3 will result in
lots of unnecessary confusion.

[Diego Novillo]

Post by Richard Kenner

Post by Ian Lance Taylor
My personal preference would be to acknowledge that for our users
there is no significant difference between GPLv2 and GPLv3.

I agree with this. I think renaming 4.2.2 to 4.3.3 will result in
lots of unnecessary confusion.

Likewise. As was suggested on IRC, we could append a letter to the
version number (say 4.2.2G) or something distinctive, but don't skip
version numbers in such an odd way.

It will be confusing and will give us no end of support headaches.

[Brooks Moses]

Post by Diego Novillo

Post by Richard Kenner

Post by Ian Lance Taylor
My personal preference would be to acknowledge that for our users
there is no significant difference between GPLv2 and GPLv3.

I agree with this. I think renaming 4.2.2 to 4.3.3 will result in
lots of unnecessary confusion.

Likewise. As was suggested on IRC, we could append a letter to the
version number (say 4.2.2G) or something distinctive, but don't skip
version numbers in such an odd way.

I would very much agree with this, if it's possible. 4.2.2_GPLv3, perhaps?

This would also allow another release or two from the 4.1 branch, rather
than making the decision to close it prematurely for notational reasons.

- Brooks

[Basile STARYNKEVITCH]

Post by Brooks Moses

Post by Diego Novillo

Post by Richard Kenner

Post by Ian Lance Taylor
My personal preference would be to acknowledge that for our users
there is no significant difference between GPLv2 and GPLv3.

I agree with this. I think renaming 4.2.2 to 4.3.3 will result in
lots of unnecessary confusion.

Likewise. As was suggested on IRC, we could append a letter to the
version number (say 4.2.2G) or something distinctive, but don't skip
version numbers in such an odd way.

I would very much agree with this, if it's possible. 4.2.2_GPLv3, perhaps?

I very much agree with this.

Also (and I am too young to know) how (and when and if) was the GPLv1 -> GPLv2 transition handled? Or is GCC older than
GPLv1 (I am just asking, maybe past history could help).

[Ian Lance Taylor]

Post by Basile STARYNKEVITCH
Also (and I am too young to know) how (and when and if) was the GPLv1
-> GPLv2 transition handled? Or is GCC older than GPLv1 (I am just
asking, maybe past history could help).

I believe gcc 2.0 was the first GPLv2 version of gcc. There were
other significant changes, mainly in the area of supporting RISC
processors, so the change in major version number was reasonable
anyhow.

There were no release branches back then, so there was no major issue
with the transition.

Ian

[Michael Eager]

Post by Ian Lance Taylor

Post by Mark Mitchell
2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit
backports from mainline to GCC 4.2.1, if necessary, to be downlicensed
to GPLv2, as part of that release.

I believe that we should make a clear statement with that release that
any future backport from a later gcc release requires relicensing the
changed files to be GPLv3 or later. I believe this is consistent with
the two different licensing requirements, and I believe it is feasible
if inconvenient for vendors who distribute patched gcc releases.

If I understand you, that means that backporting a fix from gcc-4.4
to gcc-3.4 would suddenly make everything in gcc-3.4 fall under GPLv3.

I understand that you may be talking about public branches, but
there are (many) people who are currently using and maintaining
previous releases. The same rules would apply equally to private
backports of patches.

This would be chaotic. Acme Co's version of gcc-3.4 might be GPLv2
while MegaCorp's gcc-3.4 might be GPLv3.

Post by Ian Lance Taylor
My personal preference would be to acknowledge that for our users
there is no significant difference between GPLv2 and GPLv3. And we
should acknowledge that people backporting patches from later releases
are already going to have to relicense to GPLv3.

That's going to stop all private development until corporate legal
folks get into sync with GPLv3.

Post by Ian Lance Taylor
The only people who may be discomfited by that choice are distributors
of gcc who are unwilling to distribute code licensed under GPLv3.

And anyone using any past release.

[Ian Lance Taylor]

Post by Michael Eager

Post by Ian Lance Taylor

Post by Mark Mitchell
2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit
backports from mainline to GCC 4.2.1, if necessary, to be downlicensed
to GPLv2, as part of that release.

I believe that we should make a clear statement with that release that
any future backport from a later gcc release requires relicensing the
changed files to be GPLv3 or later. I believe this is consistent with
the two different licensing requirements, and I believe it is feasible
if inconvenient for vendors who distribute patched gcc releases.

If I understand you, that means that backporting a fix from gcc-4.4
to gcc-3.4 would suddenly make everything in gcc-3.4 fall under GPLv3.
I understand that you may be talking about public branches, but
there are (many) people who are currently using and maintaining
previous releases. The same rules would apply equally to private
backports of patches.
This would be chaotic. Acme Co's version of gcc-3.4 might be GPLv2
while MegaCorp's gcc-3.4 might be GPLv3.

Your understanding of what I am saying is correct. I agree that this
is not ideal. However, I do not see an alternative. And you didn't
propose one. I encourage you to think of one.

That said, I don't really agree with your claim that having some
versions of gcc 3.4 under GPLv2 and some under GPLv3 will be
"chaotic." For gcc users, the licenses simply don't differ
significantly.

Post by Michael Eager

Post by Ian Lance Taylor
My personal preference would be to acknowledge that for our users
there is no significant difference between GPLv2 and GPLv3. And we
should acknowledge that people backporting patches from later releases
are already going to have to relicense to GPLv3.

That's going to stop all private development until corporate legal
folks get into sync with GPLv3.

Correct, for people who distribute gcc.

Post by Michael Eager

Post by Ian Lance Taylor
The only people who may be discomfited by that choice are distributors
of gcc who are unwilling to distribute code licensed under GPLv3.

And anyone using any past release.

Incorrect. It only matters for distributors, not users.


Again, I am just the messenger here. I would like to see a different
approach, but what could that be?

Ian

[Mark Mitchell]

Post by Ian Lance Taylor

Post by Michael Eager

Post by Ian Lance Taylor
The only people who may be discomfited by that choice are distributors
of gcc who are unwilling to distribute code licensed under GPLv3.

And anyone using any past release.

Incorrect. It only matters for distributors, not users.
Again, I am just the messenger here. I would like to see a different
approach, but what could that be?

I have suggested to RMS that the FSF allow downlicensing of backports of
GPLv3 code that met two condition: (1) the backport fixed a bug, rather
than added a feature, and (2) the backport was less than 1000 lines of
code. The point of (2) is to prevent abuse of (1). If you claim that
some great new feature is a bug fix, you still lose because it's too
big. So, you can't avoid GPLv3 by just "backporting" forever; the new
GPLv3 features will pull you forward.

I also suggested that GCC the 4.2.x branch be permitted to remain GPLv2.
But, RMS has said that GCC 4.2.1 must be the last release under GPLv2,
and that it happen before the end of July (which was the plan all
along). I don't think it's fruitful to discuss any changes to this
particular item (e.g., delaying GCC 4.2.1, releasing GCC 4.2.2 as GPLv2,
etc.); I think that RMS has made his decision.

[Richard Guenther]

Post by Mark Mitchell

Post by Ian Lance Taylor

Post by Michael Eager

Post by Ian Lance Taylor
The only people who may be discomfited by that choice are distributors
of gcc who are unwilling to distribute code licensed under GPLv3.

And anyone using any past release.

Incorrect. It only matters for distributors, not users.
Again, I am just the messenger here. I would like to see a different
approach, but what could that be?

I have suggested to RMS that the FSF allow downlicensing of backports of
GPLv3 code that met two condition: (1) the backport fixed a bug, rather
than added a feature, and (2) the backport was less than 1000 lines of
code. The point of (2) is to prevent abuse of (1). If you claim that
some great new feature is a bug fix, you still lose because it's too
big. So, you can't avoid GPLv3 by just "backporting" forever; the new
GPLv3 features will pull you forward.
I also suggested that GCC the 4.2.x branch be permitted to remain GPLv2.
But, RMS has said that GCC 4.2.1 must be the last release under GPLv2,
and that it happen before the end of July (which was the plan all
along). I don't think it's fruitful to discuss any changes to this
particular item (e.g., delaying GCC 4.2.1, releasing GCC 4.2.2 as GPLv2,
etc.); I think that RMS has made his decision.

As the 4.1 branch, while we don't expect any new releases from it, is still
open for bugfixes, can we as GCC community decide to only accept
dual-licensed (so, fine for GPL v2) patches to it? Otherwise we should
definitely close this branch.

Richard.

[Michael Eager]

Post by Ian Lance Taylor

Post by Michael Eager

Post by Ian Lance Taylor

Post by Mark Mitchell
2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit
backports from mainline to GCC 4.2.1, if necessary, to be downlicensed
to GPLv2, as part of that release.

I believe that we should make a clear statement with that release that
any future backport from a later gcc release requires relicensing the
changed files to be GPLv3 or later. I believe this is consistent with
the two different licensing requirements, and I believe it is feasible
if inconvenient for vendors who distribute patched gcc releases.

If I understand you, that means that backporting a fix from gcc-4.4
to gcc-3.4 would suddenly make everything in gcc-3.4 fall under GPLv3.
I understand that you may be talking about public branches, but
there are (many) people who are currently using and maintaining
previous releases. The same rules would apply equally to private
backports of patches.
This would be chaotic. Acme Co's version of gcc-3.4 might be GPLv2
while MegaCorp's gcc-3.4 might be GPLv3.

Your understanding of what I am saying is correct. I agree that this
is not ideal. However, I do not see an alternative. And you didn't
propose one. I encourage you to think of one.

Here's an alternative:

Since copyright is owned by FSF, they (via the steering committee)
can license them under different licenses.

Patches applied to gcc-4.<gplv3> are licensed under GPLv3.
Patches applied to previous versions are licensed under GPLv2.

I understand Daniel's comment that the FSF doesn't want to
do this, but the other way is simply chaos.

Post by Ian Lance Taylor
That said, I don't really agree with your claim that having some
versions of gcc 3.4 under GPLv2 and some under GPLv3 will be
"chaotic." For gcc users, the licenses simply don't differ
significantly.

Users include legal departments at major (and minor) corporations.

I've found myself in the curious position of explaining
patent and copyright law to lawyers, and I've even managed to
get them to agree with me on rare occasions. I can assert that
GPLv2 and GPLv3 are not substantially different, but I have little
belief that they will take my word as gospel.

I anticipate that almost every legal department will want
to review the 11 pages of the GPLv3 in detail before they
agree to distribute under that license. This is not high
on their priority list and there is no compelling reason
why they need to do this before other pressing matters.

The simple expedient is that legal departments will say
that until they have reviewed GPLv3, that only GPLv2 is
acceptable.

This makes for an interesting situation. If I develop a
patch to correct problem in a client's version of gcc, I can
apply it without problem. If I submit it to FSF (although
most of my fixes are to proprietary code, some are general),
then whether the client can use this under GPLv2 or not
depends on whether they get it directly from me or as part
of distribution from FSF.

Patches which are applied to the head which also fix
problems in prior branches would be excluded, since
they would be GPLv3.

As proposed, applying a GPLv3 patch to any earlier version
(whether on a open source branch or not) would convert that
version to GPLv3, as I read provisions of GPLv3 5.b and 5.c,
which say that the "modified work" must be distributed under
*this* license. For public branches, this means that at
some unknown time, the entire branch might be converted to
GPLv3 and any fix in that branch would become GPLv3, even if
that fix were applied months ago. I could pick up a fix on
Monday that was GPLv2, and pick up the same fix on Tuesday,
and discover (or more likely, not discover) that the same
fix was GPLv3.

I think this is a fine working definition of chaotic.

In the face of chaos, most corporations are going to simply
stop and wait for the maelstrom to subside.

Post by Ian Lance Taylor

Post by Michael Eager

Post by Ian Lance Taylor
My personal preference would be to acknowledge that for our users
there is no significant difference between GPLv2 and GPLv3. And we
should acknowledge that people backporting patches from later releases
are already going to have to relicense to GPLv3.

That's going to stop all private development until corporate legal
folks get into sync with GPLv3.

Correct, for people who distribute gcc.

All of the semiconductor companies, for instance.

Post by Ian Lance Taylor

Post by Michael Eager

Post by Ian Lance Taylor
The only people who may be discomfited by that choice are distributors
of gcc who are unwilling to distribute code licensed under GPLv3.

And anyone using any past release.

Incorrect. It only matters for distributors, not users.

Sorry, where do the users get their versions of GCC? From
distributors. Suggesting that you can make it difficult for
a distributor to apply fixes to gcc without affecting their
users is hiding the impact of the problem.

Post by Ian Lance Taylor
Again, I am just the messenger here. I would like to see a different
approach, but what could that be?

Dual licensing, where patches applied to exiting GPLv2
branches are licensed under GPLv2, and patches applied
to new branches are applied under GPLv3.

[Ian Lance Taylor]

Post by Michael Eager
Since copyright is owned by FSF, they (via the steering committee)
can license them under different licenses.
Patches applied to gcc-4.<gplv3> are licensed under GPLv3.
Patches applied to previous versions are licensed under GPLv2.

Well, we've now seen Mark's proposal along those lines. It is
apparently a non-starter with the FSF.

Post by Michael Eager
I think this is a fine working definition of chaotic.

I think that once legal teams are onboard with GPLv3, it won't be a
problem.

If they don't get onboard with GPLv3, then they are stuck with
previously released versions of gcc, and they will be forced to
develop any patches independently. That is not ideal but does not
seem to be avoidable. There are competing contradictory requirements.
The FSF owns the software, so they win. So it goes.

Post by Michael Eager
In the face of chaos, most corporations are going to simply
stop and wait for the maelstrom to subside.

Yes. From our point of view as free software developers, I believe
that will be not ideal, but acceptable. The maelstrom will subside.
It won't take more than a few months.

Ian

[Michael Eager]

Post by Ian Lance Taylor
If they don't get onboard with GPLv3, then they are stuck with
previously released versions of gcc, and they will be forced to
develop any patches independently. That is not ideal but does not
seem to be avoidable. There are competing contradictory requirements.
The FSF owns the software, so they win. So it goes.

Seems absolutely avoidable, IMO.

I'm not exactly sure what the actual requirement are,
but I don't see that they need to be contradictory.

With flexibility comes adoption of the GPLv3. With dogma
and inflexibility comes resistance.

The current plan applies the GPLv3 not just to the future releases,
but also indirectly to past releases. That may or may not have been
anticipated, but it looks like the result. That's at odds with
what I understand to be the FSF's public statements about GPLv3.

The rationale that "FSF owns the code" so "FSF dictates the rules"
is one of the least appealing aspects of this.

[I'll put away my soap box. For now.]

[Brooks Moses]

Post by Michael Eager

Post by Ian Lance Taylor
I believe that we should make a clear statement with that release that
any future backport from a later gcc release requires relicensing the
changed files to be GPLv3 or later. I believe this is consistent with
the two different licensing requirements, and I believe it is feasible
if inconvenient for vendors who distribute patched gcc releases.

If I understand you, that means that backporting a fix from gcc-4.4
to gcc-3.4 would suddenly make everything in gcc-3.4 fall under GPLv3.
I understand that you may be talking about public branches, but
there are (many) people who are currently using and maintaining
previous releases. The same rules would apply equally to private
backports of patches.
This would be chaotic. Acme Co's version of gcc-3.4 might be GPLv2
while MegaCorp's gcc-3.4 might be GPLv3.

Will, not would. This is, in practice, not an avoidable hypothetical.

The alternative would be to allow Acme Co to backport patches and leave
the code GPLv2, and if we do that, someone is going to backport enough
patches to make a version of gcc-3.4 which is entirely and completely
identical to gcc-4.4, and claim that they can distribute it as GPLv2.

Even if we were to leave the 4.1 and 4.2 branches open as GPLv2, this
problem would still happen with things that only got committed to 4.3
and later.

- Brooks

[Alexandre Oliva]

Post by Michael Eager
This would be chaotic. Acme Co's version of gcc-3.4 might be GPLv2
while MegaCorp's gcc-3.4 might be GPLv3.

This is already true today. Even if MegaCorp doesn't make any changes
to the code, the code is available under GPLv2+, which means they can
license their compiler under GPLv3+, or GPLv3 only, at their choice.

And this is a good thing.

[Serge Belyshev]

Ian Lance Taylor <***@google.com> writes:

[...]

Post by Ian Lance Taylor
My personal preference would be to acknowledge that for our users
there is no significant difference between GPLv2 and GPLv3. And we
should acknowledge that people backporting patches from later releases
are already going to have to relicense to GPLv3. Therefore, we should
simply change gcc 4.2.2 to be GPLv3. This is a lot of churn on the
branch, and I wish it were unnecessary, but presumably the FSF
requires it. I think that choice is the lesser evil.

Strongly agreed!

Personally, I think that bumping version number is the worst possible solution
of all proposed.

[Robert Dewar]

Post by Serge Belyshev
Personally, I think that bumping version number is the worst possible solution
of all proposed.

To me it seems essential to change the version number when changing the
license. Technical compiler folk may not regard the license change as a
significant one, but for the user base it is. Many companies using gcc
will not be able to move forward to gpl3 based software without their
attorneys approving the change, a process that can be time consuming.

For such companies, having a very clear notion of what is gpl2 and
what is gpl3 may be critical.

[Benjamin Kosnik]

Post by Ian Lance Taylor

Post by Mark Mitchell
It has not yet been decided what to do about files that are part of
run-time libraries and are covered by GPL/LGPL + exception.
Therefore, no changes to

I find this truncated sentence to be slightly ominous as I believe
there is only one plausible choice for those files: we must convert
them to be GPLv3/LGPLv3 + exception, where the exception is identical
or equivalent to the current one. Adding any restrictions to the
licensing of those files will cost us a significant portion of our
user base.

I see this as a less ominous development than you.

I think the issue is that the FSF may be trying to come up with a
unified GPLv3 + exception that libjava, libstdc++, libgfortran, libgcc,
etc. can all use. The current exception wording is being reviewed with
the existing GPLv3 text by lawyers.

Certainly, this would be an improvement over the current practice.

-benjamin

[Michael Eager]

Post by Mark Mitchell
The GCC SC is still discussing a few of the finer points of the
transition to GPLv3.
3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.

This seems to confabulate the meaning of version numbers to
now mean something about licensing. The difference between
4.2.1 and 4.2.2 would normally be considered a minor bug fix
release, under this scheme of calling it 4.3.3, one would be
misled to think that this is a minor bug fix for a non-existent
minor release.

The version numbering scheme correlating to functional changes
is more valuable than any (IMO insubstantial) benefit of
identifying the change in license version.

[Nicholas Nethercote]

Post by Michael Eager

Post by Mark Mitchell
3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.

This seems to confabulate the meaning of version numbers to
now mean something about licensing. The difference between
4.2.1 and 4.2.2 would normally be considered a minor bug fix
release, under this scheme of calling it 4.3.3, one would be
misled to think that this is a minor bug fix for a non-existent
minor release.
The version numbering scheme correlating to functional changes
is more valuable than any (IMO insubstantial) benefit of
identifying the change in license version.

One way to view it: the license is a feature. Therefore changing the
license is changing a feature. Therefore what was going to be 4.2.2 should
become 4.3.0.

Nick

[Robert Dewar]

Post by Nicholas Nethercote
One way to view it: the license is a feature. Therefore changing the
license is changing a feature. Therefore what was going to be 4.2.2 should
become 4.3.0.

I certainly agree that the license is a feature, and a pretty
important one for many users.

[Michael Eager]

Post by Robert Dewar

Post by Nicholas Nethercote
One way to view it: the license is a feature. Therefore changing the
license is changing a feature. Therefore what was going to be 4.2.2
should become 4.3.0.

I certainly agree that the license is a feature, and a pretty
important one for many users.

There's a saying "if you call a dog's tail a leg, how many legs
does a dog have. Four. Calling its tail a leg doesn't make it one."

Version numbers have been based on binary compatibility
and interoperability between versions.

Saying that license is an interoperability issue doesn't make it one.

[Marcus Meissner]

Post by Michael Eager

Post by Robert Dewar

Post by Nicholas Nethercote
One way to view it: the license is a feature. Therefore changing the
license is changing a feature. Therefore what was going to be 4.2.2
should become 4.3.0.

I certainly agree that the license is a feature, and a pretty
important one for many users.

There's a saying "if you call a dog's tail a leg, how many legs
does a dog have. Four. Calling its tail a leg doesn't make it one."
Version numbers have been based on binary compatibility
and interoperability between versions.
Saying that license is an interoperability issue doesn't make it one.

GPLv3+ code is however incompatible to GPLv2+ code, so it warrants
a major version bump.

Ciao, Marcus

[Robert Dewar]

Post by Michael Eager
Saying that license is an interoperability issue doesn't make it one.

No, saying that is not what makes it so, that's true.

However, the fact is that licensing *is* an interoperability issue,
since it has to do with what units can be mixed together in a
particular situation, which is what interoperability is about.

If you mix one GPLv3 unit into a GPLv2 environment, you have
a problem if you cannot tolerate GPLv3 licensing (e.g. because
your lawyers have not got around to OKaying it, or worse
because they have got around to not OKaying it). So it is
really important to understand the circumstances in which
GPLv3 is showing up.

One could of course just take a blanket view that everything
on the site is, as of a certain moment, licensed under GPLv3
(note you don't have to change file headers to achieve this,
the file headers have no particular legal significance in
any case).

That at least would be clean, and anyone concerned with
accepting GPLv3 stuff would simply know that as of this
date and time, they should no longer download ANYTHING
from the entire gnu.org site.

That's actually not so terrible, you lose some users
temporarily, but at least there is no misunderstanding.

[Richard Kenner]

One could of course just take a blanket view that everything on the
site is, as of a certain moment, licensed under GPLv3 (note you
don't have to change file headers to achieve this, the file headers
have no particular legal significance in any case).

Given the July 31 "deadline", that's essentially what's being done: any
file with a date before August 1, 2007 is GPLv2 and any after is GPLv3.
This is one of the reasons why I don't see the version number change as
so significant.

[Michael Eager]

Post by Richard Kenner

One could of course just take a blanket view that everything on the
site is, as of a certain moment, licensed under GPLv3 (note you
don't have to change file headers to achieve this, the file headers
have no particular legal significance in any case).

Given the July 31 "deadline", that's essentially what's being done: any
file with a date before August 1, 2007 is GPLv2 and any after is GPLv3.
This is one of the reasons why I don't see the version number change as
so significant.

This would be a desirable situation.

Unfortunately, as I understand it, this is not the case. If you
apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
this entire branch, and all files in it, magically and silently
becomes GPLv3. (This is unless FSF agrees with Mark's proposal
to dual license patches.)

As I understand the current situation, knowing the version number
will not tell you whether the code is licensed under GPLv2 or GPLv3.

[Robert Dewar]

Post by Michael Eager
Unfortunately, as I understand it, this is not the case. If you
apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
this entire branch, and all files in it, magically and silently
becomes GPLv3. (This is unless FSF agrees with Mark's proposal
to dual license patches.)
As I understand the current situation, knowing the version number
will not tell you whether the code is licensed under GPLv2 or GPLv3.

That's why I suggested a simple rule that ALL software on the site is
GPLv3 after a certain date, so you don't have to know the version number
or anything else, just the date on which you access the site, and if you
are GPLv3 allergic, then the simple rule is not to take ANYTHING off
the site after that date. This is really much the easiest rule.

[Michael Eager]

Post by Robert Dewar

Post by Michael Eager
Unfortunately, as I understand it, this is not the case. If you
apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
this entire branch, and all files in it, magically and silently
becomes GPLv3. (This is unless FSF agrees with Mark's proposal
to dual license patches.)
As I understand the current situation, knowing the version number
will not tell you whether the code is licensed under GPLv2 or GPLv3.

That's why I suggested a simple rule that ALL software on the site is
GPLv3 after a certain date, so you don't have to know the version number
or anything else, just the date on which you access the site, and if you
are GPLv3 allergic, then the simple rule is not to take ANYTHING off
the site after that date. This is really much the easiest rule.

I understood your suggestion.

This amounts to telling companies that they cannot upgrade their tool
chains to newer versions, or even pick up patches to old versions, until
they (and/or their legal departments) approve GPLv3.

This seems unnecessary. If you are trying to make GPLv3 more
easily adopted by companies, then this is not the way to do it.

On the other hand, perhaps I should simply agree with you.
I'll get more business supporting private tool chain development.

I have contracts with corporations to upgrade their software.
I regularly encourage them to contribute to the open source
repositories and sometimes they agree, although it usually
takes a while to convince them (management and legal departments)
that there is a benefit to this and no risk to their IP rights.

Converting previously released software to a license which they
have not yet evaluated will close these conversations. Rather
than move to later versions of the tools and being more involved
with the open source community, they will stay with their existing
privately supported tool chains. I'll get more work to fix problems
which are already fixed in later releases, but which are off limits
until the legal department gives it's OK. Once a corporation decides
that their current version of gcc is "good enough" and decides that
they will not upgrade, there will be little reason for management to
press their legal department to evaluate or approve GPLv3.

My experience is that for every company which is actively
using and developing gcc and contributes to the open source
community, I talk with many other companies who do gcc development
and follow the GPLv2 completely, but do not submit their patches
to the open source repository. There are a number of reasons
for this, including inertia, caution, secretiveness, etc. I'd
rather not give them another reason.

The result is that there are many private forks of gcc and other
development tools.

You may think that "do it my way or else" is a winning negotiating
tactic, but most of the companies I work with are quite happy to
do things on their own.

[Krzysztof Halasa]

Post by Michael Eager
Unfortunately, as I understand it, this is not the case. If you
apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
this entire branch, and all files in it, magically and silently
becomes GPLv3. (This is unless FSF agrees with Mark's proposal
to dual license patches.)

I hope the COPYING or similar file will contain the licence text
under which the code is distributed?

[Michael Eager]

Post by Krzysztof Halasa

Post by Michael Eager
Unfortunately, as I understand it, this is not the case. If you
apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
this entire branch, and all files in it, magically and silently
becomes GPLv3. (This is unless FSF agrees with Mark's proposal
to dual license patches.)

I hope the COPYING or similar file will contain the licence text
under which the code is distributed?

Not until someone updates the txt. Which should happen quickly,
but if someone applies a GPLv3 patch to a previously GPLv2 branch,
the entire branch becomes GPLv3, whether the COPYING file was
updated or not.

[Krzysztof Halasa]

Post by Michael Eager
Not until someone updates the txt. Which should happen quickly,
but if someone applies a GPLv3 patch to a previously GPLv2 branch,
the entire branch becomes GPLv3, whether the COPYING file was
updated or not.

Come on, if the FSF (the copyright holder) distributes a program,
and if the included licence says GPLv2+, then the licence is GPLv2+
and you'll have a really hard time trying to convince anyone that
it's different.

BTW: the copyright holder is free to take a GPLv3 patch and
release it under GPLv2 (and any other licence).

[Michael Eager]

Post by Krzysztof Halasa

Post by Michael Eager
Not until someone updates the txt. Which should happen quickly,
but if someone applies a GPLv3 patch to a previously GPLv2 branch,
the entire branch becomes GPLv3, whether the COPYING file was
updated or not.

Come on, if the FSF (the copyright holder) distributes a program,
and if the included licence says GPLv2+, then the licence is GPLv2+
and you'll have a really hard time trying to convince anyone that
it's different.

You asked if COPYING would be updated. The answer is not necessarily.
The COPYING text may say GPLv2+, but if there has been a GPLv3 patch
applied to the branch, then the entire branch is GPLv3.

Post by Krzysztof Halasa
BTW: the copyright holder is free to take a GPLv3 patch and
release it under GPLv2 (and any other licence).

FSF is the copyright holder. As of this time, they have said
that they are not willing to release patches under GPLv2 for
application to GPLv2 branches. Mark has a proposal which would
allow for that.

[Richard Kenner]

Post by Michael Eager
Unfortunately, as I understand it, this is not the case. If you
apply a GPLv3 patch to a previously GPLv2 branch after August 1, then
this entire branch, and all files in it, magically and silently
becomes GPLv3.

This is the key point, I think: what, PRECISELY, is a "GPLv3 patch".

I think everybody has assignments that predate GPLv3. The assignment I
signed (and I think the current assignments) don't even mention the GPL at
all, let alone a particular version of it!

So one of us writes a patch and posts it on that list. The copyright
status of that patch is that it's assigned to the FSF, which then can
"decide" what license agreement to apply to it. But, as a matter of
practice, no FSF individual is involved in the process of having that patch
be applied to the sources: it's checked in by the person who wrote it
(after possible approval, but not change, by some other person).

At what point in this process, and by what mechanism, does a patch become a
"GPLv2 patch" or a "GPLv3 patch". I'd argue that the patch itself has no
such status at all: as of the time it's posted, its copyright is owned by
the FSF, but that's all that's happened. The assignment agreement
obligates the FSF that all "distribution" of the patch should be under
GPL-like terms, but it's completely unclear as to at what point those terms
apply. For one thing, there are multiple possible licenses even ignoring
the v2 vs. v3 issue: GPL, LGPL, GPL+exception, etc.

So if you see a patch posted on an FSF mailing list, what copyright license
status does that patch have? My feeling is that as a practical matter, it's
irrelevant since the patch is a derived work from some file and the license
that applies to that file trumps any that might be viewed by some mechanism
as applying to the patch in isolation. If I'm patching an LGPLv3 file,
then my patch is a derived work from that file and so is also LGPLv3.
End of story.

So I think the discussion of a GPLv3 patch being applied to a GPLv2 file and
affecting the license of that file is somewhat backwards: the file's license
affects the patch and not vice-versa.

Where this gets tricky is indeed in a backport. Let's suppose I have two
files that differ only into which license applies. Suppose I start with
the GPLv3 version and develop a patch for it. That patch is a derived work
from GPLv3. When I apply it to the GPLv3 version of the file, nothing
changes.

Now, suppose I apply it to the GPLv2 version of the file. One could argue
that such file is now GPLv3 and I think that'd be correct. But since the
parts of the file being patched are identical, the patch is indistinguishable
from one that's derived from GPLv2 text. This strikes me as a VERY murky
legal areas.

[Brooks Moses]

Post by Robert Dewar
One could of course just take a blanket view that everything
on the site is, as of a certain moment, licensed under GPLv3
(note you don't have to change file headers to achieve this,
the file headers have no particular legal significance in
any case).

I'm going to pull a Wikipedia and call "citation needed" on that
parenthetical claim.

At the very least, the file headers are a clear representation as to
what license the file is under, and IMO a reasonable person would expect
to be able to rely on such a representation.

Thus, I think there's a reasonable argument to be made that distributing
a GCC with some file headers saying "GPLv2 or later" and some saying
"GPLv3 or later" is violating the license. The FSF is allowed to
violate their own license, since they hold the copyrights, but nobody
else is -- thus, a corrolary to that argument is that an exact copy of
such a GCC is not redistributable unless the redistributor fixes the
file headers. That would be bad.

And, regardless of whether one accepts that argument, if I were to pull
a file with a GPLv2 header out of a "GPLv3-licensed" svn and give an
exact copy of it to my friend, I would have to remember to tell her that
the file isn't licensed under what it says it's licensed under. That's
also not good.

Thus, I think it's reasonably critical that _all_ file headers be
updated, quickly, to match the state of intended license for the files
that include them.

- Brooks

[Robert Dewar]

Post by Brooks Moses

Post by Robert Dewar
One could of course just take a blanket view that everything
on the site is, as of a certain moment, licensed under GPLv3
(note you don't have to change file headers to achieve this,
the file headers have no particular legal significance in
any case).

I'm going to pull a Wikipedia and call "citation needed" on that
parenthetical claim.

Well the obvious citation is the copyright statutes themselves,
probably not a bad idea to read them!

Post by Brooks Moses
At the very least, the file headers are a clear representation as to
what license the file is under, and IMO a reasonable person would expect
to be able to rely on such a representation.

Well certainly it is good policy for headers to reflect the copyright
and licensing situation, and of course we aim at that, that goes without
saying. But no you cannot rely on this information, and a blanket
copyright statement is a way of making sure that no possible case can
arise in which someone says "but I thought this was still under the
v2 GPL". Then you work hard to make ALL headers reflect the new status.

Post by Brooks Moses
Thus, I think there's a reasonable argument to be made that distributing
a GCC with some file headers saying "GPLv2 or later" and some saying
"GPLv3 or later" is violating the license.

No, the position of the FSF (and it is a perfectly reasonable one) is
that if a file header says GPLv2 or later, it is essentially a multiple
distribution under all versions, so redistributing it as GPLv3 only
is fine. it is nice if you do this to change the header, but there is
nothing anywhere that requires this.

Post by Brooks Moses
The FSF is allowed to
violate their own license

That's a nonsense concept, there is no such thing as a license between
party A and party A, so the notion of violating it is meaningless.
Actually the whole notion of violating a license is a confused one.
The violation is of the copyright, the license merely gives some
cases in which copying is allowed. If you copy outside the license
you have not "violated" the license, you have simply infringed the
copyright, and the license is irrelevant.

Post by Brooks Moses
And, regardless of whether one accepts that argument, if I were to pull
a file with a GPLv2 header out of a "GPLv3-licensed" svn and give an
exact copy of it to my friend, I would have to remember to tell her that
the file isn't licensed under what it says it's licensed under. That's
also not good.
Thus, I think it's reasonably critical that _all_ file headers be
updated, quickly, to match the state of intended license for the files
that include them.

I don't think anyone disagreed with this, so no need to argue against
non-existent disagreement!

Post by Brooks Moses
- Brooks

[Alexandre Oliva]

Post by Nicholas Nethercote
One way to view it: the license is a feature. Therefore changing the
license is changing a feature.

Every release of GCC in the past decade (and then some) was GPLv2+.
GPLv3 has always been one of the options.

Anyone who had their heads in the sand for the past 18 months when
GPLv3 was being publicly discussed and developed, or wasn't at the GCC
Summit last year when I mentioned that the FSF would most certainly
want to upgrade the license of every project whose copyright it held
as soon as GPLv3 was ready, may indeed consider the license upgrade as
a surprising new feature.

But anyone who wanted to participate was welcome to do so, and GPLv3
shouldn't be a surprise for anyone who did, or even just watched it
from a distance.

Now, why should we weaken our defenses for the sake of those who
didn't plan for something that could have been so easily forecast 18
months ago, and that was even planned to be finished 4 months ago?
Heck, the last-call draft, published one month before the final
release, was so close to the final release that non-insider lawyers
who were on top of the process managed to emit solid opinions about
the final license the day after it was released.

It's those who didn't do their homework and didn't plan ahead for this
predictable upgrade who should be burdened now, rather than all of us
having to accept weaker defenses for our freedoms or facing additional
requirements on patches or backports. It was all GPLv2+, and this
means permission for *anyone* to upgrade to GPLv3+. The license
upgrade path is the easy path, and that's by design.

[Nicholas Nethercote]

Post by Alexandre Oliva

Post by Nicholas Nethercote
One way to view it: the license is a feature. Therefore changing the
license is changing a feature.

Every release of GCC in the past decade (and then some) was GPLv2+.
GPLv3 has always been one of the options.
Anyone who had their heads in the sand for the past 18 months when
GPLv3 was being publicly discussed and developed, or wasn't at the GCC
Summit last year when I mentioned that the FSF would most certainly
want to upgrade the license of every project whose copyright it held
as soon as GPLv3 was ready, may indeed consider the license upgrade as
a surprising new feature.
But anyone who wanted to participate was welcome to do so, and GPLv3
shouldn't be a surprise for anyone who did, or even just watched it
from a distance.
Now, why should we weaken our defenses for the sake of those who
didn't plan for something that could have been so easily forecast 18
months ago, and that was even planned to be finished 4 months ago?
Heck, the last-call draft, published one month before the final
release, was so close to the final release that non-insider lawyers
who were on top of the process managed to emit solid opinions about
the final license the day after it was released.
It's those who didn't do their homework and didn't plan ahead for this
predictable upgrade who should be burdened now, rather than all of us
having to accept weaker defenses for our freedoms or facing additional
requirements on patches or backports. It was all GPLv2+, and this
means permission for *anyone* to upgrade to GPLv3+. The license
upgrade path is the easy path, and that's by design.

I was just suggesting a rationale for choosing a version number.

Nick

[Robert Dewar]

Post by Alexandre Oliva
Anyone who had their heads in the sand for the past 18 months when
GPLv3 was being publicly discussed and developed, or wasn't at the GCC
Summit last year when I mentioned that the FSF would most certainly
want to upgrade the license of every project whose copyright it held
as soon as GPLv3 was ready, may indeed consider the license upgrade as
a surprising new feature.

Not surprising, but significant. I think you greatly underestimate the
cost and difficulty of upgrading to a new license for many large
corporate users. This means getting lawyers involved, and for sure
you don't want them wasting time tracking an 18 month period in which
the license keeps changing. So you typically would wait till the
license change was definite.

All the version number change does is signal the need for initiating
this process. Many of these users are not the kind of people who jump
to every new latest-and-greatest version quickly anyway.

Post by Alexandre Oliva
Now, why should we weaken our defenses

I am at a loss to understand this rhetoric, all we are talking
about is what version number to use, how does this "weaken
our defenses" (what defenses? against whom?).

[Alexandre Oliva]

This means getting lawyers involved, and for sure you don't want
them wasting time tracking an 18 month period in which the license
keeps changing.

Yet somehow a number of large stakeholders not only tracked the
license development over 18 months, but actually participated and
influenced it so as to meet their interests. And they somehow didn't
think of it as wasting time.

See, I'm not diminishing the importance of licensing issues, I'm just
saying it's legally irresponsible to sit back and *not* even watch
what's going on in the development of the license that a bunch of
software one is very clearly interested in, and then try to frame the
moment when the development is completed and the license is to be
adopted, as forecast throughout the process and as explicitly
permitted by the licensing practice in place for almost two decades,
as something unexpected, as a sudden major legal burden.

So you typically would wait till the license change was definite.

It seems to me that it would be saner to not only keep up with the
developments of the license, but also get one's major customers aware
of the upcoming changes, not creating false expectations as to
licensing issues. We shouldn't hold back the upgrade just because
some vendors *might* have failed to keep up on the legal front.

Post by Alexandre Oliva
Now, why should we weaken our defenses

I am at a loss to understand this rhetoric, all we are talking
about is what version number to use, how does this "weaken
our defenses" (what defenses? against whom?).

Some people are advocating that patches be under GPLv2+, to enable
earlier releases with backports to remain in GPLv2. Since GPLv2 has
weaker defenses for users' freedoms than GPLv3, against those who
might wish to impose restrictions on these freedoms, GPLv2-compatible
patches would enable backports into more weakly-defended releases.
The weaker defenses stem mainly out of uncertainty as to the extent of
"no further restrictions".

[Joel Sherrill]

Post by Alexandre Oliva

So you typically would wait till the license change was definite.

It seems to me that it would be saner to not only keep up with the
developments of the license, but also get one's major customers aware
of the upcoming changes, not creating false expectations as to
licensing issues. We shouldn't hold back the upgrade just because
some vendors *might* have failed to keep up on the legal front.

I don't think the FSF should delay at all in moving its
distributions to GPLv3. Do whatever version numbering
is required to make it clear to users.

The FSF can even go so far as to release no further GPLv2
patches. That is their right and they have no obligation
to provide further support for older compilers.

OTOH there are a number of non-FSF entities that
have committed morally and/or legally to providing
long-term support for gcc directly and/or OSes that ship
with a gcc. I really believe these people need guidance
from the FSF on what to do.

--joel sherrill

[Michael Eager]

Post by Alexandre Oliva
See, I'm not diminishing the importance of licensing issues, I'm just
saying it's legally irresponsible to sit back and *not* even watch
what's going on in the development of the license

Everybody's been watching. The license has changed many times.
There's been on-going conflict between FSF and Linux. There's
been widely publicized conflicts about about DRM, and Novell/Microsoft,
patent license and other issues. It's been like watching a cat
fight -- fur flying everywhere.

No lawyer is going to spend his time trying to sort out
the effect of the license until it is finalized.

Post by Alexandre Oliva
Some people are advocating that patches be under GPLv2+, to enable
earlier releases with backports to remain in GPLv2. Since GPLv2 has
weaker defenses for users' freedoms than GPLv3, against those who
might wish to impose restrictions on these freedoms, GPLv2-compatible
patches would enable backports into more weakly-defended releases.
The weaker defenses stem mainly out of uncertainty as to the extent of
"no further restrictions".

GPLv2 has been effective for many years. It doesn't stop being
effective overnight.

Let's tone down the high falootin' rhetoric about defending freedoms
and discuss the pragmatic issues of how to manage licenses in a
real world with real companies and real lawyers and real concerns.

[Geoffrey Keating]

Post by Alexandre Oliva

Post by Nicholas Nethercote
One way to view it: the license is a feature. Therefore changing the
license is changing a feature.

Every release of GCC in the past decade (and then some) was GPLv2+.
GPLv3 has always been one of the options.
Anyone who had their heads in the sand for the past 18 months when
GPLv3 was being publicly discussed and developed, or wasn't at the GCC
Summit last year when I mentioned that the FSF would most certainly
want to upgrade the license of every project whose copyright it held
as soon as GPLv3 was ready, may indeed consider the license upgrade as
a surprising new feature.

Speaking as an individual developer who nonetheless needs to follow
his company's policies on licensing, I need it to be *absolutely
clear* whether a piece of software can be used under GPLv2 or not.

If there's a situation where 'silent' license upgrades can occur,
where even just one file in a release might be GPLv3, or any other
situation where the license is not clear, then to me that software is
unusable. This applies to subversion as well to releases in tarballs.

So I would ask the SC to ensure that any piece of software that might
not be licensable under GPLv2 is clearly marked as such, in a single
obvious place, as prominently as possible. A new distinctive version
number (eg. 4.3.0 or 5.0.0, or 4.3.3, or 4.3.1.4.1.6) would help a lot
in this regard. (I would also like every other possible means of
notification: updating COPYING, release notes, gcc.gnu.org front page,
gcc-announce, skywriting...)


As far as surprises go, I would point out that the new C++ front-end
was not a surprise to anyone following GCC development, but that
doesn't mean that everyone was ready to use it on their code the day
that 4.0.0 was released. In fact I think not everyone is ready to use
it even today, two years after the release, and that's the kind of
timescale to be thinking about when considering GPLv3 adoption.

[Brooks Moses]

Post by Geoffrey Keating
Speaking as an individual developer who nonetheless needs to follow
his company's policies on licensing, I need it to be *absolutely
clear* whether a piece of software can be used under GPLv2 or not.
If there's a situation where 'silent' license upgrades can occur,
where even just one file in a release might be GPLv3, or any other
situation where the license is not clear, then to me that software is
unusable. This applies to subversion as well to releases in tarballs.

That's a good point. I think it would be a good idea to pick a clear
point at which the gcc mainline on SVN will stop being GPLv2, and make
sure that a tarball of its state immediately before that point is
produced. (I guess that point is whenever the first license-change
patch gets committed.)

This should also be documented clearly on the GCC main page, I think.

- Brooks

[Michael Eager]

Post by Alexandre Oliva

Post by Nicholas Nethercote
One way to view it: the license is a feature. Therefore changing the
license is changing a feature.

Every release of GCC in the past decade (and then some) was GPLv2+.
GPLv3 has always been one of the options.
Anyone who had their heads in the sand for the past 18 months when
GPLv3 was being publicly discussed and developed, or wasn't at the GCC
Summit last year when I mentioned that the FSF would most certainly
want to upgrade the license of every project whose copyright it held
as soon as GPLv3 was ready, may indeed consider the license upgrade as
a surprising new feature.

Not everyone is a GCC developer.

Upgrade the license of every project implied that this would be
effective for future releases, not retroactive.

Post by Alexandre Oliva
Now, why should we weaken our defenses for the sake of those who
didn't plan for something that could have been so easily forecast 18
months ago, and that was even planned to be finished 4 months ago?
Heck, the last-call draft, published one month before the final
release, was so close to the final release that non-insider lawyers
who were on top of the process managed to emit solid opinions about
the final license the day after it was released.

It seems to me that it is the FSF which didn't forecast consequences
well, and has now created a problem.

No one is suggesting that any defenses be weakened. Only that source
currently available under GPLv2 continue to be available under that
license.

Post by Alexandre Oliva
It's those who didn't do their homework and didn't plan ahead for this
predictable upgrade who should be burdened now, rather than all of us
having to accept weaker defenses for our freedoms or facing additional
requirements on patches or backports. It was all GPLv2+, and this
means permission for *anyone* to upgrade to GPLv3+. The license
upgrade path is the easy path, and that's by design.

Companies will not upgrade to GPLv3 until they have reviewed it.
It was released ~2 weeks ago. It's clearly been in a state of flux for
many months, up until the release date.

The question is not whether companies can upgrade past releases
to GPLv3 voluntarily. That's a red herring. The question is
whether companies who are currently releasing source under GPLv2
will be prohibited from releasing the code under GPLv2 if they
do something as innocuous as apply a publicly posted patch.

Try a pragmatic approach, rather than a dogmatic approach.

[Michael Meissner]

Post by Mark Mitchell
The GCC SC is still discussing a few of the finer points of the
transition to GPLv3.
1. The compiler proper (e.g., files used only in cc1, cc1plus, the
driver, etc.) should all be converted to GPLv3 ASAP.
Will someone (or someones) please volunteer to change the various files
that mention GPLv2 to mention GPLv3 instead, to change the COPYING file
in the gcc/ directory, and to look for other things that need to change?
2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit
backports from mainline to GCC 4.2.1, if necessary, to be downlicensed
to GPLv2, as part of that release.
3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.
It has not yet been decided what to do about files that are part of
run-time libraries and are covered by GPL/LGPL + exception. Therefore,
no changes to
It has also not yet been decided whether backports of bug-fixes from
GPLv3 versions of GCC to older GPLv2 versions of GCC (e.g., GCC 4.1)
will result in the patched compilers being GPLv3. If you have thoughts
about that, you might wish to contact the FSF.

As a user, I would prefer not to have GCC's version change from 4.2 to 4.3.
But assuming the copyright owner (FSF) does want us to change the version
number, why not go to 5.2.2 instead of 4.2.2. What would have been 4.3 will
now be 5.3 or 6. To accomidate code that checks __GNUC_MAJOR_VERSION__ for
feature tests, I would suggest that the historical branches (what is 4.2 and
4.1 right now) keep the major version to 4, but that the new releases (ie what
is currently 4.3) would change the major version to 5.

To the people that argue changing the major version number should only be
reserved for major things, I would respond that changing the license terms *IS
A MAJOR THING*, and it furthers the political goals of the FSF.

Note, while disclaimers are generally implied, I must stress that in this
particular case, it is my opinion, and not necessarily the view of my
employer.

[Joern Rennecke]

I would prefer the following numbering:

4.2.1 last full patchlevel release of gcc under GPLv2
4.2.1.x patch releases to gcc 4.2.1 where only patches with GPLv2 license
are applied
4.2.2 The first GPLv3 patchlevel release of gcc 4.2

Rationale: Because some people want to stay with GPLv2 for the time being,
there undoubtably will be patched gcc 4.2.1 versions that are still GPLv2.
By having an official branch for such versions, we make version
confusion less likely. By having these versions carry a sub-patchlevel off
4.2.1, it is also apparent that these versions are restricted in what patches
can be used, while 4.2.2 and later vesions are not restrained in the same way.

Moreover, when someone gets to an ftp site to download a gcc tarball,
the 4.2.1.1 version will stick out, and with possibly adding a README.GPLv3
and README.4.2.1.x files, that (in addition to the already discussed
announcements / release notes) should be sufficient to inform users of the
license change, so we can dispese with a painful version renumbering.

[DJ Delorie]

Post by Mark Mitchell
1. The compiler proper (e.g., files used only in cc1, cc1plus, the
driver, etc.) should all be converted to GPLv3 ASAP.

I'll note that libiberty is not used "only" in gcc. We still need to
coordinate that change separately.

Post by Mark Mitchell
2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit
backports from mainline to GCC 4.2.1, if necessary, to be downlicensed
to GPLv2, as part of that release.
3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.
What would have been GCC 4.2.2 will instead be GCC 4.3.3, to try to
emphasize the GPLv3 switch. The GCC mainline will then be GCC 4.4.

I write this with a heavy hand, but...

I read these as "4.2.1 is the last 4.2 release". Pulling a 4.3.3 from
that branch is, IMHO, stupid and confusing. If 4.2.1 is the last 4.2
release, the 4.2 branch is DEAD (svn topology notwithstanding). The
next release cannot be 4.3.3, that makes no sense. The next release
would be 4.3.0, regardless of where it came from. However, we've been
telling users "feature X will be in 4.3" for some time, please don't
turn us into liars.

I can see the slashdot headline now: "GCC 4.2.1 to be last 4.2
release; next major release is 4.3.3, without any of the promised 4.3
features."

Users don't care about our svn branching structure, they only care
about release numbers and functionality.

Vendors only care slightly, because they want to know the origin path
of changes, but they don't always mirror our branching structure (RH
doesn't). But they have to explain features vs version to customers.

The SC says they don't have a choice, but they do. They can choose to
stay with the current 4.3-as-head and let the 4.2 branch die with
4.2.1 (just hold off the 4.2.1 release until 4.3 is released ;). That
honors the FSF's hard-headed goals, without causing confusion for the
people who use and care about gcc.

I, as a technical contributor, will not support the "4.3.3 follows
4.2.1" decision. If RMS wants to screw the users, let RMS write the
patches. I care about the users too much to participate in this type
of fiasco. Perhaps others who feel as I do will agree, and the FSF
will find that there's nobody left to work on 4.3.3 any more. Then
what?

As an aside, I consider version numbers to be, at least partially, a
technical issue, since so many packaging systems rely on them making
sense in a programatical way. In that respect, the SC should not be
acting unilaterally, as they are not supposed to make technical
decisions.

[Brooks Moses]

Post by DJ Delorie
I read these as "4.2.1 is the last 4.2 release". Pulling a 4.3.3 from
that branch is, IMHO, stupid and confusing. If 4.2.1 is the last 4.2
release, the 4.2 branch is DEAD (svn topology notwithstanding). The
next release cannot be 4.3.3, that makes no sense. The next release
would be 4.3.0, regardless of where it came from. However, we've been
telling users "feature X will be in 4.3" for some time, please don't
turn us into liars.

We are, what, about six months out from having the current 4.3 branch
ready for release? And 4.2.1 will be released in a week or two, so
there's not any present urgency to a further release there yet.

We _could_, hypothetically speaking, avoid some of the confusion
problems you mention by waiting until mainline is ready for release, and
releasing it as 4.4.0, and only _then_ doing the next release in the
4.2-branch sequence (which we'd call 4.3.0). Yes, this would mean that
4.3.0 and 4.4.0 are released essentially simultaneously, and it would
mean waiting three extra months for an official 4.2-branch update.
Might be worth it, though.

On the other hand, this also means that even with the present schedule
and stuff, it's only three months or so between "Ok, so here's 4.3.0,
which doesn't have what we'd said would be in it" and "And now here's
4.4.0, which does have all that", and that isn't _that_ long.

- Brooks

[R. D. Flowers, Chattanooga TN USA]

I rarely de-lurk, but:

It seems to have been suggested that (with at least some new patches
being "GPLv2 or later" in some lawful way acceptable to FSF):

0. Bump no version numbers to reflect license changes.

It seems to me that there have been proposed (with all new patches being
"GPLv3 or later"):

1. Bump both minor and sub-minor numbers.
2. Bump the major number(s).

I think that we also could do one of:

3. Bump only the minor numbers, but twice (to avoid 2 different 4.3.x
series). Start with new subminors. Changes to 4.2 would go in 4.4.x.
Mainline would be in 4.5.x.

4. Bump only the subminor number. Maybe correcting license holes could
be considered sort of a bugfix.

MHO (best first) is 0,4,3, huge gap 1, 2.


--
R. D. Flowers
Earth Rising

481 days until they pay
558 days until he leaves

[David Gressett]

$.02 from a user who has been following the discussion:

1. Don't jack with the version numbers. This is confusing.
2. Turn off public access to the code while changing license text in the
source.
3. Backports to current stuff should stay under current licence, i.e. a
gcc 4.2.1 containing bits and pieces of 4.3 should stay under GPLv2
until 4.3 is released. If a 4.2.2 comes out after the release of 4.3, it
should go to GPLv3. I.e, all open branches should change licenses at once.
4. gcc should put a short reference to the license in the version
string. My MingGW version of gcc describes itself as
"gcc version 3.4.5 (mingw special)" A future MinGW version should do
something like "gcc version 4.3.0 (mingw special) GPLv3". Every vendor
who distributes a tweaked gcc should be requested to to implement this ASAP.
5. It probably wouldn't hurt to have a command-line option to describe
the license(s) in more detail. This would be especially useful when
using compilers from vendors like AdaCore who have products like GNAT
GPL which has a run-time library that is governed by GPL rather than LGPL.
6. gcc isn't the only software product that will be affected by
confusion about the license. gcc should provide a small license-display
library that users can use in their own products. This would be easy
enough for any user to implement, but if it comes with gcc, it would be
more likely to be widely used.

[Nick Clifton]

Hi David,

Post by David Gressett
2. Turn off public access to the code while changing license text in the
source.

This is not necessary. (I am assuming here that by "public access to
the code" you mean access to the svn repository, not access to the
various release tarballs). The repository sources are not an official
release. They are part of the development process for future releases.
Anyone using these sources should be aware of this and not expect them
to remain constant. In particular, in the context of this discussion,
no-one should expect that the mainline repository sources will all exist
under the governance of just one version of the GPL.

I will be as quick as I can in updating the mainline sources, but it is
going to take me a couple of days. I am going to perform the upgrade in
an incremental fashion as I do not have the bandwidth to perform a
single pass commit of all of the sources.

Cheers
Nick

[Alexandre Oliva]

Post by Mark Mitchell
2. GCC 4.2.1 will be the last GPLv2 release. The FSF will permit
backports from mainline to GCC 4.2.1, if necessary, to be downlicensed
to GPLv2, as part of that release.
3. After GCC 4.2.1 is released, we will renumber the branch to GCC 4.3.

How about, after the 4.2.1 release, switch the branch to GPLv3 and
then release 4.2.3, without any functional changes, under GPLv3?

The skipped minor version number (to a .3, no less) and the quick
succession of releases would probably hint at the license upgrade, and
it would probably make the FSF happier with a GCC release under GPLv3
in a short time-frame.

[Russ Allbery]

How about, after the 4.2.1 release, switch the branch to GPLv3 and then
release 4.2.3, without any functional changes, under GPLv3?
The skipped minor version number (to a .3, no less) and the quick
succession of releases would probably hint at the license upgrade, and
it would probably make the FSF happier with a GCC release under GPLv3 in
a short time-frame.

Just a GCC user, not a developer, so please weigh my opinion
appropriately, but I for one would strongly prefer that the GCC project
not use "cute" version number changes as a form of semaphore communication
to users. That's what release notes are for. Version numbers are the
most useful when they are monotonically increasing, follow a normal
arithmetic progression, and follow a consistent policy about how they
change with each release.

I personally don't care of the GPLv3 change gets a major version number
change or a minor one, but please make the first 4.3 release 4.3.0, and
please maintain the convention that the next minor release after 4.2.1 is
4.2.2. Anything else is needlessly confusing IMO and raises pointless
questions.

[Clemens Koller]

Post by Russ Allbery

How about, after the 4.2.1 release, switch the branch to GPLv3 and then
release 4.2.3, without any functional changes, under GPLv3?
The skipped minor version number (to a .3, no less) and the quick
succession of releases would probably hint at the license upgrade, and
it would probably make the FSF happier with a GCC release under GPLv3 in
a short time-frame.

Just a GCC user, not a developer, so please weigh my opinion
appropriately, but I for one would strongly prefer that the GCC project
not use "cute" version number changes as a form of semaphore communication
to users. That's what release notes are for. Version numbers are the
most useful when they are monotonically increasing, follow a normal
arithmetic progression, and follow a consistent policy about how they
change with each release.
I personally don't care of the GPLv3 change gets a major version number
change or a minor one, but please make the first 4.3 release 4.3.0, and
please maintain the convention that the next minor release after 4.2.1 is
4.2.2. Anything else is needlessly confusing IMO and raises pointless
questions.

100% ACK!

I wouldn't care if you label the first GPLv3 version 5.0.0, as long as
it's a monotonic version number increase.

Just my 5.0.0 cents. ;-)
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.[phone]
Fax [phone]
http://www.anagramm-technology.com

[Rob Brown]

As a (non-developer) user, may I humbly submit a slightly different view:

The change of license is an Event, which needs to be marked in concrete by
a version number change. All future mainline development will be under the
GPLv3. However, there are many people who (due to legal or commercial
pressures, amongst others) are required to continue under GPLv2, and there
doesn't seem to be a good pragmatic reason to actively penalise those people.

I think that having one more GPLv2 release, and then all future releases
under GPLv3, creates a discontinuity in the compiler between licenses which
may be unhelpful because the first GPLv3 gcc will be technically different
to the last GPLv2 gcc. This means that the decision about which to use will
be a combination of license issues and technical issues.

So, could there be a simultaneous release of gcc under GPLv2 and GPLv3,
identical in all respects except for the license? The GPLv2 release will
represent the best-quality compiler that the project can deliver, as a base
for those who must continue to support it. The GPLv3 release will be the
reference point for future development, and will be a known quantity in
technical terms.

The GPLv2 compiler could be gcc 4.2.1, and the GPLv3 compiler could be gcc
4.3.0. There is an issue that people have been hearing about the new
functionalities that gcc 4.3 will have, but it shouldn't be too hard to
"market" the concept that 4.3 is now a license change version, and 4.4 will
be the compiler that 4.3 was going to be.

Perhaps the simultaneous release could be done on July 31, which is iirc
the FSF's deadline for GPLv2 releases. Extending the gcc 4.2.1 release date
might allow some last-minute bug-fixes to make it in there.

Compiler vendors etc will have an increased workload maintaining the
separability of GPLv2 and GPLv3 code during the transition to the new
license, and it would seem that the transition will take quite some time
(years?), but I'm sure that they will develop procedures to make it manageable.

Cheers,
Rob Brown.

[Krzysztof Halasa]

Post by Rob Brown
So, could there be a simultaneous release of gcc under GPLv2 and GPLv3,
identical in all respects except for the license?

How could that be useful? That v2(+) version would already be v3
if the user wanted so (due to the "or later" clause).

Use any licence you want but don't mess with version numbers
or the branches (including closing) for purely political,
not technical reasons.

[Rob Brown]

Post by Michael Eager

Post by Krzysztof Halasa

Post by Michael Eager
Not until someone updates the txt. Which should happen quickly,
but if someone applies a GPLv3 patch to a previously GPLv2 branch,
the entire branch becomes GPLv3, whether the COPYING file was
updated or not.

Come on, if the FSF (the copyright holder) distributes a program,
and if the included licence says GPLv2+, then the licence is GPLv2+
and you'll have a really hard time trying to convince anyone that
it's different.

You asked if COPYING would be updated. The answer is not necessarily.
The COPYING text may say GPLv2+, but if there has been a GPLv3 patch
applied to the branch, then the entire branch is GPLv3.

I struggle to believe this. Afaik a bunch of code is released under a
license, and nothing has the power to magically change that license. If
someone applies a GPLv3 patch to some GPLv2 code and releases the whole
under the GPLv2, then that person has broken copyright law and the release
is invalid (because the GPLv3 code has been released without a license),
but the rest of the GPLv2 code is still GPLv2. Or have I missed something
here? It sounds to me like the syntactic mischief Microsoft is playing when
it calls the GPL "viral" (note, I'm not suggesting that you are making
mischief, just that the implication is similar)!

Post by Michael Eager

Post by Krzysztof Halasa
BTW: the copyright holder is free to take a GPLv3 patch and
release it under GPLv2 (and any other licence).

FSF is the copyright holder. As of this time, they have said
that they are not willing to release patches under GPLv2 for
application to GPLv2 branches. Mark has a proposal which would
allow for that.

I think this misses a point: FSF is a copyright assignee, and I don't know
how that relates to "holding", but the person who wrote the patch is free
to dual-license without reference to the FSF. So as a completely fabricated
example: say in 6 months Richard Kenner makes a patch to (GPLv3) mainline
for a bug, and you want that patch to improve a GPLv2 product that you're
maintaining for one of your customers. You are free to ask Richard to
release that patch to you under GPLv2, and Richard is free to grant that
request.

[Rob Brown]

Post by Robert Dewar
One could of course just take a blanket view that everything
on the site is, as of a certain moment, licensed under GPLv3
(note you don't have to change file headers to achieve this,
the file headers have no particular legal significance in
any case).

According to http://www.gnu.org/licenses/gpl-howto.html, the file headers
are precisely the place to make the license grant.

Post by Robert Dewar
That at least would be clean, and anyone concerned with
accepting GPLv3 stuff would simply know that as of this
date and time, they should no longer download ANYTHING
from the entire gnu.org site.
That's actually not so terrible, you lose some users
temporarily, but at least there is no misunderstanding.

There would be gross misunderstanding! Placing everything on gnu.org under
GPLv3 does nothing to affect all of its mirrors. So if I download
gcc-4.2.0.tar.bz2 from ftp.gnu.org then it's GPLv3, but if I download it
from any of the mirrors then it's GPLv2.

Surely the aim of the process should be to eliminate "gotchas" as much as
possible. Everyone has the responsibility to verify that they have a
license before using someone else's code. How could I, as the recipient of
a file which says "GPLv2" etc at the top, know that it was downloaded from
gnu.org and is actually really GPLv3?