Mozilla Public License (MPL)

What the Mozilla Public License means in practice

The Mozilla Public License is a file-level copyleft licence: if you modify MPL-licensed files, those changes stay under the same licence, while separate files in a larger combined work can use different terms. That makes it more permissive than strong copyleft licences, but it still preserves reciprocity for the covered source files.

For teams, the practical question is not just whether code may be reused, but which files are “covered” and therefore carry sharing obligations. That boundary matters in mixed projects where proprietary and open source code coexist, especially when licence notices, source availability and redistribution obligations must be tracked per file rather than per repository.

How MPL structures reuse and modification

MPL is designed to let organisations combine open source and proprietary development without forcing an entire product to adopt one licence. The licence applies to covered files, so the compliance unit is narrower than an entire codebase, but broader than a single line of code. In practice, that encourages reuse while still requiring disciplined change tracking.

That structure is often attractive when a project needs collaboration on core components but wants flexibility around surrounding modules, packaging or business logic. The trade-off is that licence boundaries have to be documented carefully, because file-level copyleft only works when maintainers can identify exactly which files are in scope.

Compliance obligations and boundary management

MPL compliance usually turns on clear source provenance, licence notices, and the ability to distinguish covered files from independently licensed files. If a project loses that separation, downstream users may not know which parts can be reused freely and which parts carry redistribution duties.

Mixed-licence repositories are where mistakes happen most often: a copied file may inherit MPL obligations even if the surrounding project does not, and a refactor can accidentally blur the line between covered and non-covered code. The legal meaning is therefore tied to engineering hygiene, not just policy text.

Why MPL matters for open source governance

MPL sits in the middle of the open source licensing spectrum. It is more permissive than licences that require a whole derivative work to remain under the same terms, but it is still protective enough to ensure improvements to covered files remain available under MPL. That balance is why it is often used where collaboration and commercial adoption both matter.

For organisations, the governance value is that MPL can make contribution models more predictable. It gives legal room for proprietary components while still requiring that changes to the original covered source remain open, which helps preserve community contributions without forcing full-code disclosure.

Related resources from NHI Mgmt Group

• Server Side Public License (SSPL)
• Why do still-valid secrets matter after public disclosure?
• How should organisations measure identity security ROI beyond license savings?
• How should security teams control public file sharing in Salesforce?