Changes

Mozilla is on the verge of completing an 18has 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 [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 [http://groups.google.com/group/mozilla.governance/msg/50954ce2033f7c0c It has been decided] that Mozilla will be changing our codebase to use the Mozilla community, including new licence. ====How will this happen?==== (This is the current plan; subject to confirmation with project leadership, have reviewed drafts of leaders.)  We will develop a script to replace existing tri-licence blocks with the upcoming MPL 2boilerplate (which is only 3 lines long).0 version and are eager to adopt We would run it, in place of against the trifollowing repositories: * mozilla-central* comm-central* tamarin-redux* camino* dom-inspector* venkman* chatzilla* l10n-licensing scheme we currently usecentral* Any active labs projects using the MPL* NSS trunk (which is still in CVS) <i>If you feel this list is incorrect by omission or commission, please let us know. </i> Repos which feed into mozilla-central (The MPL 2 is compatible with e.g. mozilla-inbound, tracemonkey) would need to merge the LGPL changes from mozilla-central, and GPLrun the script to upgrade any new files they might have created, like before making any further merges into to mozilla-central. Some repositories such as release repositories are effectively forks of some of the tri-licenceabove code from earlier points in time.) We'd like would not plan to make sure all of upgrade the Mozilla community is aware that a decision licence on upgrading our code those repositories, but just let them fall out of use naturally. Merges from any other repositories into mozilla-central would need to have the MPL 2license upgraded before the merge was permitted.0  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 made shortlyclosed to other changes, and if there are any issues with doing sowe would make all of the upgrades and various back-and-forth merges, we'd like before asking people to know about them before the licence is finalizedupdate their local trees.

You can read the [http://mplwww.mozilla.org/wp-contentMPL/uploads2.0/2011/08/MPL-RC1-typography.html Release Candidate 1 text] (, a [http://mplwww.mozilla.org/participateMPL/rc2.0/ more formatsFAQ.html FAQ]), about the licence and and a another [http://mplwww.mozilla.org/wp-contentMPL/uploads/2011/082.0/Revision-FAQ-RC.html FAQ] specifically about the changes.

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

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

If When we upgraded upgrade to MPL 2, that list would will 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 has decided to add the Exhibit-B GPL-incompatibility language to their licence headerswitch. ====How would it happen?==== (This is the current plan; subject to confirmation with project leaders.)  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: * 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) <i>If you feel this list is incorrect by omission or commission, please let us know.</i> 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 dryAny project which is MPL-runs which made sure the script was working correctly, we would probably declare a "relicensing day" where the trees would be closed only (such as Bugzilla) will need to other changes, and we would make all of add the upgrades and various backExhibit-andB GPL-forth merges, before asking people incompatibility language to update their local treeslicence header.

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 will be removing it along with the rest of the MPL 1.1 header.