This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077