MPL Upgrade
MPL 2 Upgrade
Introduction
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. It has been decided that Mozilla will be changing our codebase to use the new licence.
The Plan
We have a script which replaces existing tri-licence blocks with the MPL 2 boilerplate (which is only 3-5 lines long), and adds licence blocks to files without it (if the file type is recognized). 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 (in CVS)
- NSPR trunk (in CVS)
If you feel this list is incorrect by omission or commission, please let us know.
The script excludes files and directories which are known to have a different licence (e.g. third party libraries).
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 licence upgraded before the merge was permitted.
While getting review of the exact patches checked in will often be unfeasible (because it would lengthen tree closure), mostly-the-same patches, created by running the script over the current tree, could be posted a few days before the relicensing took place, for interested parties to review.
Main Codebase: Step By Step Procedure
- Close mozilla-inbound, mozilla-central and comm-central
- Merge mozilla-inbound both ways with mozilla-central, to make them identical
- Relicense mozilla-central
- Build Firefox
- Push to try (everything: try: -b do -p all -u all -t all)
- Relicense comm-central
- Build Thunderbird
- Push to try (everything: try: -b do -p all -u all -t all)
- Check that the try runs are green
- Check in mozilla-central and comm-central
- Merge from mozilla-central to mozilla-inbound
- Reopen mozilla-central, comm-central and mozilla-inbound
- Relicense l10n-central
- Check in l10n-central
All other trees can be done at separate times, in coordination with their (smaller) development communities. It's just the big mozilla-central/comm-central closing which needs project-wide coordination.
Q&A
You mistakenly added an MPL 2 licence header to my file/directory/external library! What do I do?
Revert the incorrect changes. I've tried hard to avoid changing the licence on (or, more likely, adding new licences to) inappropriate files, but if I screwed up somewhere, I'm afraid you'll just have to forgive me and change them back, by reverting that part of the patch and then checking in again. My sincere apologies. I'd appreciate it if you told me what went wrong so I can fix the script.
There's some files in the tree which are still MPL 1.1! What do I do?
There are a number of reasons this might be the case. If your case doesn't fit any of these reasons, let me know about it.
- You are looking at a tree I haven't relicensed yet (all of them, at the moment!)
- You are looking at a tree that is not slated for relicensing, such as a historical branch (see list above)
- You are looking at a tree which pulls from mozilla-central, but the changes have not worked their way through yet, e.g. mozilla-beta or mozilla-release
- It's code mastered in another Mozilla repo, e.g. NSPR or NSS, which live in CVS. It will be relicensed upstream and we'll get the benefit when we import a new release which contains the relicensing.
- It's code which comes from an upstream project but is nevertheless MPLed, e.g. cairo and libpixman. The decision to relicense in this case lies with the upstream project; but the MPL 1.1 gives us the right to use the code under MPL 2.
There's a file that has no licence, and I think it should have an MPL 2 licence. What do I do?
Well, if it's your area of the code and you know what's going on with that file, you can give it one. If it has no file extension, or a weird one, that's one reason it may well have been missed in the licence addition process. But if you are in any doubt, ask.
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 licence 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.
