Mozilla Public License 2.0 Explained — Plain English Guide (File-Level Copyleft)

The Mozilla Public License (MPL 2.0) is a weak copyleft license that operates at the file level — modified MPL files must stay MPL, but you can combine them with proprietary code in the same project without open-sourcing everything. It bridges the gap between the permissive MIT License and the strong copyleft GNU GPL, powering Firefox, LibreOffice, and Thunderbird.

What You’ll Learn

By the end of this guide, you’ll understand how file-level copyleft works, what happens when you combine MPL code with proprietary code, whether you can use MPL libraries in commercial products, and how MPL compares to LGPL and GPL in practice.

Why It Matters

The MPL solves a real problem: the GPL is too restrictive for many corporate users, while MIT gives up too much control over how the code is used. The MPL’s file-level approach means you can contribute to open-source projects while building proprietary products — as long as you leave the MPL-licensed files alone. This makes it the preferred license for projects that want both community participation and corporate integration.

Real-World Use

Your company takes the Firefox browser engine (MPL 2.0) and builds a custom embedded browser for your IoT dashboard. You add proprietary C++ code in new files that work alongside the MPL files. Your proprietary files remain proprietary. But if you modify any MPL-licensed files in the engine, those modifications must be released under MPL. The line is drawn at the file boundary — not the function or class boundary.

Quick Reference

What the MPL 2.0 Actually Says

The MPL 2.0 is built around the concept of “Covered Software” — files that are originally licensed under the MPL. Here’s the core rule:

If you distribute modified versions of MPL-licensed files, those modified files must remain under the MPL. But you can combine MPL files with proprietary files in a “Larger Work” without affecting the license of the proprietary files.

File-Level Copyleft

This is the key concept. Imagine a project with three files:

• core.js — MPL 2.0
• plugin.js — MPL 2.0 (your modifications)
• ui.js — Your proprietary code

Under MPL:

• plugin.js (modified) must stay MPL ✅
• ui.js (proprietary) can stay proprietary ✅
• You can distribute all three together as one application ✅

Under GPL, combining plugin.js and ui.js would make the whole thing GPL. Under MPL, only files that are originally MPL (or derived from MPL files) must stay MPL.

The “Larger Work” Concept

MPL 2.0 defines a “Larger Work” as a work that combines Covered Software (MPL files) with other code not governed by the MPL. The Larger Work itself can be licensed differently — including under proprietary terms — as long as the MPL-covered files remain available under MPL.

This is what makes MPL business-friendly: you can build proprietary products around MPL components without releasing your proprietary code.

Can I Use MPL Code in Commercial Products?

Yes — with conditions that depend on how you use it.

You Can Always:

• Use MPL code in commercial products
• Sell products containing MPL code
• Combine MPL code with proprietary code in the same application
• Distribute the combined work under proprietary terms (for your own code)

Conditions Apply When:

• You modify an MPL-licensed file: your changes must be released under MPL
• You distribute MPL code (modified or not): you must provide source access for the MPL-covered files
• You must include the original copyright notices and MPL license text

What About Patents?

MPL 2.0 includes an explicit patent grant. Contributors grant you a patent license for any patents they hold that cover their contribution. If you sue someone over patents related to the MPL code, your license terminates. This is similar to Apache 2.0’s patent clause.

Real-World Projects Using MPL 2.0

Why These Projects Chose MPL

Projects like Firefox and LibreOffice chose MPL because they want:

1. Contributions shared back — if you fix a bug in their code, that fix must be available to everyone
2. Corporate adoption — companies can integrate the code without fear of GPL contamination
3. File-level granularity — the boundary is clear and enforceable

MPL vs LGPL vs GPL

The MPL is often described as “in between” LGPL and GPL — but it’s not exactly on the same spectrum. LGPL is focused on libraries and linking. MPL is focused on files in any kind of project.

MPL 2.0 Compliance in Practice

What You Must Do

When distributing MPL code (modified or unmodified) as part of your application:

1. Include the MPL license text — either in a LICENSE file or in each MPL file header
2. Retain copyright notices — don’t remove original author attributions
3. Identify changes — if you modified MPL files, indicate what you changed and when
4. Make source available — provide source code for all MPL-covered files (in a tarball, a GitHub link, or alongside your binary)
5. Do NOT remove the MPL from MPL-covered files — they must stay MPL

What You Don’t Need to Do

