MPL 2.0 FAQ
About This FAQ
This is the Mozilla Public License (MPL) version 2.0 FAQ. It aims to answer the most common questions people have about using and distributing code under the MPL.
Please note that, while this FAQ is intended to be accurate and helpful, it is not the license, and may not cover important issues that affect you and your specific situation. As a result, reading the FAQ should not serve as a substitute for reading the license itself, or for seeking legal advice from a lawyer.
If you see any errors in this FAQ, or have suggestions for further questions, please email licensing@mozilla.org.
The MPL version 1.1 FAQ is still available here but should not be used except as a reference for that license.
Last updated on January 30th, 2024
About MPL
Q1: What is the Mozilla Public License?
The MPL is a simple copyleft license. The MPL's "file-level" copyleft is designed to encourage contributors to share modifications they make to your code, while still allowing them to combine your code with code under other licenses (open or proprietary) with minimal restrictions.
Q2: Why yet another open source license?
The MPL fills a useful space in the spectrum of free and open source software licenses, sitting between the Apache license, which does not require modifications to be shared, and the GNU family of licenses, which requires modifications to be shared under a much broader set of circumstances than the MPL.
Q3: Who maintains the MPL?
The MPL is maintained by the Mozilla project, a global non-profit community dedicated to building openness, interoperability and individual empowerment into the Internet. The Mozilla project operates under a system of distributed authority known a the Module Ownership System. Like other Mozilla modules, the MPL has a module owner and peers who are responsible for maintaining the license. The current owner and peers are listed at the Module Owners page.
Using and Distributing Software Under the License
Q4: I want to use the Mozilla Public License for software that I have written. What do I have to do?
To apply the Mozilla Public License to software that you have written, add the header from Exhibit A of the license to each source code file in your project. Sample headers for various commenting styles are available here.
Alternately, in ecosystems where Software Package Data Exchange® (SPDX) Identifiers are the preferred format for communicating license information, add this header (in a comment style appropriate to your programming language) to each source code file in your project:
// SPDX-License-Identifier: MPL-2.0
You may also add additional accurate notices of copyright ownership, such as the name of the copyright holder, but this is not necessary.
Q5: I want to use software which is available under the MPL. What do I have to do?
Nothing. Like all other free and open source software, software available under the MPL is available for anyone (including individuals and companies) to use for any purpose. The MPL only creates obligations for you if you want to distribute the software outside your organization.
Q6: I want to distribute software which is available under the MPL, either changed or unchanged, within my organization. What do I have to do?
Nothing. The right to private modification and distribution (and inside a company or organization counts as 'private') is another right guaranteed by free and open source software licenses, including the MPL.
Q7: I want to distribute (outside my organization) complete and unchanged executable programs built from MPL-licensed software by someone other than me. What do I have to do?
As long as the people who distributed the program to you have complied with the MPL, typically nothing. To check and see if the people who distributed the program to you have complied with the MPL, look for the notice that tells you where the software is available in Source Code form (i.e., check that it complies with Section 3.2(a)), and then check that the Source Code is available in that place, including a notice that informs you that the Source Code is available under the terms of the MPL (i.e., check that it complies with Section 3.1).
If you are only distributing libraries, or are only distributing some parts of the program as you received it, it could be that you need to take extra steps to make sure that users of your program are appropriately informed of their rights, as required by section 3.2(a).
In the case of Mozilla Firefox, the Mozilla-provided executable programs already meet the requirements of Section 3, including the notices required by Section 3.1 and 3.2.
If you want to add your own terms when you distribute the software, Section 3.2(b) requires that those terms must not restrict a recipient's rights under the MPL, and if you offer a warranty on the software, Section 3.5 requires you to make clear that it is offered by you alone.
Q8: I want to distribute (outside my organization) executable programs or libraries that I have compiled from someone else's unchanged MPL-licensed source code, either standalone or part of a larger work. What do I have to do?
You must inform the recipients where they can get the source for the MPLed code in the executable program or library you are distributing (i.e., you must comply with Section 3.2). You may distribute any executables you create under a license of your choosing, as long as that license does not interfere with the recipients' rights to the source under the terms of the MPL.
Q9: I want to distribute (outside my organization) MPL-licensed source code that I have modified. What do I have to do?
To see the complete set of requirements, read the license. However, generally:
You must inform the recipients that the source code is made available to them under the terms of the MPL (Section 3.1), including any Modifications (as defined in Section 1.10) that you have created.
You must make the grants described in Section 2 of the license.
You must respect the restrictions on removing or altering notices in the source code (Section 3.4).
Q10: I want to distribute (outside my organization) an executable program based on MPL-licensed source code that I have modified. What do I have to do?
You must make available the MPL-licensed portions of the source code as described in the previous question, and inform the recipients how they can obtain such source code (Section 3.2).
Other Common Questions
Q11: How 'viral' is the MPL? If I use MPL-licensed code in my proprietary application, will I have to give all the source code away?
No. The license requires that Modifications (as defined in Section 1.10 of the license) must be licensed under the MPL and made available to anyone to whom you distribute the Source Code. However, new files containing no MPL-licensed code are not Modifications, and therefore do not need to be distributed under the terms of the MPL, even if you create a Larger Work (as defined in Section 1.7) by using, compiling, or distributing the non-MPL files together with MPL-licensed files. This allows, for example, programs using MPL-licensed code to be statically linked to and distributed as part of a larger proprietary piece of software, which would not generally be possible under the terms of stronger copyleft licenses.
Q12: How does the scope of the MPL's copyleft compare with the LGPL and GPL's copyleft?
Broadly speaking, the scope of the MPL, LGPL, and GPL can be summarized this way:
- MPL: The copyleft applies to any files containing MPLed code.
- LGPL: The copyleft applies to any library based on LGPLed code.
- GPL: The copyleft applies to all software based on GPLed code.
However, we would recommend reading the licenses to better understand their scope, and in particular, to understand how the LGPL and GPL define "based on."
Q13: May I combine MPL-licensed code and BSD-licensed code in the same executable program? What about Apache?
Yes to both. Mozilla currently does this with BSD-licensed code. For example, libvpx, which is used in Firefox to decode WebM video, is under a BSD license.
Q14: May I combine MPL-licensed code and (L)GPL-licensed code in the same executable program?
Yes, by creating a "Larger Work" under the terms of Section 3.3. In particular, three requirements must be met:
The software must not be “Incompatible With Secondary Licenses.” Software can become “Incompatible With Secondary Licenses” in one of two ways: the original author marks it as such by adding the file header in Exhibit B, or the original author published the software under MPL 1.1 and did not dual- or tri-license the code with the (L)GPL.
The Larger Work must be "a combination of Covered Software with a work governed by one or more Secondary Licenses." So you can't just say "I really prefer (L)GPL" - you must have a need to combine with another, existing GPL work. (This is different from a traditional dual-license, which does not require you to combine, and instead allows you to simply say "I've decided to be GPL-only.")
You must "additionally distribute" under (L)GPL. In other words, you must make the MPL-licensed source code available to your recipients under both MPL and (L)GPL. Someone downstream from your recipients can then take under (L)GPL-only or MPL-only. This is different from a traditional dual-license, which never requires publication under both licenses, and so always gives you the option of releasing incompatibly-licensed code.
No GPL-compatible license can perfectly preserve the original author's ability to reuse downstream derivatives, but the last two restrictions serve to increase the probability that such reuse can occur in the broadest possible set of circumstances.
We have written a document explaining how to do this in practical terms, i.e. what to do about license headers and so on.
Q15: Does Sec. 3.3's ability to mix with other licenses lead to more license proliferation?
Mozilla's experience with MPL 1.1, and the experience of some of our advisors, was that in practice license incompatibility is often resolved by the use of custom additional permissions or dual- and tri- licenses. Each combination of dual or tri-license, or custom additional permissions, further complicates license interaction and proliferation analysis. We feel that Sec. 3.3, by replacing these ad-hoc solutions with a single, standardized solution for the most common situation, should reduce, rather than increase, the practical risk of license proliferation.
Q16: Is "minified" JavaScript Source Code?
No. Minified JavaScript, while not an "executable" in the software engineering sense of the word, is difficult for humans to read, edit, and modify. As such, it is not "the preferred form for modification" and so it is not Source Code as defined by the license. Therefore, minified JavaScript is the Executable form, and the responsibilities set out in the license for distribution of the Executable form should be met when you distribute minified MPL-licensed JavaScript.
This means, among other things, that you do not need to, and probably should not preserve the MPL boilerplate (which begins "This Source Code Form...") when minifying JavaScript. However, you do need to comply with section 3.2(a) by informing the recipients of the minified source how they can obtain a copy of the source code. How exactly you do this will depend on how they can obtain that copy, but one way would be to include a comment with a link to the source code in either the page which uses the JavaScript or in the JavaScript file itself.
Note that treating minified JavaScript as an executable increases distributor flexibility by allowing MPL-licensed code to be combined into a single file with non-MPL JavaScript source code without requiring the non-MPL code to be distributed under the terms of the MPL.
Q17: What does "distribute" mean?
The MPL uses "distribute" in the sense of delivery of a copy of the software to another person or entity. We do not use distribute to mean "make available" in the sense of "making functionality available over the web without delivery of a copy of the software." So e.g. in a web-based application, the code which runs on the server is not 'distributed' to the user, but the code which is sent to the client (e.g. HTML, CSS, JavaScript) does count as 'distributed'.
Q18: Should MPL be used for non-software works?
MPL was written with software in mind, and should generally only be used for software. However, for consistency and simplicity, it may be appropriate to use the MPL for non-software works (such as documentation, images, and sound files) that are written primarily for use in MPL-licensed software.
Q19: Can I remove or change notice statements which are displayed by a piece of software?
Section 3.4 prohibits most changes to license notices that are seen when looking at the source code. We do not encourage changing licensing and notice statements which are displayed when the software is executed. However, such changes are permitted by the license, so that source code can be reused between software with very different user interfaces.
Q20: I've downloaded a copy of some MPL software. Am I an "owner" of that software for purposes of Section 1.1?
No. Merely downloading the software does not make you an owner for the purposes of Section 1.1.
Q21: Does the MPL 2.0 give me permission to make my own license by changing the MPL?
Yes but, as with MPL 1.1, we strongly discourage you from doing so. It will almost certainly make your software much less popular and less widely used. Software developers and companies are already aware of and understand popular licenses like the MPL. If you create your own, they will have to perform a legal assessment of your changes - and may conclude it's not worth the effort to do so. Or, you may accidentally make your software incompatible with the Free Software Definition or the Open Source Definition, or with the other commonly-used free software licenses that MPL 2.0 is compatible with.
If you like the MPL 2.0, just use it as-is - it is a clear, modern, internationalized, generic license. There is nothing Mozilla-specific, or specific to a particular country or project, in its licensing terms.
For more information on the problems that creating your own license causes, see the Wikipedia article on license proliferation.
Q22: Does MPL 2.0 require that the MPL 2.0 license notice header be included in every file?
The license notice must be in some way "attached" to each file. (Sec. 1.4.) In cases where putting it in the file is impossible or impractical, that requirement can be fulfilled by putting the notice somewhere that a recipient "would be likely to look for such a notice," such as a LICENSE file in the same directory as the file. (Ex. A.) The license notice is as short as possible (3 lines) to make it easy to put in as many different types of files as possible.
While the license permits putting the header somewhere other than the file itself, individual files often end up being distributed on their own, without the rest of the software they were authored with. As a result, putting the license notice in the file is the surest way to ensure that recipients are always notified.
For your convenience, Mozilla has produced boilerplate headers formatted with several common 'comment' syntaxes, suitable for copying and pasting.
Q23: What does "used" mean in the definition of Contributor Version (Sec. 1.2)?
“Used” in Section 1.2 means an action taken in the process of creating a Contribution or Modification.
Q24: "Contributor" means one who creates "Covered Software", and "Covered Software" includes "the Executable Form" of MPL-licensed source code. Does this mean that compiling unmodified code to create an executable makes someone a Contributor?
No. We intend Contributors to be those who have created an addition or change to the program that adds new expression -- copyrightable material -- to pre-existing code. Mere compilation is not an act of authorship it does not create such an addition, and so does not make you a Contributor.
Q25: What happens if someone doesn't use the per-file boilerplate, and just ships a copy of the full MPL 2 with their code?
The code is licensed under the plain MPL 2. It is not considered Incompatible with Secondary Licenses. Making code Incompatible with Secondary Licenses requires an active choice on the part of the licensor; it is not the default. The notice in Exhibit B is not considered "attached" merely by being present as the Exhibit B of a copy of the full MPL 2.
The only exception is if the code used to be straight MPL 1.1 and was upgraded to MPL 2, in which case it would be Incompatible with Secondary Licenses (Sec. 1.5 b).
Q26: I would like to distribute source code by using a courier or other physical mechanisms. Is this "reasonable" for purposes of meeting my obligations under Section 3.2(a)?
In modern software development, distribution happens almost exclusively over the internet, because of the low cost and convenience. While the MPL allows for alternatives when necessary, in general any mechanism (such as a courier) that adds cost and complexity without a specific, necessary purpose is not reasonable, and so does not comply with the requirements of Section 3.2(a).
Q27: Can I use a machine-readable header in my source code files to indicate that the file is under the MPL?
Use of a standards-compliant, machine-readable license metadata header in source code files can be compliant with the notice-related goals and requirements of MPL 2.0.
MPL 2.0 recommends the use of the specific text in Exhibits A or B in order to provide consistency for recipients of source code. However, the license was drafted with the understanding that not all technical communities may be able to, or wish to, use the header in the recommended manner. In particular, Exhibit A notes that it may not be "desirable" to include the standard header in all files, and describes some alternative mechanisms.
As a result, use of a machine-readable mechanism, such as a Software Package Data Exchange® (SPDX) ID, can meet the requirements of the license.
Where a relevant technical community's stated policy is to require such machine-readable license metadata, such as those communities that recommend use of SPDX IDs or the REUSE project's licensing data specification, we recommend following that community's practice.