MPL 2.0, copyleft, and license compatibility

In part one of my Mozilla Public License piece, I mentioned license compatibility as a major feature of MPL 2.0. In fact, it's such a major - and complicated - issue that it warrants its own explanation.

First, a disclaimer

Exactly what it means for two open source licenses to be compatible is a complicated topic; so complicated that the most sophisticated free and open source license wranglers often disagree on the nuances. This article can provide only an abbreviated overview, and will inevitably have some things that not everyone agrees with. Apologies in advance!

So what is compatibility?

When talking about open source licenses, someone who says "compatible" generally means "one-way" compatibility, where code from a more permissive license can be used as part of a project whose overall license is more restrictive, but not vice versa. For example, if the Mozilla Project switches to MPL 2, Firefox may quickly contain Apache code (because the permissive Apache license will be compatible with Firefox's overall MPL license), but your Apache webserver won't have any Mozilla-licensed code any time soon (because MPL will still be more restrictive than the Apache Project's overall Apache license.)

To be slightly more precise, one can say that permissive License P is one-way compatible with restrictive License R when:

1. Anyone who complies with all requirements of License R would also comply with all requirements of License P.
2. Everything permitted by License P is also permitted by License R.

In other words, License P and License R are compatible if, as long as you play by the more restrictive rules set by License R, you'll also be playing by the rules set by the more permissive License P. So, making two licenses compatible is an exercise in making those rules align.

A good example of these subtle incompatibilities is between MPL 1.1 and Apache 2.0. In certain circumstances, a patent litigant could trigger Apache 2.0's patent peace clause without triggering MPL 1.1's similar (but slightly different) patent peace clause. This made the two licenses incompatible in the sense used here. Aligning these triggering conditions is what allowed us to be more comfortable that Apache 2.0 and MPL 2.0 are compatible. In other words, complying with MPL 2.0's patent requirements will allow someone to be comfortable that they've also complied with the patent requirements of any Apache-licensed code contained within the MPL-licensed project.

Why is compatibility between copyleft licenses hard?

Compatibility between copyleft licenses is tricky because a major reason (in some sense, the major reason) to use copyleft licenses is that new software based on the original software must also be available under the same copyleft license. This was originally intended to protect against proprietary licenses, but it also has the side-effect of "protecting" against other copyleft licenses. GPL does this by requiring that a user must convey the entire program's source code "under the terms of this License." Similarly, MPL 1.1 says modifications are "governed by the terms of this License." These requirements are the central feature of these copyleft licenses,and they are contradictory - if the GPL (or a similar copyleft) requires all components of a program be distributed under the terms of the GPL, and the MPL requires all files under the MPL to remain under the MPL, then (at least under the most common interpretation of the GPL) you can't put MPL files into a GPL program. The same problem will crop up with any two copyleft licenses whose scope overlaps, and this is the challenge that anyone who wants to make copyleft licenses compatible has to resolve.

Can we do better than a dual-license?

The traditional solution for compatibility between copyleft licenses is to dual-license the code, allowing someone to use under either license as necessary. This approach obviously works, but it allows anyone to trivially create incompatible code by distributing changes under only one of the licenses, instead of both (or in the Mozilla case, all three) licenses. Once that happens, voila - whether intentionally or not, you've created code that the original project can't use, defeating the whole point of the copyleft license and making it harder to use the new code. This can't be completely avoided, but we wanted to find a different approach that would limit the circumstances where this could happen.

So how does MPL 2 handle this?

Our solution was the second sentence of MPL 2.0 Section 3.3:

If the Larger Work is a combination of Covered Software with a work governed by a Secondary License, and the Covered Software is not Incompatible Software, You may additionally distribute such Covered Software under the terms of that Secondary License, so that the recipient of the Larger Work may, at their option, further distribute the Covered Software under the terms of either this License or that Secondary License.

This clause permits someone to combine MPL and GPL ("Secondary License") code, and distribute that combination (the "Larger Work") under the other license, but with two key features that help keep code under the MPL for as long as possible:

1. First, the Larger Work must be "a combination of Covered Software with a work governed by a Secondary License." So you can't just say "I really prefer GPL" - you must combine with another, existing GPL work. Compare this to a traditional dual-license, which does not require you to combine - you can just roll out of bed and say "I've decided to be GPL-only."

2. Second, you can "additionally distribute" under GPL. In other words, you must also comply with MPL, and must make available to your recipients under both MPL and GPL. Someone downstream from you can "at their option, further distribute" under GPL-only or MPL-only - as required by GPL - but you don't have that option. This ensures that one distribution is done under both licenses, and those changes therefore have at least some opportunity to be merged back into the upstream release. Again, this is superior to the dual-license, which can't guarantee any releases under a compatible license.

These clauses give us the best of both worlds. The interests of MPL users are protected by ensuring that it is only used when necessary, and that at least one initial distribution must be under the MPL - and therefore can be integrated back into the original project. At the same time, GPL users are protected by ensuring that there is still a useful path for reuse in GPL projects when that is necessary and makes sense.

Why does all this matter?

MPL continues to grow as a license, and lots of MPL code has to do with technologies that are becoming increasingly interesting to free and open source developers - Javascript, network security, and so on. Making it easier for people across the free software community to use that code is a win for all of us. At the same time, lots of interesting work is being done under the Apache license as well, and making it easier for MPL users to incorporate that has the same benefit. With that in mind, this new compatibility is one of the biggest features of MPL 2.0, and one we hope will be widely understood - and widely used.