MPL 2.0 is a simple copyleft license whose obligations attach at the file level. If you modify a covered file, that file stays under the MPL. Separate files in a larger work can be under other licenses. For license inventories, record which files are covered and whether you changed them. This is not legal advice.
What the license and FAQ say
Mozilla's FAQ describes the MPL as a simple copyleft license. It says the 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. The license text defines a Larger Work as a work that combines Covered Software with other material, in a separate file or files, that is not Covered Software.
Where it sits among other licenses
| Aspect | Permissive (MIT, BSD) | MPL 2.0 | Strong copyleft (GPL) |
|---|---|---|---|
| Changed files | No sharing duty | Covered file stays under MPL | Whole covered work under the license when conveyed |
| Separate files in the same product | Any terms | Can carry other terms | Generally part of the combined work |
| Notice duty | Keep notices | Keep notices and license text | Keep notices and license text |
The comparison is a simplification to help you sort components into tiers. The license text controls.
What to record in an inventory
- The component name, version and the license identifier, MPL-2.0.
- Whether you modified any covered file. Unmodified use is a different situation from a patched copy.
- Where the modified files live in your repository.
- Whether source for the covered files is available to recipients when you distribute.
- Any combination with GPL or LGPL code. The FAQ explains that combining MPL code with (L)GPL code is possible through the Larger Work provision, but only if conditions are met, including that the software is not marked Incompatible With Secondary Licenses. Check with counsel before relying on that.
Detecting modified files
The most common gap is a vendored or patched copy. If someone copied a library into your repo and edited it, the SCA scanner may not see a modification. The post on vendored code and git submodules covers detection. Also see license detection methods compared.
Per file headers
The FAQ says a standards compliant, machine readable license metadata header can be compliant with the notice related goals of the MPL, although the license recommends its own exhibit text. Keep the headers intact when you edit a covered file. Stripping them is the quickest way to create a problem you did not have.
Safeguard's SBOM and dependency scanning can list MPL components in your builds so you know which ones to inspect. Whether a given use meets the license is for you and your counsel.
Quick check
Does MPL 2.0 force us to open source our whole app?
Per the FAQ, the copyleft is file level and the license allows combining with other code, so the obligation centers on modified covered files rather than your separate files. Confirm your specific facts with counsel.
Is an unmodified MPL library different from a patched one?
Yes in practice. Record which one you have, because the sharing duty attaches to modifications of covered files.
Sources
Last reviewed: 19 October 2026.
