Why I Chose the Mozilla Public License 2.0

Selecting a software license requires a conscious effort  because of the various rights and obligations that come with it. For me, the most important aspects of a license were

  • using an existing open source license,
  • commercial use clauses,
  • patent protection,
  • the obligation to disclose changes,
  • the ability to revoke the license as the sole copyright holder, and
  • compatibility with BSD-licensed code.

In this blog post I elaborate on why I chose the Mozilla Public License 2.0 for my eigensolver DCGeig based on these features.

Why Choose an Existing License

A copyright holder can release his code under his very own custom license. In my eyes, this approach has many drawbacks:

  • you need to find a lawyer to devise the license,
  • getting licenses right is hard,
  • there is no foundation enforcing the license, and
  • it abets license proliferation.

The Free Software Foundation ensures compliance for the GNU licenses and similarly, the Mozilla Foundation backs the Mozilla Public License. Note that all licenses of these two organizations have evolved over the years and while some of these changes were motivated by new technologies (case in point: Affero GPL and Software as a Service), I drew the conclusion that getting licenses right is hard. License proliferation makes it difficult to determine license compatibility and understanding what users and developers of the software are agreeing to. As a consequence, I decided that my code should be released under one of the following better known licenses:

Commercial Use

It would be great if I could benefit from commercial use of my software but none of the better known licenses forbids commercial use and it seems to me that you must use dual-licensing in this case. Since using an established license is more important to me than commercial use considerations, I decided to ignore this point.

Patent Protection

A patent holder may contribute code to an open source software project but that does not mean the patent holder granted patent rights to the users of the software. The AGPLv3, GPLv3, LGPLv3, MPL 2.0, and Apache License 2.0 all contain patent use clauses that either grant patent rights or (in layman's terms) forbid enforcing these rights. I wanted a license with patent protection meaning I could not use a BSD license or the MIT license. The GPLv2 provides an implicit patent grant that was deemed not extensive enough for the GPLv3 (see Why Upgrade to GPLv3) but I cannot say how the GPLv2 patent protection compares to the other licenses.

Obligation to Disclose Changes

There is no license that forces changes to be disclosed under all circumstances. The GPL only requires the disclosure of changes if the software is distributed. Hence Google can run a customized Linux kernel (see page 44 in the linked document) without ever disclosing these changes, for example. The AGPLv3 requires the disclosure of changes if the compiled code is distributed or if it is used to provide services over a network so if a company uses programs only internally, then none of the popular licenses requires the company to disclose changes. This raises the question if there exists useful software that is not distributed and not provided as a service and if not, then there would be no "disclosure gap". My solver DCGeig is well-suited for certain problems arising, e.g., in the design of automobiles, aircraft, spacecraft, or submarines and thus, it is exactly the kind of software a vehicle manufacturer does not want to make accessible outside of the company. Now while there may be a disclosure gap, I wonder how one can prove the existence of a piece of software used only internally in a company and the fact the company is in violation of the software license. In conclusion, this point does not narrow down the set of licenses to choose from.

Revoke License as Copyright Holder

So far, we found out that we cannot earn money from licensing our software without a custom license and we cannot enforce the disclosure of all changes. Nevertheless, one might be interested to revoke the license for certain individuals or organizations but such a license cannot be an open source license according to the definition of the Open Source Initiative (see Articles 5 and 6). Also, the GPLv3 contains an explicit irrevocability clause in Article 2. Nevertheless, can the copyright holder revoke the license or not? I found many contradicting answers (no, yes, no, in 35 years in the US, only in Australia). Assuming licenses cannot be revoked, the only possible approach is to put future releases under a different license. Again, we cannot narrow the set of licenses to choose from.

Compatibility with BSD-licensed Code

My eigensolver DCGeig relies heavily on the Python interpreter CPython, the numerical mathematics libraries BLAS, LAPACK, NumPy, SciPy including the linear system solver SuperLU, the graph partitioning software Metis, and soon maybe the sparse symmetric matrix library SPRAL. These software packages are released under the following licenses (in order): Python Software Foundation License (BSD-like), BSD, BSD, BSD, BSD, BSD, Apache 2.0 License, BSD. If I were to release DCGeig under a GNU license, then it would be impossible to make my solver available in, say, SciPy which comes to my mind here because this project had to remove its UMFPACK bindings since the copyright holder changed the license to GPL (see the corresponding GitHub issue #3178). I benefit from these projects and I want to keep the option of allowing these projects to use my work. This choice leaves me unable to use a GNU license.

Why I Licensed My Code Under the MPL 2.0

At this point, I could use the Apache License 2.0 or the Mozilla Public License 2.0. I wanted to ensure disclosure of changes of my code and thus, I decided to put future DCGeig versions under the MPL 2.0. As a bonus, the MPL 2.0 is free of political messages, the license makes concessions if licensees cannot fully comply with it (compare this to the GPLv3, Article 12), the code cannot just be taken und put under a different license (see MPL 2.0 FAQ, Q14.2), the boilerplate license notice that needs to be put at the top of every file is short, and in my opinion the license is quite readable. The article The Mozilla Public License Version 2.0: A Good Middle Ground? highlights the core ideas of this license well.