Licensing a library under the MPL

Question

The Mozilla Public License 2.0 is a license that specifically allows you to include source code licensed under it, in any program without restrictions, provided users are given a copy of the MPL-licensed code, and the license is reproduced. This is in a way a step between the LGPL, which requires you to give users a method by which to modify the library (i.e. dynamic linking), and more permissive licenses like MIT/BSD, which don't require the disclosure of source code at all.

I'm writing a library that's intended to be shipped along with programs that use it, since newer versions of the library likely won't be compatible with programs using older versions. The most convenient (and common) method to accomplish this is static linking. I'd like to avoid forcing application authors to either open all of their code or ship another file along what would otherwise be a single .exe/ELF, but I'd also like to make sure any modifications to this library remain open source. In this sense, the MPL seems like a perfect fit.

However, I'm not aware of any libraries that use the MPL, nor any mentions of it online. This makes me worried that this license either might not apply to libraries, or might just not be very useful for the purpose. Can the MPL be used for libraries? If so, is it effective in making sure the source code remains open? Are there any pitfalls to using this license for a library? Are there any examples of big open-source libraries using this license?

Answer 1

Allow me to share a fragment from my book Entreprenerd: Building a Multi-Million-Dollar Business with Open Source Software as an introduction to my answer:

I developed two PDF libraries. I started writing the first one ("rugPdf") in 1998 and I chose the LGPL when I released it. The MPL was written in the same year, but I wasn't aware of its existence.

I released a second PDF library ("iText") in 2000 and I used the same license as before (that is: the LGPL) because I didn't know any better. That second library was much better—and subsequently more popular—than my first attempt. This popularity resulted in feedback from different legal departments that aired the same concerns that you mention in your question. These valid concerns made me offer the library under a dual license:

• Users who wanted to use iText under the LGPL, could continue doing so
• Users who preferred the MPL, could use it under the MPL

As is custom with the MPL and the LGPL, people who improved the library contributed their improvements back to the project, improving the software for everyone. In 2006-2007, I did a research project for Ghent University, Actuate, and the Eclipse Foundation regarding the IP of the codebase. The deliverable of this research project was a detailed list of every third party contribution and contributor. That was quite an extensive list, but it was less extensive than you'd probably wish. Based on personal experience, I have stopped believing in the fairy tale of "make it open source and everyone will cooperate!" In reality, most developers are very happy to use your software, but only a handful will actually help you improving it.

In 2009, I changed the license of new versions of iText to the AGPL after almost giving up on the project. Without a business model and financial revenue, it was no longer possible to further develop and maintain the library, but that's another story.

A fork of the pre-2009 library, renamed to openpdf, is still available under the MPL, but obviously, its functionality doesn't come close to the breadth of functionality iText offers today. "No financial revenue" equals "No means to fund a dedicated time of developers to keep up with the PDF specifications and to answer the ever-increasing demands of the market."

Summarized:

In my opinion, the MPL is extremely suited for libraries. I used it with success for many years in my project, and a fork of my project still uses it today.

Pitfall 1 is believing that you'll get plenty of code contributions. I hope for you that I'm wrong, but just compare the evolution of the functionality of iText (developed either by paid developers, or by partners in the context of iText-as-a-Platform) with the evolution of the functionality of openpdf (maintained by people who work on a voluntary basis). Although it looks like openpdf is still actively developed, it didn't keep up with the evolution of the different PDF standards (e.g. the PDF/UA standard released in 2012 and ISO 32000-2 released in 2017).

Pitfall 2 is the difficulty of building a business with a library that is released under the MPL. Make sure you have a business model in place where you fund the development and maintenance of your MPL library with another project or another sustainable source of revenue. For a longer article on business models for open source, see Open Source Survival: A Story from the Trenches.

DISCLAIMER: I am the original developer of iText and the original founder of the iText Group companies, but I sold those companies in three parts in 2015, 2018, and 2020. Today, the companies are fully owned by three private equity companies backed by Peter Thiel, and I am no longer affiliated with any of the iText companies or projects. Neither am I affiliated with openpdf, despite the fact that they still use my name in their package names.