ChatGPT's New Skills Resident Evil 4 Remake Galaxy A54 5G Hands-On TikTok CEO Testifies Huawei's New Folding Phone How to Use Google's AI Chatbot Airlines and Family Seating Weigh Yourself Accurately
Want CNET to notify you of price drops and the latest stories?
No, thank you

Mark Lewis of EMC on GPLv3: A step in the wrong direction?

Is the GPL forking itself? That's what Mark Lewis of EMC believes and, to the extent that he's correct, it's a serious problem.

It's great to have Mark Lewis blogging. I remember pinging him about OSBC involvement back in 2003 when, as now, his title reflected open source strategy. He then got pulled into some other areas at EMC. He's exceptionally bright and a credit to his employer. Good to have him back, focused on open source issues.

On this particular one - GPLv3 - I think his corporate affiliation may be coloring his opinion somewhat, as he spends too much time worrying about the ability to mingle proprietary code with GPLv3 code.

The newly aggressive provisions about what code combinations must be covered by GPLv3 create cumbersome issues for anyone, proprietary or open, who wants to combine code under another license with GPLv3....

For developers who use GPL code for "nuts and bolts" and innovate around it, GPLv3 is harder to work with than GPLv2 and much, much harder than Apache or BSD. It isn't impossible - just the equivalent of a full employment contract for many lawyers. This is not a direction I see as useful, it's just added confusion.

Also by clamping down on the allowed means of mixing software, GPLv3 rules out some of the current types of proprietary innovation, thereby removing some existing incentives to contribute to the maintenance and improvement of open source software. This sacrifices investment in open source software in order to pursue political principles, and I wonder whether that tradeoff is the wisest move.

I wish Mark would have provided some examples, because I don't understand this point. My understanding of GPLv3 is that it's essentially the same as v2, but the legalese has been updated. I'm actually disappointed that it's not a more progressive license.

Mark's other points about GPLv3's one-way compatibility and incompatibility with GPLv2 are better points, though I continue to not care very much if the FSF thinks it's compatible with Apache or not. Reasonable minds can disagree on this - I don't need the FSF's explicit blessing to believe that the GPL (v2 and v3) are compatible with Apache licensing.

But the v2 incompatibility is more worrisome. RMS has given the reason behind the incompatibility:

When we say that GPLv2 and GPLv3 are incompatible, it means there is no legal way to combine code under GPLv2 with code under GPLv3 in a single program. This is because both GPLv2 and GPLv3 are copyleft licenses: each of them says, "If you include code under this license in a larger program, the larger program must be under this license too." There is no way to make them compatible. We could add a GPLv2-compatibility clause to GPLv3, but it wouldn't do the job, because GPLv2 would need a similar clause.

OK. I get that. But it's a problem. I agree with Mark that this is a big step backward, because it makes GPLv3 code incompatible with 70%+ of the code out on Sourceforge. It's a bold move, cannibalizing oneself, but a premature one, in my mind. I don't care if proprietary companies feel that they can hijack GPL code - they couldn't under v2 and I'm grateful that v3 keeps this barrier. But interoperability with previous versions of the GPL...that's important. Unfortunately, GPLv3 removes this, and that's a problem.

Maybe a FLOSS Exception is the right way to deal with this, though it doesn't really remedy the incompatibility, for the reasons stated by RMS....