subject:"Re\: RFH\: GPLv3"

> 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.

David

RE: RFH: GPLv3

On 12 July 2007 15:29, Doug Gregor wrote:

> On 7/12/07, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
>> Mark Mitchell wrote:
>>> 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
-- 
Can't think of a witty .sigline today

Re: RFH: GPLv3

Mark Mitchell <[EMAIL PROTECTED]> writes:

> 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.

> 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.)

> 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.

> 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

Re: RFH: GPLv3

David Edelsohn <[EMAIL PROTECTED]> 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.

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

Re: RFH: GPLv3

2007-07-12 Thread Doug Gregor


On 7/12/07, David Edelsohn <[EMAIL PROTECTED]> wrote:

> 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.


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

Re: RFH: GPLv3

> Ian Lance Taylor writes:

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

Re: RFH: GPLv3

> Doug Gregor writes:

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

RE: RFH: GPLv3

On 12 July 2007 15:54, David Edelsohn wrote:

>> Doug Gregor writes:
> 
> 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
-- 
Can't think of a witty .sigline today

Re: RFH: GPLv3

2007-07-12 Thread Doug Gregor


On 7/12/07, Dave Korn <[EMAIL PROTECTED]> wrote:

On 12 July 2007 15:29, Doug Gregor wrote:
> 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

Re: RFH: GPLv3

2007-07-12 Thread Basile STARYNKEVITCH

Dave Korn wrote:

On 12 July 2007 15:29, Doug Gregor wrote:

On 7/12/07, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:

Mark Mitchell wrote:

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.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet | mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: RFH: GPLv3

> Dave Korn writes:

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. 

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

RE: RFH: GPLv3

On 12 July 2007 16:06, Dave Korn wrote:

> On 12 July 2007 15:54, David Edelsohn wrote:
> 
>>> Doug Gregor writes:
>> 
>> 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
-- 
Can't think of a witty .sigline today

Re: RFH: GPLv3

2007-07-12 Thread Benjamin Smedberg

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

David Edelsohn wrote:
>> Doug Gregor writes:
> 
> 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
[EMAIL PROTECTED]
http://benjamin.smedbergs.us/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGlkqfSSwGp5sTYNkRAid2AKDa67NkOEy/3XBQAhzDqkxV4pFI/QCcCbRx
XbDhAsRG7xpXKtJKUXwos3c=
=dK44
-END PGP SIGNATURE-

Re: RFH: GPLv3

> Benjamin Smedberg writes:

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.

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

Re: RFH: GPLv3

> 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.

Re: RFH: GPLv3

2007-07-12 Thread Benjamin Smedberg

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Richard Guenther wrote:

>> | 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
[EMAIL PROTECTED]
http://benjamin.smedbergs.us/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGlkulSSwGp5sTYNkRAhkvAJ41Ki5bNRPYYg6ruN9osh1ebXq2wQCfSjTy
9iM05WCf/CPmr4C8Qny4+GQ=
=r9D3
-END PGP SIGNATURE-

Re: RFH: GPLv3

2007-07-12 Thread Benjamin Kosnik

>> 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

Re: RFH: GPLv3

2007-07-12 Thread Diego Novillo

On 7/12/07 11:43 AM, Richard Kenner wrote:
>> 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.

Re: RFH: GPLv3

> 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.

Re: RFH: GPLv3

> 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.

Re: RFH: GPLv3

> 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.

Re: RFH: GPLv3

> Richard Kenner writes:

>> 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

Re: RFH: GPLv3

2007-07-12 Thread Benjamin Smedberg

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

David Edelsohn wrote:
>> Benjamin Smedberg writes:
> 
> 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.
> 
> 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
[EMAIL PROTECTED]
http://benjamin.smedbergs.us/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGlk4QSSwGp5sTYNkRAuYhAKCcXUJVQvIzjSfGgJmUo3vDaeu98ACghYPp
q2jrLjWBpStLUFRI+5Ui2iY=
=WYom
-END PGP SIGNATURE-

Re: RFH: GPLv3

2007-07-12 Thread Gabriel Dos Reis

David Edelsohn <[EMAIL PROTECTED]> 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

Re: RFH: GPLv3

2007-07-12 Thread Bernd Schmidt


David Edelsohn wrote:
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
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: RFH: GPLv3

> Bernd Schmidt writes:

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

Re: RFH: GPLv3

> Bernd Schmidt writes:

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

Re: RFH: GPLv3

> 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!

Re: RFH: GPLv3


Mark Mitchell wrote:

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.


--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: RFH: GPLv3


David Edelsohn wrote:

