License guide · Copyleft

MPL-2.0, in plain English

The Mozilla Public License 2.0 is file-level copyleft — and that scoping is the whole idea. You may combine MPL-covered code with proprietary code and ship the result commercially. Your files stay yours. What must stay open under the MPL are the MPL-covered files themselves, including any changes you make to them. It sits deliberately between MIT and the GPL.

Updated 31 Jul 2026 · by the depproof team

General information, not legal advice. The controlling text is the license itself as shipped with the dependency. Primary source: the Mozilla Public License, Version 2.0.

File-level copyleft: what the boundary actually is

Copyleft licenses differ mainly in how far the reciprocity reaches. MPL-2.0 draws the line at the file.

  • MPL-covered files stay under the MPL. The dependency’s own source, plus any modification you make to those files, must be made available under the MPL.
  • Your new files do not. Code you write in separate files — even in the same program, compiled into the same binary — can be proprietary and licensed on your own terms.
  • The combined work can be distributed under your license. MPL calls this a “Larger Work”, and explicitly permits it, provided the covered files’ source remains available.

Contrast the two neighbours. The GPL draws the line at the combined work, so linking pulls your program in. LGPL draws it at the library, with a relinking requirement. MPL draws it at the file, which is the narrowest of the three and the easiest to satisfy inside a proprietary codebase.

Can you…? The MPL-2.0 decision at a glance

Can you…Under MPL-2.0?
Use it in a proprietary commercial product and sell itYes
Keep your own separate source files proprietaryYes
Distribute the combined work under your own licenseYes — as a “Larger Work”
Keep your modifications to MPL-covered files privateNo — those go back under the MPL
Ship without telling recipients how to get the covered sourceNo — source availability is the core condition
Run it as a SaaS without disclosing anythingYes — no network clause
Rely on an express patent grantYes — like Apache-2.0
Combine it with GPL-licensed codeYes — unless marked “Incompatible With Secondary Licenses”

Why MPL gets over-restricted in dependency policy

MPL is frequently swept into a blanket “no copyleft” ban alongside the GPL and AGPL. That is usually a mistake. The obligation MPL creates — publish your changes to the dependency’s own files — is one most teams satisfy by default, because most teams do not fork their dependencies at all. If you consume an MPL library unmodified, there is nothing new to publish; you point recipients at the upstream source.

The obligation only becomes real when someone patches a vendored copy — a hot-fix applied to a bundled dependency, a forked file pulled into the tree. That is precisely the case a keyword-based policy cannot see, and it is the reason to classify MPL distinctly rather than lumping it with strong copyleft.

MPL vs LGPL vs GPL, in one line each

  • MPL-2.0 (file-level copyleft). Only the covered files and your changes to them stay open; new files beside them can be proprietary.
  • LGPL-3.0 (weak copyleft). The library stays open and users must be able to relink; your application stays proprietary.
  • GPL-3.0 (strong copyleft). The whole combined work comes under the GPL when you distribute it.

Frequently asked questions

Is MPL-2.0 safe for commercial use?

Yes, with one condition that permissive licenses do not have. The Mozilla Public License 2.0 lets you combine MPL-covered code with proprietary code and distribute the result — your own files stay proprietary and you need not publish them. What you must do is make the source of the MPL-covered files available, including any modifications you made to those files. The copyleft is scoped to the files, not to your whole application.

What does file-level copyleft mean?

It means the license's reciprocity attaches to individual source files rather than to the combined work. Under the GPL, linking a GPL library into your program brings the whole program under the GPL. Under MPL-2.0, only the files that are themselves MPL-covered — plus your modifications to those files — must remain under the MPL. New files you write alongside them can be proprietary and licensed however you choose. That is why MPL is described as a middle ground between permissive and strong copyleft.

Do I have to open-source my application if I use an MPL-2.0 dependency?

No. Your own source files remain yours to license as you wish, and the combined executable can be distributed under your own terms. The obligation is to provide the source of the MPL-covered files themselves — the dependency as you shipped it, including any changes you made to it — under the MPL, and to tell recipients how to obtain it.

Does MPL-2.0 have a network or SaaS clause?

No. Like the GPL and unlike the AGPL, MPL-2.0's obligations are triggered by distribution. Running MPL-covered code on your own servers to provide a hosted service is not distribution, so it does not trigger the source-availability requirement. Only network-copyleft licenses such as the AGPL treat remote interaction as a trigger.

Does MPL-2.0 grant patent rights?

Yes. MPL-2.0 includes an express patent license from each contributor covering their contributions, together with a termination provision that ends your patent rights if you initiate patent litigation alleging the covered software infringes. In this respect it resembles Apache-2.0 rather than MIT or BSD.

Is MPL-2.0 compatible with the GPL?

Yes. MPL-2.0 was written to be compatible with the GPL, LGPL and AGPL — this was one of the main goals of the 2.0 revision. Covered software can be combined with GPL-licensed work and distributed under the GPL, unless the original author marked the file as "Incompatible With Secondary Licenses", which is an explicit opt-out the license provides.

General information, not legal advice; confirm specific decisions with counsel. “Mozilla Public License” refers to the license published by the Mozilla Foundation and is used nominatively.