Incompatibility among public copyright licenses dampens their potential for reducing underlying friction caused by copyright. Increasing compatibility among public copyright licenses is one of the successes of the free/libre/open source community, or so I think. Without long-term, distributed collaboration among license stewards and projects released under public licenses, it would have been easy to obtain a world in which it usually isn’t legally possible to use code from one project in another. (A shared understanding of what constitutes “free” and “open” really helps — the scope for incompatible-in-spirit licenses is greatly reduced, and distributed collaboration facilitated by everyone sharing broad premises.)
I’ve been watching from afar development of the Mozilla Public License version 2 (going for nearly 2 years, I believe about the right amount of time to version a widely used public license) almost exclusively because I was eager to see it become GPL compatible, and how it would achieve this.
Luis Villa explained most of the “how” three months ago. To make sure I understand, here’s my summary:
- MPL 1.1 is not GPL-compatible. MPL 2.0 will be, but with a few caveats to ensure that projects released under the MPL won’t become GPL-compatible unintentionally, and that there’s a way for new projects under MPL 2.0 that really, really don’t want to be GPL compatible, don’t have to be.
- Code from a project is released under MPL 2.0 (and not multi-licensed), it can only be made available under the GPL* when incorporated into a larger project that is already GPL licensed, i.e., there has to be a good reason.
- The entity doing such incorporation in the point above has to offer the MPL code under the MPL and additionally the GPL. A downstream entity can choose to only use the GPL. In other words, people who want to use the original project’s code line under the MPL have ample opportunity to do so, until it is truly forked into a GPL-only version.
- MPL 1.1 projects (1.1 has a “future versions” clause) modified and released under MPL 2.0 are not GPL-compatible in the manner above unless the project was already multi-licensed under the MPL and GPL (the most important MPL 1.1 licensed projects are multi-licensed), i.e., the intent to allow for use under the GPL is already established.
- Projects that want to use MPL 2.0 and really don’t want to be GPL compatible can include an “Incompatible With Secondary Licenses” notice.
I think the last point is an unfortunate complication (such projects could stick with MPL 1.1, for instance), but I trust that there are good stakeholder use cases for it. But that’s a minor nit. Villa and other people who worked on MPL 2.0 did a great job and get congratulations and thanks from me.
One of my dreams for Creative Commons Attribution-ShareAlike 4.0 is that it be one-way GPL compatible, as MPL 2.0 will be. MPL 2.0 demonstrates mechanisms for achieving GPL compatibility without upsetting current licensor expectations, which ought be a useful perspective from which to evaluate options for CC BY-SA 4.0. Though CC licenses should not be used for code, it’s easy to see a future in which most “culture” includes “code” and it is an unnecessary pain to keep their licenses separate in all cases. Also, there is some demand for a source-requiring copyleft license for non-software works (BY-SA does not require adaptations to provide source, which is often OK for cultural works, but not always) and it doesn’t make sense to create another source-requiring copyleft license in addition to the GPL.
*Actually LGPL 2.1 or greater, GPL 2.0 or greater, or AGPL 3.0 or greater. MPL has a weaker copyleft than any of the GPL-family licenses — MPL’s copyleft is scoped by file, LGPL’s by library, GPL’s by any linked code, AGPL adds requirement for source distribution to network services.
Addendum 20120103: MPL 2.0 is released today. FSF has added MPL 2.0 to their free licenses page with a GPL compatibility explanation.
One minor nit: because 1.1 has an auto-upgrade clause at the choice of the licensee, a project can’t “stay with 1.1” as a mechanism for prohibiting GPL-compatibility- a licensee who wanted to merge with GPL code could always take under 1.1, convert to 2.0, and voila. But otherwise, clear analysis of the situation. Thanks!
But I thought 2.0’s 1.5(b) made previously 1.1-licensed software that is not mutli-licensed incompatible. By “stay with 1.1” I meant “stay with 1.1 as only license offered”. I don’t understand why an entity multi-licensing under MPL 1.1 and GPL would want to specify incompatibility with secondary licenses (ie GPL, which they’re already offering). Am I missing something?
In any case I’m glad I got it mostly right, and thanks again!
(I also meant to plug MPL 2.0’s HTML typography — http://tieguy.org/blog/2011/08/22/making-html-legal-documents-like-mpl-look-good/ — but for another post.)
Ah, I see what you mean. I think we thought that we still want people to be able to have the other benefits of MPL 2 without getting into a compatibility situation. In retrospect, perhaps that was a poor choice, though.
My current intent for Saxon (subject to review with interested parties) is to move all the open-source code forward from MPL 1.0 to MPL 2.0, except for the small number of modules where there are untraceable contributors, in which case it will go to MPL 2.0 “incompatible with secondary licenses”. Most of these modules are optional features that an integrator could dispense with if they really feel a need; and with luck we can reduce the number over time.
MPL 2.0 is a great improvement over previous versions, for example it’s actually grammatical, and the notice required in source code is no longer embarrassing gibberish.
(Licensing really gets me annoyed, most notably the fact that contributors who add value never quibble about it, whereas consumers who contribute nothing want to waste hours and weeks of my time arguing about the small print. My only objective in licensing is to get these time-wasters off my back.)
Michael,
I hope that better licenses provide less room for people who merely want to argue about licenses to do so, saving humanity lots of time. My expectation may be too high. :-/
I used Saxon a fair amount ~10 years ago. Thanks! (I was satisfied, just haven’t done much XSLT since.)
[…] software licenses, most famously used for Mozilla’s own Firefox browser. That MPL 2.0 is now compatible with the GPL, the most popular free and open source software license, is a big step forward for […]
[…] fields), which I take as an indication that license innovation is possibly more important than compatibility and […]
[…] works metric, the license and free software community look pretty good (note that permissive licenses such as MIT and BSD, visibly popular among web developers, are […]
[…] wants to start from. GPLv3 allowed for the preexisting Apache2 to be compatible with it, and for MPL2 to be developed such that it could be. But maybe it was ridiculous for Apache2 to have been […]
[…] People who know the open source world well like to worry about about “license proliferation” (which the OSI’s license list mentioned at the beginning serves to throttle) and related, license incompatibility. I do too, including in and across nearby spaces, to the extent I think it is a minor tragedy that licenses first developed for software didn’t also come to dominate culture, data, hardware, etc, yet. But I’m pretty sure the open world could cope with each project adapting or developing a license just for its own use, though it would be hugely annoying. Fortunately, progress has often been in the right direction. […]
[…] included a variation on the more complex but in my view elegant and politically advisable mechanism introduced in MPL 2.0, which allows for continued use under the donor compatible license as long as possible. Nobody […]
[…] mentioning MPL 2.0 and potential CC-BY-SA 4.0 compatibility with GPLv3 (both of which I’ve blogged about before), but the most interesting part of the talk concerned his participation in Trans-Pacific […]