The Mozilla Public License 2.0 (MPL 2.0) is a "weak" or file-level copyleft license: any file that contains MPL-covered code must stay open source and MPL-licensed when distributed, but you can freely combine those files with proprietary code kept in separate files without infecting your whole codebase. Maintained by the Mozilla Foundation and used by projects such as Firefox, Thunderbird, and Terraform (through its final MPL release), MPL 2.0 is designed to occupy the middle ground between permissive licenses like MIT and strong copyleft licenses like the GPL. It also includes an explicit patent grant and a compatibility mechanism that lets MPL code coexist with GPL projects.
This article explains how MPL 2.0 works in general terms. It is not legal advice — consult a qualified attorney for guidance on your specific circumstances.
What the MPL 2.0 Permits and Requires
MPL 2.0 grants broad rights while attaching copyleft at the granularity of individual source files.
| Category | Details |
|---|---|
| Permissions | Commercial use, modification, distribution, private use, and an explicit patent grant from contributors |
| Conditions | Disclose the source of any modified MPL-covered files; keep those files under MPL; preserve notices; changes to MPL files must be shared under MPL |
| Limitations | No warranty; no liability; no trademark rights; patent grant terminates on patent litigation against the software |
The defining rule is file-level reciprocity. If you modify a file that is under the MPL, that file must remain MPL and its source must be made available. But files you author separately — even in the same application — are not pulled under the MPL. This is what makes MPL "weak" copyleft compared to the GPL's "strong," whole-work copyleft.
Is the MPL Copyleft or Permissive?
The MPL is weak (file-level) copyleft — a deliberate compromise. It is more restrictive than permissive licenses because you cannot take an MPL file, modify it, and close the modifications; those changes must go back to the community under MPL. But it is far less restrictive than the GPL because the obligation is confined to the covered files, not the entire program. You can build a proprietary product that links to or includes MPL components as long as you keep the MPL files (and your modifications to them) open.
MPL 2.0 also has a built-in GPL-compatibility feature. Unless a file is explicitly marked "Incompatible With Secondary Licenses," MPL-covered code can be combined with GPL, LGPL, or AGPL code, letting the larger work be distributed under those licenses. This resolved a long-standing incompatibility that plagued MPL 1.1. Our comparison pages show exactly where MPL falls between the permissive and strong-copyleft families, and our concepts library explains the weak-versus-strong copyleft distinction.
What the MPL 2.0 Means for Your Project and Compliance
For most teams, MPL is one of the more comfortable copyleft licenses to comply with, because the obligations are contained and predictable.
The core obligation is to keep MPL files open. If you ship a product that includes MPL-covered files — modified or not — you must make the source of those specific files available to recipients under the MPL, and preserve the notices they carry. Crucially, you do not have to disclose the source of your own separate proprietary files, which is why MPL is popular for components meant to be embedded in commercial software.
Practically, the main compliance risks are (1) accidentally editing an MPL file and treating your changes as proprietary, and (2) losing track of which files in a merged codebase are MPL-covered. Both are inventory problems. You also get the benefit of an explicit patent grant, which — like Apache 2.0 and unlike MIT or BSD — reduces patent uncertainty, subject to the retaliation clause.
Because MPL's boundary is the file, disciplined source management is the key to staying compliant. The academy walks through establishing that discipline as part of a broader license workflow.
How Safeguard Tracks MPL License Compliance
File-level copyleft only works if you can reliably tell which components — and, ideally, which files — carry MPL terms. In a large dependency tree, that is not something you can track by hand.
Safeguard's Software Composition Analysis identifies every open-source component across your project, resolves the license attached to each, and flags MPL-licensed components throughout the transitive graph. That tells you precisely where the file-level source-disclosure obligation applies, so you can keep those components open while confidently keeping your own code closed.
SBOM Studio then records each component's license in a CycloneDX or SPDX software bill of materials, giving legal and engineering teams a shared, auditable inventory of copyleft exposure. Policy rules let you decide how MPL fits your product — permitted, permitted-with-review, or blocked — and enforce that decision on every build, so a weak-copyleft dependency is a conscious choice rather than an accident discovered at release time. Create a free account to scan your dependencies for MPL and other copyleft licenses, or read the documentation to configure your policy.
Frequently Asked Questions
Can I use MPL 2.0 code in a proprietary, closed-source product? Yes. MPL 2.0 is weak copyleft, so you can combine MPL-covered files with your own proprietary files and keep your code closed. The one requirement is that the MPL-covered files themselves — including any modifications you make to them — must remain under the MPL with their source available. Your separate, original files are unaffected.
How is the MPL different from the GPL? The MPL applies copyleft at the file level, while the GPL applies it to the entire derivative work. Under the MPL you must keep MPL-covered files open but can keep your own separate files proprietary. Under the GPL, distributing a derivative generally requires the whole combined work to be GPL-licensed with full source. This makes the MPL far friendlier to mixing with proprietary code.
Is the MPL 2.0 compatible with the GPL? Yes, by default. MPL 2.0 includes a secondary-license mechanism that allows MPL-covered code to be combined with GPL, LGPL, or AGPL code and distributed under those licenses, unless a file is specifically marked "Incompatible With Secondary Licenses." This fixed the GPL incompatibility that existed in the older MPL 1.1.
Does the MPL include a patent grant? Yes. Like the Apache License 2.0, MPL 2.0 provides an explicit patent license from each contributor covering their contributions, along with a retaliation clause that terminates the grant if you initiate patent litigation over the software. This gives MPL users more patent certainty than permissive licenses such as MIT or BSD, which are silent on patents.