MPL Upgrade: Difference between revisions

Mozilla is on the verge of completing an 18-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 [http://blog.lizardwrangler.com/ Mitchell Baker] (the author of the original MPL) and led by [http://tieguy.org/ Luis Villa], with help from [http://www.gerv.net/ Gervase Markham], [http://lockshot.wordpress.com/ Harvey Anderson], Heather Meeker of [http://gtlaw.com/ Greenberg Traurig], and [http://mpl.mozilla.org/participate/ many helpful commenters].

Many in the Mozilla community, including the project leadership, have reviewed drafts of the upcoming 2.0 version and are eager to adopt it, in place of the tri-licensing scheme we currently use. (The MPL 2 is compatible with the LGPL and GPL, like the tri-licence.)  We'd like to make sure all of the Mozilla community is aware that a decision on upgrading our code to the MPL 2.0 will be made shortly, and if there are any issues with doing so, we'd like to know about them before the licence is finalized.

You can read the [http://mpl.mozilla.org/wp-content/uploads/2011/08/MPL-RC1-typography.html Release Candidate 1 text] ([http://mpl.mozilla.org/participate/rc/ more formats]), and a [http://mpl.mozilla.org/wp-content/uploads/2011/08/Revision-FAQ-RC.html FAQ] about the changes.

====What would be the difference in terms of included licence compatibility?====

As noted above, in addition to the MIT and BSD family of licences, we would 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 would be the difference in terms of forward licence compatibility?====

If we upgraded to MPL 2, that list would technically be the same, with the obvious exception of MPL 1.1.

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. But we want to make sure the Mozilla community as a whole is supportive of the move.

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 ([https://bugzilla.mozilla.org/show_bug.cgi?id=680131 Bugzilla discussion]).

 

Should an upgrade be agreed, any project which is MPL-only (such as Bugzilla) would need to add the Exhibit-B GPL-incompatibility language to their licence header.

 

 

 

More specifically, we would write (or repurpose) 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:

 

 

 

 

 

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 would 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.

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 now plan to remove it along with the rest of the MPL 1.1 header.