Bernd Schmidt writes:


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.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: RFH: GPLv3

2007-07-12 Thread Daniel Jacobowitz

On Thu, Jul 12, 2007 at 05:53:52PM +0200, Bernd Schmidt wrote:
> 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.

-- 
Daniel Jacobowitz
CodeSourcery

Re: RFH: GPLv3


Ian Lance Taylor wrote:

Mark Mitchell <[EMAIL PROTECTED]> writes:


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.


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.


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.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: RFH: GPLv3

2007-07-12 Thread Michael Meissner

On Wed, Jul 11, 2007 at 09:58:51PM -0700, Mark Mitchell wrote:
> 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.

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.

-- 
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]

Re: RFH: GPLv3

2007-07-12 Thread Mark Mitchell

Nick Clifton wrote:
> Hi Mark,
> 
>> 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!

>> 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!

> 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,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: RFH: GPLv3

2007-07-12 Thread 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.

Re: RFH: GPLv3

2007-07-12 Thread DJ Delorie

Mark Mitchell <[EMAIL PROTECTED]> writes:
> 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.

> 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.

Re: RFH: GPLv3

Michael Eager <[EMAIL PROTECTED]> writes:

> Ian Lance Taylor wrote:
> > Mark Mitchell <[EMAIL PROTECTED]> writes:
> >
> >> 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.


> > 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.

> > 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

Re: RFH: GPLv3

David Edelsohn <[EMAIL PROTECTED]> writes:

> > Ian Lance Taylor writes:
> 
> 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.

>   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.

>   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

Re: RFH: GPLv3

2007-07-12 Thread Serge Belyshev

Ian Lance Taylor <[EMAIL PROTECTED]> writes:

[...]
> 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.

Re: RFH: GPLv3

2007-07-12 Thread Mark Mitchell

Ian Lance Taylor wrote:

>>> 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.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: RFH: GPLv3

> Ian Lance Taylor writes:

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

Re: RFH: GPLv3

2007-07-12 Thread 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

RE: RFH: GPLv3

On 12 July 2007 17:59, Ian Lance Taylor wrote:


> 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
-- 
Can't think of a witty .sigline today

Re: RFH: GPLv3

2007-07-12 Thread Mark Mitchell

David Edelsohn wrote:

>   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.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: RFH: GPLv3


Diego Novillo wrote:

On 7/12/07 11:43 AM, Richard Kenner wrote:

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

Re: RFH: GPLv3


Michael Eager wrote:

Ian Lance Taylor wrote:

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

Re: RFH: GPLv3

2007-07-12 Thread 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.

Re: RFH: GPLv3

2007-07-12 Thread Janis Johnson

On Thu, 2007-07-12 at 09:58 -0700, Ian Lance Taylor wrote:
> 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

Re: RFH: GPLv3


Ian Lance Taylor wrote:

Michael Eager <[EMAIL PROTECTED]> writes:


Ian Lance Taylor wrote:

Mark Mitchell <[EMAIL PROTECTED]> writes:


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. 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.


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.


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.


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.


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 G

Re: RFH: GPLv3

2007-07-12 Thread Basile STARYNKEVITCH


Brooks Moses wrote:

Diego Novillo wrote:

On 7/12/07 11:43 AM, Richard Kenner wrote:

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).



--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet | mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: RFH: GPLv3


Mark Mitchell wrote:

David Edelsohn wrote:

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

RE: RFH: GPLv3

On 12 July 2007 18:42, Janis Johnson wrote:

> On Thu, 2007-07-12 at 09:58 -0700, Ian Lance Taylor wrote:
>> 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
-- 
Can't think of a witty .sigline today

RE: RFH: GPLv3

2007-07-12 Thread Janis Johnson

On Thu, 2007-07-12 at 18:47 +0100, Dave Korn wrote:
> On 12 July 2007 18:42, Janis Johnson wrote:
> 
> > On Thu, 2007-07-12 at 09:58 -0700, Ian Lance Taylor wrote:
> >> 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

Re: RFH: GPLv3

2007-07-12 Thread Robert Dewar


Serge Belyshev wrote:


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.

Re: RFH: GPLv3

Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:

> 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

Re: RFH: GPLv3

Michael Eager <[EMAIL PROTECTED]> writes:

> 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. 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.

> 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.

> 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

Re: RFH: GPLv3

2007-07-12 Thread Richard Guenther

On 7/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:

Ian Lance Taylor wrote:

>>> 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.

Re: RFH: GPLv3


Ian Lance Taylor wrote:


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.]

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: RFH: GPLv3


