MPL 2.0 License Generator

The Mozilla Public License 2.0 explained

The Mozilla Public License 2.0 (MPL 2.0), released by the Mozilla Foundation in 2012, is a weak copyleft license that operates at the file level. Modify a file licensed under MPL 2.0 and that file must remain MPL 2.0 with its source available — but you can freely combine it with proprietary, MIT or GPL files in the same project. It is a deliberate compromise between permissive licenses (MIT/BSD) and strong copyleft (GPL).

Permissions: use, modify, distribute and sublicense (in other files). Conditions: modifications to an MPL-licensed file must be released under MPL 2.0 with the original LICENSE and notice files preserved. MPL 2.0 includes an explicit patent grant from contributors and a patent retaliation clause, which makes it safer than MIT or BSD in patent-heavy domains.

Projects that use it

MPL 2.0 covers Firefox, Thunderbird, large parts of the early LibreOffice codebase, Servo, several Rust crates and a number of Eclipse-adjacent components (EPL plays a similar role). It is also popular for cryptography libraries where contributors want patent grants but not the viral reach of GPL.

MPL vs GPL vs LGPL vs Apache 2.0

• MPL 2.0 vs GPL — GPL is strong copyleft: the whole derivative work must be GPL. MPL only covers the modified files. MPL 2.0 added a "secondary license" provision making it explicitly compatible with GPLv2+, LGPL and AGPL — its predecessor MPL 1.1 was not GPL-compatible.
• MPL 2.0 vs LGPL — LGPL works at the file-and-linking boundary (dynamic vs static linking gets complicated); MPL works at the file boundary, which is much easier to reason about.
• MPL 2.0 vs Apache 2.0 — Apache is permissive (no copyleft) with explicit patent grants. MPL keeps file-level copyleft so improvements to MPL files flow back to the community.
• MPL 2.0 vs CDDL — Sun's CDDL (OpenSolaris) is conceptually similar but GPL-incompatible, which fragmented the OpenSolaris/ZFS ecosystem. MPL 2.0 explicitly avoided that mistake.

When to choose MPL 2.0

Pick MPL 2.0 when you want bug fixes and improvements to your files to come back upstream, but do not want to "infect" the rest of an integrator's application. It is the sweet spot for shared libraries that need to live inside proprietary apps. Caveat: MPL is not network-protective — for SaaS use cases where you want server-side modifications shared, choose AGPL instead.

FAQ

Can I combine MPL 2.0 code with proprietary code? Yes — in separate files. Your proprietary files keep their license; the MPL files stay MPL 2.0 with source available.

Can I fork an MPL project and close-source it? Only the new files you create can be closed. Modifications to existing MPL files must remain MPL 2.0 and source-available.

Does MPL 2.0 cover SaaS use cases? No. MPL does not require releasing source for server-side modifications. If you need that, use AGPL 3.0.

Does Mozilla require a CLA? Yes — Mozilla projects use a Committer's Agreement. But the MPL itself does not require contributors to sign one.

Disclaimer. This generator produces a license template — it is not legal advice. For copyleft strategy or dual-licensing, consult an attorney.