Accountapprovers, antispam, confirm, emeritus
4,925
edits
Changes
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?==== ..."
__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?====
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.
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.
====Where can I read about the new licence?====
You can read the <a>Release Candidate 1 text</a>, and a <a>FAQ</a> 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 better protects us against unnecessary incompatible forks.
* Boilerplate goes from 35 lines to 3.
====What would 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 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.
====What would 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
If we upgraded to MPL 2, that list would 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?====
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 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.
====What code would have its licence upgraded?====
All code which is currently tri-licensed. There are a few projects within Mozilla which have a different licensing scheme (e.g. Bugzilla is MPL; Rhino is MPL/GPL). For those projects, whether to shift or not is a discussion to be had with their leadership.
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.
====How would it happen?====
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 / mozilla-inbound
* comm-central
* tamarin-redux
* camino
* tracemonkey
* dom-inspector
* venkman
* chatzilla
* l10n-central
* Any tri-licensed labs projects
* XXXAny more?
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 other repositories into mozilla-central would need to have the license upgraded before the merge was permitted.
====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.
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.
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.
====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.
{{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?====
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.
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.
====Where can I read about the new licence?====
You can read the <a>Release Candidate 1 text</a>, and a <a>FAQ</a> 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 better protects us against unnecessary incompatible forks.
* Boilerplate goes from 35 lines to 3.
====What would 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 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.
====What would 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
If we upgraded to MPL 2, that list would 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?====
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 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.
====What code would have its licence upgraded?====
All code which is currently tri-licensed. There are a few projects within Mozilla which have a different licensing scheme (e.g. Bugzilla is MPL; Rhino is MPL/GPL). For those projects, whether to shift or not is a discussion to be had with their leadership.
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.
====How would it happen?====
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 / mozilla-inbound
* comm-central
* tamarin-redux
* camino
* tracemonkey
* dom-inspector
* venkman
* chatzilla
* l10n-central
* Any tri-licensed labs projects
* XXXAny more?
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 other repositories into mozilla-central would need to have the license upgraded before the merge was permitted.
====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.
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.
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.
====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.
