MPL Upgrade

MPL 2 Upgrade FAQ

What's this about?

Mozilla has now completed a 21-month process to revise the Mozilla Public License (MPL), the licence it has used for most new code since the original release of the source code in 1998. The result is a licence which is about half the length, has many provisions removed which have become onerous to comply with, and has better compatibility with other licences. This work has been overseen by Mitchell Baker (the author of the original MPL) and led by Luis Villa, with help from Gervase Markham, Harvey Anderson, Heather Meeker of Greenberg Traurig, and many helpful commenters.

It has been decided that Mozilla will be changing our codebase to use the new licence.

How will this happen?

(This is the current plan; subject to confirmation with project leaders.)

We will develop a script to replace existing tri-licence blocks with the MPL 2 boilerplate (which is only 3 lines long). We would run it against the following repositories:

• mozilla-central
• comm-central
• tamarin-redux
• camino
• dom-inspector
• venkman
• chatzilla
• l10n-central
• Any active labs projects using the MPL
• NSS trunk (which is still in CVS)

If you feel this list is incorrect by omission or commission, please let us know.

Repos which feed into mozilla-central (e.g. mozilla-inbound, tracemonkey) would need to merge the changes from mozilla-central, and run the script to upgrade any new files they might have created, before making any further merges into to mozilla-central.

Some repositories such as release repositories are effectively forks of some of the above code from earlier points in time. We would not plan to upgrade the licence on those repositories, but just let them fall out of use naturally.

Merges from any other repositories into mozilla-central would need to have the license upgraded before the merge was permitted.

In terms of mechanics, after various dry-runs which made sure the script was working correctly, we will probably declare a "relicensing day" where the trees would be closed to other changes, and we would make all of the upgrades and various back-and-forth merges, before asking people to update their local trees.

Where can I read about the new licence?

You can read the text, a FAQ about the licence and and another FAQ specifically about the changes.

Why is it better?

Briefly:

• It makes licence compliance simpler, both for us and for people who receive code from us;
• It provides stronger patent protections for us and our contributors;
• Compatibility with Apache opens up a wider body of code for us to use within Mozilla;
• New language for GPL compatibility makes it simpler for others to use our code in their projects;
• Boilerplate at the top of each file goes from 35 lines to 3.

What will be the difference in terms of included licence compatibility?

(Included licence compatibility is "what licences can code coming into the Mozilla project be under?")

As noted above, in addition to the MIT and BSD family of licences, we will now be able to include Apache-licensed code in our codebase and even copy it into MPLed files. This makes re-use of Apache code easy. There are several bits of Apache-licensed code that people have had their eye on over the years.

What will be the difference in terms of forward licence compatibility?

(Forward licence compatibility is "what projects can our code be used in?")

Several years ago, Mozilla relicensed most of its code under an MPL/LGPL/GPL tri-licence to make our code usable in a wider variety of projects. The tri-licence makes our code forwardly-compatible with the following existing licences:

• MPL 1.1, MPL 2.0, and later versions
• LGPL 2.1, LGPL 3.0, and later versions
• GPL 2.0, GPL 3.0, and later versions
• AGPL 3.0, and later versions

When we upgrade to MPL 2, that list will technically be the same, with the obvious exception of MPL 1.1.

However, there is one twist. The Free Software Foundation is of the opinion that the Apache License 2.0 is not compatible with the GPL 2.0, only with the GPL 3.0. One goal of relicensing is to allow us to include Apache-licensed code in our codebase. Once that had happened, it would no longer be possible to build a GPL 2.0 version of the entire Mozilla codebase. Anyone wanting to use the Mozilla codebase as a whole under the terms of the GPL would need to use GPL 3.0. (The parts which did not contain Apache code could still be used under GPL 2.0.)

Does Mozilla need permission from anyone to change the MPL?

No. The agreement that created the Mozilla Foundation transferred the ability to create new versions of the MPL from Netscape to the Foundation. This is how we can make an MPL 2.

No permission is needed from any contributor to upgrade the codebase from MPL 1.1 to MPL 2 because the MPL 1.1 contains within itself a provision which allows software under 1.1 to be redistributed under a later version of the licence.

What code would have its licence upgraded?

All code in active projects which is currently under the MPL (perhaps in combination with other licenses).

There are two projects within Mozilla which have historically had greater independence - Bugzilla and Rhino. Neither uses the usual tri-licensing scheme - Bugzilla is MPL 1.1 only, and Rhino is MPL/GPL. For those projects, whether to shift or not is a discussion to be had with their leadership (Bugzilla has decided to switch.).

Any project which is MPL-only (such as Bugzilla) will need to add the Exhibit-B GPL-incompatibility language to their licence header.

What about the list of Contributors?

The list of Contributors in the license header was required by the MPL 1.1 but, in line with other modern free software licences, is not required by MPL 2. In practice, it was neither a complete nor accurate list of people with a copyright interest in the particular file. After discussion, most people in the project think it is not useful, and can be a source of merge problems, so we will be removing it along with the rest of the MPL 1.1 header.

How do you spell "licence"?

This FAQ was written by Gerv, a Brit, who spells the noun "licence" and the verb "license", except when he is referring to the official titles of licences written by Americans, such as the Mozilla Public License or the Apache License. Any deviations from this policy should be reported.