About MPL 2.0: Revision Process and Changes FAQ
1. How was MPL 2.0 drafted?
MPL 2.0 was drafted over a period of 21 months in a public process that included extensive feedback from a variety of people, including MPL users, lawyers, and open source community groups like the Free Software Foundation and Open Source Initiative.
2. Is the revision process publicly documented?
Historical documents about the revision process are available from this website.
3. Section 6 of MPL 1.1 says Netscape can update the license, but Mozilla isn't Netscape. Can Mozilla still update the license?
As part of the creation of the Mozilla Foundation, Netscape assigned the ability to publish new licenses to Mozilla, making the Mozilla Foundation Netscape's successor for this purpose.
Upgrading a project from MPL 1.1 to MPL 2.0
4. I use MPL 1.1 for my project. Why should I upgrade to MPL 2.0?
If your project is licensed under MPL 1.1, there are several important reasons why you should move your project to MPL 2.0:
- MPL 2.0 makes compliance simpler, both for you and for people who receive code from you.
- MPL 2.0 provides patent protections for you and your contributors more in line with those of other open source licenses, and allows your entire community to protect any contributor if the contributor is sued.
- Compatibility with Apache and GPL makes code reuse and redistribution easier for you and for the broader open source community.
For a more complete list of reasons why, see the question about "what has changed", below.
5. I am the author of code which I have placed under MPL version 1.1. How do I license my project under MPL 2.0 instead of MPL 1.1?
If you are the author, to change the license from MPL 1.1 to MPL 2.0, replace the old license header with the new header from MPL 2.0 Exhibit A.
6. I am distributing code written by someone else under the terms of MPL 1.1. Can I distribute that code under the terms of MPL 2.0 instead of MPL 1.1? If so, how?
Yes, you can, because MPL 1.1 allows anyone who received code under the terms of MPL 1.1 to distribute under the terms of a later version of the MPL.
To do this, replace the old license header with the new header from MPL 2.0 Exhibit A. If you received the code under only MPL 1.1, and not a combination of the MPL plus a member of the GNU family of licenses (such as the Mozilla Tri-License), then you must also add the text of Exhibit B to the license header.
Changes from MPL 1.1
7. What has not changed between MPL 1.1 and MPL 2.0?
The most important part of the license - the file-level copyleft - is essentially the same in MPL 2.0 and MPL 1.1.
8. What has changed between MPL 1.1 and MPL 2.0?
The primary change is simplification. For example, rather than exactly specifying the amount of time source code must be available, the source code must simply be made available when the executable is made available. License headers have been made shorter, and notification requirements have been simplified. Overall, the license is substantially shorter and should be easier to understand.
In addition, a handful of new features have been added to the license. For example, the license is now compatible with the Apache license - anyone who complies with the terms of the MPL should also be compliant with the Apache license's terms. Similarly, by default, the license allows the code to be distributed alongside code licensed under the GPL or LGPL. In addition, patent protections have been brought more in line with what other licenses (such as Apache) use, while also allowing any member of a community to defend a contributor who has been sued for infringement.
A word-by-word redline of all changes is also available for those seeking to analyze the changes in more detail. Note, however, that the changes are extensive, and you may find that simply reading the new license itself will provide a clearer understanding of its contents.
9. Why did the new license remove the government entities language?
Software licensed under the MPL is a commercial item as defined in 48 C.F.R. 2.101, unless it was originally written at the direction, and for the use, of the US government. As a result, removing the language from the license simplifies the license without changing the rights and responsibilities that US Government users have towards MPL-licensed code.
10. Why doesn't the new license require distributors to include a complete copy of the license with the distributed Source Code?
When MPL 1.1 was written, source code distribution occurred primarily through tarballs and zip files. In contrast, modern software distribution often occurs on a file-by-file basis over the web (e.g., http://hg.mozilla.org). As a result, MPL 2.0 requires distributors to tell recipients how to get the license (for example, by linking to it in the header of a single source file), rather than requiring them to distribute the entire license itself. In most cases, distributing the license with the code - as was required in MPL 1.1 - is still the best and easiest way to meet this requirement. However, given the diversity of modern source code and executable distribution practices, it was sensible to give more flexibilty and place the burden on the distributor to pick an effective notification mechanism.
11. Why did the new license remove the reference to build scripts and documentation from the definition of Source Code?
If you choose to license software under the MPL, it is considered a best practice to release all of the software, including interface files and build scripts, under the MPL. However, since these terms only apply to specific types of software distributed in specific ways, and MPL is now applied to a wide variety of software distributed in a number of different ways, we removed these reference and will allow the broader definition of "preferred form" to be interpreted as appropriate to a given situation.
12. Section 3.2 now requires that I "inform" recipients how they can obtain the Source Code form. Could you give some examples of what it means to "inform"?
Historically, informing recipients of source availability was done by means of the "About" box of a piece of software. However, other mechanisms for informing users are also acceptable when appropriate for the type of software being distributed. As a specific example, when using MPL-licensed JavaScript on a website, recipients could be informed by having links to the source in the "Legal" or "Notices" section of the website. More generally, notices should be put in the place a reasonable person is likely to look for legal information about the software they have recieved.
13. Unlike MPL 1.1, MPL 2.0 contains explicit provisions for distribution alongside GPL- and LGPL-licensed code. Why?
Providing an explicit mechanism by which MPL and GPL code can be distributed together has several significant benefits:
It allows elimination of the common dual and tri-license approach, which reduces license proliferation, since (for compatibility and proliferation purposes) each dual-license and tri-license is a separate license.
Along with Apache compatibility, it creates a series of upwards-compatible free software licenses covering much of the world's free and open source software.
It helps protect the original licensor's ability to reintegrate modifications made downstream, by requiring that the initial distribution of changes occurs under both licenses and not just the GPL.