Mozilla Public License (MPL)

Key characteristics

The MPL applies copyleft on a file-by-file basis rather than to an entire combined program. In practice this means that any modifications to files under the MPL must be distributed under the same license, but other files in the same project can be licensed differently — including under a proprietary license — so long as MPL-covered files remain available under MPL terms.

• File-level copyleft: only the source files originally under MPL must remain MPL when modified.
• Compatibility and re-licensing: MPL code can, in many situations, be re-licensed or combined with GPL code through explicit compatibility provisions.
• Patent and contribution terms: modern MPL versions include provisions designed to clarify patent grants and contributor obligations.

History and revisions

The MPL was first written in the late 1990s when open source practices were evolving in commercial web and browser development. Its initial drafting is attributed to a lawyer associated with Netscape; later stewardship moved to the Mozilla Foundation. The license saw a minor update to version 1.1 and a more substantial overhaul to version 2.0, which simplified language and improved compatibility with other widely used licenses.

Derivatives and adaptations of MPL 1.1 influenced other licenses; for example, Sun Microsystems used it as a basis when creating the Common Development and Distribution License. The license has also been recognized and approved by major standards organizations concerned with open licensing.

Uses and notable examples

The MPL is the chosen license for many of Mozilla's flagship projects, including Firefox, Thunderbird, and a range of other Mozilla projects. It has been adopted beyond Mozilla: some vendor toolkits and office suites have used the MPL for components (for example, parts of LibreOffice were distributed under MPL terms alongside LGPL licensing), and commercial products have sometimes incorporated MPL code then combined it with proprietary modules.

Practical implications for developers and organizations

Choosing MPL means contributors must make source code for MPL-covered files available when those files are distributed in compiled or executable form. However, because the copyleft applies per file, proprietary modules can coexist in the same larger work if they do not modify MPL-covered files. This pragmatic approach reduces licensing friction in mixed-source environments while preserving a measure of share-alike reciprocity.

Compatibility, approvals and provenance

The MPL is formally recognized by both open source and free software communities; it has been approved by organizations that review licenses for openness and freedom. The license's provenance traces to early browser-era legal work, and its governance and wording evolved to address modern concerns such as cross-license compatibility, contributor rights, and patent clarity. The story of the MPL is part legal engineering and part practical compromise between strictly permissive and strongly reciprocal licensing philosophies.

Summary and distinctions

In summary, the MPL offers a pragmatic middle path: it enforces sharing of modifications to covered files while allowing broader application code to follow different licensing, including GPL or proprietary terms, where appropriate. It has been applied to flagship open source products, influenced other licenses, and remains a widely used option for projects that want both collaboration and flexibility. For historical context, its origins are linked to legal work done during the Netscape era by a Netscape lawyer, and its status has been recognized by bodies such as the Free Software Foundation for its acceptable terms under free-software criteria.

Further reading: consult the full license text and authoritative commentary before applying the MPL to a project; compatibility and obligations can vary depending on version and how software is combined and distributed.