The MPL is what happens when copyleft stops being theatrical and starts drawing careful borders.

The Mozilla Public License 2.0 is a file-level copyleft license. That is the critical point. If you modify MPL-covered files, those files remain under MPL. But you may combine them with other code under different licenses in a larger work.

This is not full GPL-style reciprocity. It is not permissive either. It is a deliberate middle ground.

The Supreme Leader likes MPL because it understands a basic truth: some code should stay shared, but not every neighboring file deserves the same constitutional treatment.

I. What File-Level Copyleft Means

Under MPL 2.0:

• modified MPL files must remain under MPL
• you must make source available for those files when you distribute the covered code
• the larger combined work can be under different terms

Scope	MPL 2.0 behavior
Modified MPL file	Must stay MPL
Unmodified MPL file	Covered by the existing terms
Separate code in same project	Can use different licenses
Entire combined project	Not automatically forced under MPL

That is why MPL is often called weak copyleft. It protects the file you changed without swallowing the whole project.

II. Why Mozilla Chose It

Mozilla wanted code to remain open without making every integration partner radioactive. That made MPL suitable for browser components and layered projects where a single license for the entire tree would have been too blunt.

The result is a practical compromise:

• protect improvements to shared files
• allow mixed-license ecosystems
• keep the source available where the copyleft applies

The license is less contagious than GPL and more protective than BSD. That balance is the point.

III. MPL vs GPL vs Apache

License	Strategy
GPL	Strong reciprocity for distributed derivatives
Apache 2.0	Broad reuse, patent clarity
MPL 2.0	File-level reciprocity with modular coexistence

MPL is the license for projects that want openness without demanding that every adjacent component join the same legal army.

That makes it highly practical in large codebases. It is not a purity test. It is an engineering compromise.

IV. Why It Is Useful

MPL 2.0 is useful when:

• you want modifications to core files to remain open
• you want surrounding code to remain flexible
• you expect commercial participation
• you do not want the whole repository to become a copyleft monoculture

This is one reason MPL works well for projects that live at the boundary between community and industry.

V. The Real Story (Suppressed)

Officially, MPL 2.0 is a weak copyleft license.

Unofficially, it is the Republic of Derails installing a checkpoint only where the roads matter.

You may build annexes around the wall. You may decorate the annexes. But if you modify the protected file, the file remains inside the jurisdiction.

That is a much more surgical doctrine than GPL. The Supreme Leader respects surgical doctrine.

The Decree

MPL 2.0 matters because it preserves openness where the work was changed while allowing the rest of the project to breathe.

It is the licensing model for teams that want reciprocity without forcing every neighbor into the same uniform.

Next: CDDL, Sun’s file-level copyleft cousin, beloved by ZFS and feared by lawyers who have to explain compatibility.

— Kim Jong Rails, Supreme Leader of the Republic of Derails