DJ Delorie wrote:

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

Re: RFH: GPLv3

On Jul 12, 2007, Michael Eager <[EMAIL PROTECTED]> wrote:

> 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.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Re: RFH: GPLv3

On Jul 12, 2007, Benjamin Smedberg <[EMAIL PROTECTED]> wrote:

> 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.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Re: RFH: GPLv3

On Jul 12, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote:

> 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.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Re: RFH: GPLv3

2007-07-13 Thread Robert Dewar


Alexandre Oliva wrote:


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.


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?).

Re: RFH: GPLv3

2007-07-13 Thread Nicholas Nethercote


On Fri, 13 Jul 2007, Alexandre Oliva wrote:


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

Re: RFH: GPLv3

On Jul 13, 2007, Robert Dewar <[EMAIL PROTECTED]> wrote:

> 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.

>> 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".

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Re: RFH: GPLv3

On Jul 13, 2007, Nicholas Nethercote <[EMAIL PROTECTED]> wrote:

> 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.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Re: RFH: GPLv3

2007-07-13 Thread Robert Dewar


Nicholas Nethercote wrote:

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.

Re: RFH: GPLv3

2007-07-13 Thread Nicholas Nethercote


On Thu, 12 Jul 2007, Michael Eager wrote:


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

Re: RFH: GPLv3

2007-07-13 Thread Nick Clifton


Hi David,

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

Re: RFH: GPLv3

2007-07-13 Thread Joel Sherrill


Alexandre Oliva wrote:

On Jul 13, 2007, Robert Dewar <[EMAIL PROTECTED]> wrote:

  

  

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

Re: RFH: GPLv3

2007-07-13 Thread Russ Allbery

Alexandre Oliva <[EMAIL PROTECTED]> writes:

> 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.

-- 
Russ Allbery ([EMAIL PROTECTED])

Re: RFH: GPLv3

2007-07-13 Thread Clemens Koller


Russ Allbery schrieb:

Alexandre Oliva <[EMAIL PROTECTED]> writes:


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.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

Re: RFH: GPLv3

2007-07-13 Thread Geoffrey Keating

Alexandre Oliva <[EMAIL PROTECTED]> writes:

> On Jul 13, 2007, Nicholas Nethercote <[EMAIL PROTECTED]> wrote:
> 
> > 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.

Re: RFH: GPLv3

2007-07-13 Thread Michael Eager


Robert Dewar wrote:

Nicholas Nethercote wrote:

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.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: RFH: GPLv3

2007-07-13 Thread Michael Eager


Alexandre Oliva wrote:

On Jul 13, 2007, Nicholas Nethercote <[EMAIL PROTECTED]> wrote:


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.


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.


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 Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: RFH: GPLv3

2007-07-13 Thread Michael Eager


Alexandre Oliva wrote:

On Jul 13, 2007, Robert Dewar <[EMAIL PROTECTED]> wrote:

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.


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.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: RFH: GPLv3

2007-07-13 Thread 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.

Re: RFH: GPLv3

2007-07-13 Thread Marcus Meissner

On Fri, Jul 13, 2007 at 08:54:17AM -0700, Michael Eager wrote:
> Robert Dewar wrote:
> >Nicholas Nethercote wrote:
> >
> >>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

Re: RFH: GPLv3

2007-07-13 Thread Brooks Moses


Geoffrey Keating wrote:

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

Re: RFH: GPLv3

2007-07-13 Thread Robert Dewar


Michael Eager wrote:


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.

Re: RFH: GPLv3

2007-07-14 Thread 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.

Re: RFH: GPLv3

2007-07-14 Thread Krzysztof Halasa

Rob Brown <[EMAIL PROTECTED]> writes:

> 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.
-- 
Krzysztof Halasa

Re: RFH: GPLv3


Richard Kenner wrote:

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.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: RFH: GPLv3

2007-07-14 Thread Robert Dewar


Michael Eager wrote:


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.

Re: RFH: GPLv3


Robert Dewar wrote:

Michael Eager wrote:


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.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: RFH: GPLv3

2007-07-14 Thread Krzysztof Halasa

Michael Eager <[EMAIL PROTECTED]> writes:

> 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?
-- 
Krzysztof Halasa

Re: RFH: GPLv3


Krzysztof Halasa wrote:

Michael Eager <[EMAIL PROTECTED]> writes:


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.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: RFH: GPLv3

2007-07-14 Thread Krzysztof Halasa

Michael Eager <[EMAIL PROTECTED]> writes:

> 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).
-- 
Krzysztof Halasa

Re: RFH: GPLv3