• Release your proprietary files (unless they contain copied MPL code)
• Release object files or relinkable artifacts (unlike LGPL static linking)
• Open-source your entire application

Example NOTICE File for MPL

This software includes components licensed under the Mozilla Public License 2.0:

- Firefox SpiderMonkey JS engine (Copyright Mozilla Foundation)
  Modifications: Fixed memory leak in GC (2026-01-15)
  Source: https://github.com/example/spidermonkey-patches

Full MPL 2.0 license text available in LICENSES/MPL-2.0.txt

Common Misconceptions

“MPL means the whole project must be open source”

No — only the individual files that are (or derive from) MPL code. Other files in the same project can have any license, including proprietary.

“MPL is the same as LGPL”

Different mechanisms. LGPL links at the library boundary. MPL draws the line at the file boundary. MPL applies to any kind of software (not just libraries) and doesn’t require dynamic linking.

“I can’t use MPL in a GPL project”

Actually, MPL 2.0 is GPL-compatible. You can incorporate MPL 2.0 code into a GPLv3+ project. The MPL files are effectively “upgraded” to GPL under the combination.

“MPL requires me to display the license in my app”

No — include the license text in your distribution (a LICENSE file or similar). No in-app display required unless you’re using the project’s trademarks.

“MPL is only for Mozilla projects”

While Mozilla created the MPL, anyone can use it. It’s a general-purpose open-source license, not restricted to Mozilla. Version 2.0 was specifically designed to be more reusable and compatible with other licenses.

When to Choose MPL 2.0

Choose MPL 2.0 for your own projects when:

• You want copyleft protection but at the file level, not the whole-application level
• You expect corporate users who need to integrate with proprietary code
• You want patent protection (MPL 2.0 has it)
• You’re building a project where some components might be proprietary and some open
• You want contributors to share their modifications, but not force end-users to open their entire product

Avoid MPL when:

• You want the strongest copyleft (choose GNU GPL)
• You want maximum adoption with zero obligations (choose MIT License)
• You want a library-specific license (choose GNU LGPL)
• File-level copyleft doesn’t fit your project’s architecture (e.g., tightly coupled languages where file boundaries don’t make sense)

FAQ

Copyleft Spectrum

graph TB
    A[MPL 2.0] --> B[File-Level Copyleft]
    B --> C[Modified MPL files must stay MPL]
    B --> D[New files can be any license]
    B --> E[Larger Work = combined, different licenses]
    F[LGPL] --> G[Library-Level Copyleft]
    F --> H[Linking exception for proprietary code]
    I[GPL] --> J[Work-Level Copyleft]
    J --> K[Entire distributed work must be GPL]

Practice Questions

1. Your project has three files: two MPL-licensed and one proprietary. You modify one MPL file and add two new proprietary files. What must be released under MPL? Only the modified MPL file. The original MPL file (unmodified) and the new proprietary files are not required to be MPL.

2. You embed Firefox’s SpiderMonkey engine (MPL 2.0) in your commercial iOS app. You don’t modify it. What are your obligations? Include the MPL license text and provide source access to the SpiderMonkey files. Your iOS app code stays proprietary.

3. Can a competitor take your MPL-licensed library, modify it, and sell the modified version without releasing the source code? No — modified MPL files must be distributed under MPL with source access. The modified library source must be available.

4. Your SaaS product uses an MPL library on the backend. Do you need to provide source to your customers? No — SaaS use does not constitute distribution. No source disclosure required for MPL or GPL (though AGPLv3 would apply).

5. You find MPL code copied into a competitor’s proprietary file (not a separate MPL file). What’s the issue? The competitor has violated the MPL by incorporating MPL-licensed code into a non-MPL file. The code was copied, not just linked. The file containing it should be MPL-licensed.

Mini Project: MPL Compliance Audit

1. Download a copy of Firefox or LibreOffice source code
2. Identify which directories contain MPL-licensed files (check file headers)
3. Count how many files are MPL vs other licenses in the project
4. Find the project’s LICENSE file and read how they handle the “Larger Work” notice
5. Create a hypothetical project that combines MPL and proprietary files, then write a compliance notice

Challenge: Find a real-world project that uses MPL 2.0 alongside proprietary or differently-licensed modules. Read their license documentation to understand how they manage the file-level boundaries. Write a short guide on how they handle contributions from external developers.

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro. This guide is for educational purposes and does not constitute legal advice. Consult an attorney for specific licensing questions.