MPL-2.0 explained: why one project uses four licenses on purpose

MPL-2.0, the Mozilla Public License, is a "file-level" copyleft licence: if you change a file covered by it and distribute the result, you must share your changes to that file, but you can combine it with your own closed code in a larger product without opening that code. That middle ground is why some projects use it for their core, and why a project can end up using several licences on purpose, each for a different part.

This post explains MPL-2.0 in plain terms, compares it with the licences most people know, and shows how Havenfold splits its repository across four licences and why. It is a general explanation, not legal advice.

Copyleft, permissive, and the middle

Open-source licences fall roughly into three groups:

• Permissive licences (MIT, BSD, Apache-2.0) let you use, change and redistribute the code, including inside closed products, with few conditions, usually keeping the copyright notice.
• Strong copyleft licences (GPL, AGPL) require that software built on the code is shared under the same licence when distributed. The Mozilla FAQ puts the GPL's scope this way: "The copyleft applies to all software based on GPLed code."
• Weak or file-level copyleft (MPL-2.0) sits in between: the copyleft applies to the files that carry the licence, not to the files around them.

What MPL-2.0 asks of you

Mozilla's own FAQ describes the MPL as "a simple copyleft license" whose file-level copyleft is "designed to encourage contributors to share modifications they make to your code". In practice:

• Changes to MPL files are shared. If you modify an MPL-licensed file and distribute your software, you make the source of that modified file available under the MPL.
• Your own new files stay yours. The FAQ says "new files containing no MPL-licensed code are not Modifications", so they don't have to be released under the MPL. It gives the example of MPL code that can be "statically linked to and distributed as part of a larger proprietary piece of software".
• It can live alongside the GPL. The FAQ explains that MPL and GPL code can be combined into a "Larger Work", unless the MPL code has been marked "Incompatible With Secondary Licenses".

For a project that wants improvements to its core to come back, while still letting companies build products on top, this is a natural fit.

The other three licences, briefly

• Apache-2.0 is permissive and includes an explicit patent licence: section 3, "Grant of Patent License", grants a licence to patents that contributors hold and that their contributions read on.
• AGPL-3.0 is GPL plus a network clause. Section 13 says that if you modify the program, your modified version must prominently offer the opportunity to receive its source to anyone interacting with it remotely through a computer network. It closes the gap where server software is never "distributed" but still serves other people over a network.
• CC BY 4.0 is not a software licence but a Creative Commons licence for text and media: you can share and adapt the material if you give appropriate credit.

Why Havenfold uses four licences on purpose

Havenfold's README says it "uses several licenses on purpose". Each package states its licence in its package file, each source file carries an SPDX line, and the full texts are in the repository. The split is:

• MPL-2.0 for the core, the phone package, the node software and the installer. The README's reason: "file-level copyleft: you may ship the core inside a closed product, but changes to the core's files must be published." It adds that MPL-2.0 is compatible with app store distribution, which matters because phone apps are built on the core.
• Apache-2.0 for the test vectors and number allocations, the SDK, the export-open tool and the task images, "so anyone can implement Havenfold without hesitation". It includes a patent grant.
• AGPL-3.0-only for server-side reference code, today a reference receiver for service packages, and later the Mailbox and the relay when they move into the repository. Code that runs as a network service is exactly where the AGPL's network clause applies.
• CC BY 4.0 for documentation, including the founding document and the README files.

The README also lists commitments that sit next to the licences: published code will not be relicensed under a more restrictive licence, contributions come in under the Developer Certificate of Origin with no CLA, and if the project is sold, the trademark and repository go to a foundation. On patents, the project describes its innovations as a defensive publication and says it files no patent applications for them.

What this means if you build on Havenfold

• Building a closed app on the core: allowed under MPL-2.0; changes you make to the core's own files must be published.
• Writing your own implementation from the specs and test vectors: the Apache-2.0 parts are meant to make that easy.
• Running a modified server-side reference component for others: the AGPL asks you to offer its source to the people using it over the network.
• Quoting or adapting the documents: CC BY 4.0, with credit.

Havenfold itself is pre-alpha: do not use it for real data. The licences describe what you may do with the code; they say nothing about whether it's ready, and today it isn't.

Summary

• MPL-2.0 is file-level copyleft: changes to MPL files are shared, while your own separate files, even in a closed product, can stay closed.
• Permissive licences like Apache-2.0 ask little and, in Apache's case, add an explicit patent licence; the AGPL adds a network clause to the GPL; CC BY 4.0 covers text and media with attribution.
• Havenfold uses MPL-2.0 for its core, Apache-2.0 for the SDK, tools and test vectors, AGPL-3.0 for server-side reference code and CC BY 4.0 for documents, each for a stated reason.
• Its README also commits never to move published code to a more restrictive licence and to use the DCO without a CLA.