RFH: GPLv3

Alexandre Oliva aoliva@redhat.com
Fri Jul 13 14:06:00 GMT 2007


On Jul 13, 2007, Robert Dewar <dewar@adacore.com> 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   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}



More information about the Gcc mailing list