Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
The next GPL: Why it's being shaped on GitHub (InfoWorld)
Posted Jul 6, 2012 19:43 UTC (Fri) by mlinksva (subscriber, #38268)
Posted Jul 6, 2012 20:57 UTC (Fri) by landley (guest, #6789)
I liked the quid pro quo of GPLv2. I don't like navigating a rights minefield. I learned the elaborate ins and outs of _one_ license, and then all I had to know about anything else was "can your code fit into this box (y/n)".
It's now more complicated than that. This is not an improvement. Now I can't avoid worrying about the _interaction_ of licenses, and IANAL. This strikes me as just as dangerous as a non-security specialist trying to figure out the interaction between selinux and no_new_privs. I know there are potential problems here, I don't feel confident in my ability to have spotted them all, and given the way random third parties tend to drive a truck through these things I'm just not going there.
"Copyleft" no longer means "code you can use in your project without looking further", and neither does "GPL". Saying "this code is GPL" doesn't say whether I can use it in a kernel driver, or in Samba, and you can't move code from one project to the other even though they implement two ends of the same protocol.
One way convertibility means that if somebody else takes my code, and they patch it, that patch can't go back upstream to the original project. Once upon a time this made the full GPL a black hole accumulating the canonical version of everything, and you could only re-use that giant mass of code if your project was also GPL.
Sure, long before Affero and the need to distinguish "GPLv2 only" from "GPLv2 or later", this led to some fun corner cases with the gcc linking exception clause and QT being GPL (not LGPL) which meant you _couldn't_ link against them without buying a license but the kernel headers were GPL (not LGPL) and you _could_ link against them...
But there was a safe haven: full GPL meant you didn't have to care. I could avoid being a half-assed laywer by shipping GPLv2 and rejecting code that wasn't compatible with GPLv2. That safe haven option no longer exists, because there isn't one full GPL anymore.
I had this brought home to me when I inherited a project (BusyBox) that had incorporated "GPLv2 only" code from kernel developers into its "GPLv2 or later" codebase, meaning that to be compliant we had to either audit every contribution ever or fail closed to GPLv2 only. I cared about being scrupulously compliant because we were looking to break new ground trying to _enforce_ this license by suing people over license violations. Getting our house in order preparing to launch license enforcement suits is actually how this came up in the first place.
This "GPLv2 only" vs "GPLv2 or later" distinction had never mattered until there was a GPLv3 for the "or later" clause to apply to in a non-theoretical way. Dealing with this was _annoying_, because I just wanted to do development. (And because some clueless troll who'd never posted before in the history of the project's mailing list showed up to harass us because he personally wanted us to switch to GPLv3, but he's irrelevant except as a source of annoyance.)
That project took advantage of the "universal receiver" at the 11th hour, back when there still wasn't any GPLv3 code in the wild, and ever since it (like all projects) has had to filter contributions with more than just "is it GPL". Now there's at least three states: GPLv2 only, GPLv2 or later, GPLv3. Not counting Affero, and this new thing.
In the absence of a viable universal receiver, I've switched my code to being a universal donor. There's no longer one terminal node that lets me re-use essentially everything, just multiple unconnected leaf nodes. (And the leaf node containing the single largest open source project in history _isn't_ the one this article's talking about.)
If picking a non-leaf node means one way convertibility off what my project can accept as a contribution has become more or less unavoidable, I can at least pick the license that converts _to_ as many things as possible, so my code can feed _into_ those others. Hence the simplest (2 clause) BSD, essentially public domain with a fig leaf against frivolous lawsuits.
Posted Jul 9, 2012 3:44 UTC (Mon) by kevinm (guest, #69913)
Posted Jul 9, 2012 11:25 UTC (Mon) by pbonzini (subscriber, #60935)
Posted Jul 16, 2012 3:20 UTC (Mon) by kevinm (guest, #69913)
Of course the GPLv2-only parts cannot ever be included in a third party GPLv3+-only project, but we're only trying to make a universal reciever here, not a universal donor.
Posted Jul 16, 2012 4:07 UTC (Mon) by dlang (✭ supporter ✭, #313)
This means that you can't then include code from a GPL3+ project, because you don't have any terms under which you can distribute the result.
you can't use GPLv2 because of the GPLv3 code
you can't use GPLv3 because of the GPLv2 code
Busybox realized that they had included GPLv2 only code, and so they went through and made sure they didn't have any GPLv3+ code and properly documented that the result was GPLv2 only, not GPLv2+
dual licensed codebases can be distributed under _any_ of the licenses, you can't use one license for some and a different license for other. If you could, then the CPL would be meaningless as you could 'dual license' your code GPL + proprietary and not give out the source to the proprietary bits.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds