File-scoped copyleft. The MPL files stay open when you ship a binary, modified or not. Your own separate files stay yours.
On this page
What it does
MPL-2.0 draws its copyleft line around files, not around your product. Copyleft means the license requires the covered code to stay available under the same license. Every file carrying the MPL header stays under the MPL, and anything you write in your own separate files does not. That is how Firefox-era code ends up inside closed products without pulling them open. Section 3.1 hands the Source Code Form of the Covered Software to recipients under the MPL, and section 3.2 says an executable distribution has to tell them how to get it. Covered Software means the licensed files as you distribute them, so the duty does not depend on whether you edited anything.
Details
Two readings cost teams money here. The first is that the MPL pulls the whole product open, which it does not: your separate files are yours, and linking is not the deciding factor. The second is that you owe nothing because you did not modify anything. That one is wrong. The duty in sections 3.1 and 3.2 attaches to the covered files you distribute, edited or untouched. Modification changes what that source contains, not whether you owe it. Section 3.3 is the GPL bridge. A Larger Work that combines MPL files with GPL, LGPL or AGPL code may also go out under that Secondary License, unless the files are marked Incompatible With Secondary Licenses. A hosted service owes nothing at all, because distribution means handing a copy to someone and the MPL has no network clause.
Pros
- You can link the library from closed code in the way the license describes.
- File-level reciprocity is easier to isolate than GPL-style whole-work copyleft.
Cons
- Vendoring or statically linking can pull more of your tree into the covered set than a dynamic link would.
- The source-offer duty is real the moment you distribute binaries that include modified covered files.
What it allows and requires
Choose a category to see the full grant in one scannable list. Permissions show what the license allows, limits show what it withholds, and obligations show the conditions your release process must satisfy.
Permissions
Commercial use
You may ship the code inside a paid product. The license does not restrict commercial use.
Modify
You may change the code, including keeping those changes private, unless a later obligation says otherwise.
Distribute
You may give copies to others. Distribution is what usually turns notice and source duties into real work.
Private use
Use inside your company, including internal forks, does not by itself trigger distribution duties.
Patent use
These licenses typically include a patent grant covering the licensed files. Read the grant before relying on it in a high-stakes deal.
Limits
Hold liable
The authors disclaim warranty. Recipients cannot hold them liable for damages arising from the software, except where law forbids that disclaimer.
Use trademark
The license is not a trademark license. Names, logos and product marks stay with their owners unless a separate grant says otherwise.
Open your product
File- or library-scoped copyleft does not, on its face, force you to open your entire application. Reciprocity stays on the covered files.
Obligations
Include copyright
Keep copyright notices on the covered files you distribute.
Include license
Keep the license text with the covered files, and say that those files are under this license.
Disclose source
Covered Software you distribute in executable form must have source available under the MPL, modified or not.
Same license
Covered files stay under the MPL. Your own separate files can stay under other terms.
What MPL-2.0 requires when you ship
When you distribute a binary that includes MPL-2.0 code, notice still travels with the copy, and the corresponding source has to be available under the same license. Internal use without a copy leaving the company is a different situation. The list below is the shipping work: what a recipient of that binary can demand, and what you record so a buyer can see it.
You are meeting sections 3.1 and 3.2 when everyone who gets your executable can obtain the source of the MPL files, whether or not you touched them.
You have done the telling part when your distribution says where that source lives, since section 3.2 asks you to inform recipients, not just to have it somewhere.
You keep your own code out of it when your work sits in separate files rather than inside the MPL-headered ones, because the license scopes by file.
You have handled notices when the MPL header stays in every covered file you pass on and the license text travels with the distribution.
You are clear for a hosted product when nothing leaves your servers, because the MPL has no clause that treats network access as distribution.
The duties named in MPL-2.0
Notice still travels with the copy. On top of that, MPL-2.0 names a source duty. These are the conditions in the text. The how-to above is when they become real work.
Include copyright
Keep copyright notices on the covered files you distribute.
Include license
Keep the license text with the covered files, and say that those files are under this license.
Disclose source
Covered Software you distribute in executable form must have source available under the MPL, modified or not.
Same license
Covered files stay under the MPL. Your own separate files can stay under other terms.
Things to be aware of
- Teams file the whole thing under 'we did not modify it, so nothing applies'. Publish the covered files' source anyway, or link to the upstream release you built from.
- Teams assume the MPL pulls their whole codebase open and rip the dependency out. Check the file boundary first; separate files stay closed by design.
- Nobody tells recipients where the source is, so section 3.2 is missed even though the code is public. Put the URL in the release notes and in the notice file.
- A package declares MPL-2.0-no-copyleft-exception and is handled as plain MPL-2.0. That variant drops the option to relicense a larger work under the GPL, so read the declared id.
What the Mozilla Public License 2.0 does not do
Search results often flatten Mozilla Public License 2.0 into a slogan. These are the usual misreads. MPL-2.0 is a grant with conditions, not a permission to skip the paperwork below.
- MPL-2.0 does not pull your whole application open. Reciprocity stops at files that carry the MPL header.
- It does not wait for you to modify a covered file. Sections 3.1 and 3.2 attach to Covered Software you distribute in executable form, edited or untouched.
How MPL-2.0 differs from nearby licenses
These licenses are often confused with MPL-2.0, but their release duties differ. Each row summarizes what the license requires when you ship. Open the linked page for the full checklist.
- MPL-2.0
- File-scoped copyleft. The MPL files stay open when you ship a binary, modified or not. Your own separate files stay yours.
- MPL-1.1
- The 1998 Mozilla license. Its source duty attaches to the files you modified, not to every MPL file you ship, and it has no GPL bridge.
- EPL-2.0
- Eclipse-family copyleft scoped to each Contribution. It reaches GPL compatibility only when the project designates a Secondary License.
- GPL-2.0-or-later
- GPL-2.0 asks for source when you hand someone a binary. Running it on your own servers triggers nothing. The trigger is shipping a copy, not merely using it.
Common questions about Mozilla Public License 2.0
Answers to common questions about what Mozilla Public License 2.0 requires, when its duties apply, and what evidence belongs with a release.
What is the Mozilla Public License 2.0?
MPL-2.0 draws its copyleft line around files, not around your product. Copyleft means the license requires the covered code to stay available under the same license. Every file carrying the MPL header stays under the MPL, and anything you write in your own separate files does not. That is how Firefox-era code ends up inside closed products without pulling them open. Section 3.1 hands the Source Code Form of the Covered Software to recipients under the MPL, and section 3.2 says an executable distribution has to tell them how to get it. Covered Software means the licensed files as you distribute them, so the duty does not depend on whether you edited anything.
What does MPL-2.0 require when you ship a product?
You are meeting sections 3.1 and 3.2 when everyone who gets your executable can obtain the source of the MPL files, whether or not you touched them. You have done the telling part when your distribution says where that source lives, since section 3.2 asks you to inform recipients, not just to have it somewhere. You keep your own code out of it when your work sits in separate files rather than inside the MPL-headered ones, because the license scopes by file. You have handled notices when the MPL header stays in every covered file you pass on and the license text travels with the distribution. You are clear for a hosted product when nothing leaves your servers, because the MPL has no clause that treats network access as distribution.
Does hosting a product that uses MPL-2.0 trigger extra duties?
Hosting alone usually does not trigger the source duty for MPL-2.0. Shipping a binary, a container, or an on-prem build does. Notice still travels with any copy you hand over.
Can I keep my application closed if I use MPL-2.0?
MPL-2.0 is library-scoped copyleft. Your application can stay closed if recipients can replace the library with their own build. Static linking makes that expensive. The library itself still ships with corresponding source and notices. Confirm the linking story on the component, then record it.
What is corresponding source for MPL-2.0?
Corresponding source is the source a recipient needs to build and run the same binary, including scripts and interface files the license names. Hosting a repository URL can be an offer. The offer has to match what you actually shipped. SourceTrust records that a person on your team confirmed the offer. It does not publish your source and does not host a mirror.
How is MPL-2.0 different from Mozilla Public License 1.1?
MPL-2.0 asks this: File-scoped copyleft. The MPL files stay open when you ship a binary, modified or not. Your own separate files stay yours. Mozilla Public License 1.1 asks this: The 1998 Mozilla license. Its source duty attaches to the files you modified, not to every MPL file you ship, and it has no GPL bridge. Open the Mozilla Public License 1.1 page for what that license requires when you ship. Do not treat the SPDX ids as interchangeable because the short names look similar.
Where do I record MPL-2.0 for a buyer?
MPL files carry their license in a header, so the fetcher usually finds real MPL text inside the package artifact and compares it against the declared id. A confirmed match fills the text in; anything else waits for a person to accept it. The catalog marks MPL-2.0 as copyleft, so a source offer item appears on the checklist in the Distributed binary and Mixed contexts, and never for a SaaS-only project. SourceTrust does not publish your source or host a mirror.
Where do I record MPL-2.0 for a buyer?
MPL files carry their license in a header, so the fetcher usually finds real MPL text inside the package artifact and compares it against the declared id. A confirmed match fills the text in; anything else waits for a person to accept it.
The catalog marks MPL-2.0 as copyleft, so a source offer item appears on the checklist in the Distributed binary and Mixed contexts, and never for a SaaS-only project. SourceTrust does not publish your source or host a mirror.
Read /docs/auto-fetch-license for how the fetch and the comparison work.
See also
The hub is the pillar for this cluster. Sibling licenses are the other spokes. Product FAQ links explain how SourceTrust records the duty, not the license text itself.
Practical guidance for procurement review, not legal advice. Confirm high-stakes use with counsel.