If you distribute an executable built from MPL 2.0 code, you must tell recipients where to get the source for the MPL covered code. You may license your executable under terms you choose, provided they do not interfere with recipients' rights to that source. New files that contain no MPL code stay yours. Not legal advice.
Definition
The Mozilla Public License 2.0 has file level copyleft. The Mozilla FAQ describes it as a simple copyleft license designed to encourage contributors to share modifications, while allowing combination with code under other licenses, open or proprietary, with minimal restrictions.
Three common shipping cases
The Mozilla FAQ answers these directly.
| You are shipping | What the FAQ says you must do |
|---|---|
| A complete, unchanged executable built by someone else from MPL software | Typically nothing, if the people who distributed it to you complied. You can check for the notice of where the source is available |
| An executable or library you compiled from someone else's unchanged MPL source, standalone or in a larger work | Inform recipients where to get the source for the MPL code, under Section 3.2. You may license your executables under terms of your choice that do not interfere with recipients' rights to the source |
| An executable based on MPL source you modified | Make the MPL licensed portions of the source available and inform recipients how to obtain them, under Section 3.2 |
The file level boundary
The FAQ answers the worry about "viral" effects. It says the license requires that Modifications, as defined in section 1.10, be licensed under the MPL and made available to anyone to whom you distribute the source. New files that contain no MPL licensed code are not Modifications, so they do not need to be distributed under MPL terms, even if you create a Larger Work by compiling or distributing them together with MPL files.
The FAQ summarises scope this way: MPL copyleft applies to any files containing MPL code, LGPL to any library based on LGPL code, and GPL to all software based on GPL code. It recommends reading the licenses to understand how "based on" is defined.
What to put in a mobile or desktop app
- Add the MPL component to your notices list, with license name and version.
- Add a clear line saying where the source for the MPL covered code can be obtained, such as the upstream repository at the version you used, or your own page if you modified it.
- Keep the license text with the notice.
- If you modified MPL files, publish those modified files under the MPL.
- Keep your own new files in separate files from the MPL ones, so the boundary stays clean.
- Keep the notice reachable from your About or licenses screen.
Mistakes to avoid
- Editing an MPL file to add your proprietary logic. That makes your logic part of a Modification.
- Removing the license header from an MPL file when you copy it. The FAQ points to the license's restrictions on removing or altering notices in section 3.4.
- Using a EULA that forbids users from extracting the MPL covered source.
Try it yourself
Click through the inventory demo and look for how components are marked. An MPL component in your build should be visible as a separate line, so you can attach a source location to it.
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning list the components in your build, and policies and gates can hold a change for license review. A free scan is available at gold.safeguard.sh/scan.
Quick check
Does MPL 2.0 force me to open source my whole app?
No. The FAQ says new files with no MPL code do not need to be under the MPL, even in a Larger Work.
Do I need to publish source if I did not modify the MPL code?
You must inform recipients where they can get that source. Pointing to the upstream release you used is one way to do that.
What if I changed an MPL file?
Your modifications to that file must be under the MPL and made available to recipients of your executable.
Sources
Last reviewed: 19 October 2026.
