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.