RFH: GPLv3

Michael Eager eager@eagercon.com
Sat Jul 14 22:50:00 GMT 2007


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	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077



More information about the Gcc mailing list