User: Password:
|
|
Subscribe / Log in / New account

The next GPL: Why it's being shaped on GitHub (InfoWorld)

The next GPL: Why it's being shaped on GitHub (InfoWorld)

Posted Jul 6, 2012 20:57 UTC (Fri) by landley (subscriber, #6789)
In reply to: The next GPL: Why it's being shaped on GitHub (InfoWorld) by rfontana
Parent article: The next GPL: Why it's being shaped on GitHub (InfoWorld)

Actually I switched my projects over to the simplest 2-clause BSD I could find when I became convinced the GPL fragmentation had started doing more harm than good to software developers trying to read and re-use code.

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.


(Log in to post comments)

The next GPL: Why it's being shaped on GitHub (InfoWorld)

Posted Jul 9, 2012 3:44 UTC (Mon) by kevinm (guest, #69913) [Link]

Would a dual-licensed GPLv2 / GPLv3 project be a universal receiver?

The next GPL: Why it's being shaped on GitHub (InfoWorld)

Posted Jul 9, 2012 11:25 UTC (Mon) by pbonzini (subscriber, #60935) [Link]

No, because as soon as you copy in GPLv2-only code, GPLv3-or-later, or GPLv3-only code your code is not anymore GPLv2/GPLv3 dual-licensed. It has a large GPLv2/GPLv3 dual-licensed core, but it can only be distributed in its entirety under GPLv2 or GPLv3, depending on the license of the code you took.

The next GPL: Why it's being shaped on GitHub (InfoWorld)

Posted Jul 16, 2012 3:20 UTC (Mon) by kevinm (guest, #69913) [Link]

I don't think that's true. If you copied in, say, GPLv2-only code then that code says "you must offer to license your derivative work under the GPLv2". Licensing your derivative work under either GPLv2 or GPLv3 fulfills that.

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.

The next GPL: Why it's being shaped on GitHub (InfoWorld)

Posted Jul 16, 2012 4:07 UTC (Mon) by dlang (subscriber, #313) [Link]

no, if you include GPLv2 code only, you have no rights to distribute it under the GPLv3, it makes your resulting codebase GPLv2 only when combined.

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 © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds