MPL Upgrade: Difference between revisions

no edit summary
(Created page with "__NOTOC__ {{draft}} This is a draft. It is not complete, probably not accurate and possibly not even truthful. Trust nothing. ==MPL 2 Upgrade FAQ== ====What's this about?==== ...")
 
No edit summary
Line 8: Line 8:
====What's this about?====
====What's this about?====


Mozilla is on the verge of completing an 18-month process to revise the Mozilla Public License (MPL), the licence it has used for all 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.
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].


The leadership of the Mozilla project would like to upgrade the Mozilla codebase to use the new licence, instead of the tri-licensing scheme we currently use. (The MPL 2 is compatible with the LGPL and GPL, like the tri-licence.) We want to make sure the Mozilla community is happy with this upgrade.
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.


====Where can I read about the new licence?====
====Where can I read about the new licence?====
Line 22: Line 22:
* It makes licence compliance simpler, both for us and for people who receive code from us;
* 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;
* 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.
* Compatibility with Apache opens up a wider body of code for us to use within Mozilla;
* New language for GPL compatibility better protects us against unnecessary incompatible forks.
* New language for GPL compatibility makes it simpler for others to use our code in their projects;
* Boilerplate goes from 35 lines to 3.
* Boilerplate at the top of each file goes from 35 lines to 3.


====What would be the difference in terms of included licence compatibility?====
====What would be the difference in terms of included licence compatibility?====
Line 30: Line 30:
(Included licence compatibility is "what licences can code coming into the Mozilla project be under?")
(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 would now be able to include Apache-licensed code in our codebase and even copy it into MPLed files. There are several bits of Apache-licensed code that people have had their eye on over the years.
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?====
====What would be the difference in terms of forward licence compatibility?====
Line 47: Line 47:
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.)
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?====
====Does Mozilla need permission from anyone to change the MPL?====


The agreement that created Mozilla transferred the ability to create new versions of the MPL from Netscape to Mozilla. This is how we can make an MPL 2.
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. But we want to make sure the Mozilla community as a whole is supportive of the move.
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.
Line 60: Line 60:


====How would it happen?====
====How would it happen?====
(This is the current plan; subject to confirmation with project leaders.)


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:
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:
Line 81: Line 83:
====What about the list of Contributors?====
====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. And the Initial Developer section was probably only designed to make sure Netscape got a name check.
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.


However, we understand that Mozilla contributors have a long history of putting their names in the files they touch, and even though it was not designed as a "credit" mechanism, some people do perceive it that way.
However, we understand that Mozilla has a long history of allowing contributors to put their names in the files they touch, and even though Contributors was not designed as a "credit" mechanism, some people do perceive it that way.


Therefore, we propose that the script would preserve the Initial Developer and Contributors of each file in a Contributors list, which would be placed in a separate comment below the licensing information. People would continue to be able to add their names to the list if they chose. However, such a list would not count as a "licence notice" under section 3.4 of the MPL 2, and so would not be unalterable.
Therefore, we propose that the script would preserve the Initial Developer and Contributors of each file in a Contributors list, which would be placed in a separate comment below the licensing information. People would continue to be able to add their names to the list if they chose. However, such a list would not count as a "licence notice" under section 3.4 of the MPL 2, and so would not be unalterable.
Line 89: Line 91:
====How do you spell "licence"?====
====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 to the style police.
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 [mailto:gerv@mozilla.org reported].
Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925

edits