Why We Use the Mozilla Public License

The MPL 2.0 is a more modern and development friendly approach to software licensing to protect the copyright of your code than the GPL and LGPL.  Want to see more? Return to our development articles.

This article covers version 2.0 of the Mozilla Public License ("MPL") and does not cover older versions as they are not GPL compatible and considered outdated and out of use. For an introduction on software copyright and licensing, feel free to read our article Basics of Software Copyright and Licensing before continuing.

What is the Mozilla Public License?
The MPL is a file-level copyleft license with MPL licensed code kept independent of others with no restrictions on linking or class inheritance. MPL code can be linked with or packaged with code that has a different license including the GPL series (Affero GPL, GPL, LGPL), permissive licenses (Apache 2.0, BSD, MIT), and commercial licenses. This makes the MPL appealing to both companies and free software/open source projects as the copyleft only applies to the individual files and doesn't affect the licenses of others. Like Apache 2.0, the MPL provides patent and trademark protection.

By default, the MPL is compatible with the GPL family of licenses according to a FSF press release and Mozilla's FAQ. If MPL code is combined with GPL code as part of a larger work, the MPL licensed code is dual licensed under both the MPL and the GPL license. If your MPL code has the optional "Incompatible with Secondary Licenses" clause, your MPL code is NOT compatible with the GPL licenses and is not recommended.

The MPL is an approved license by the Free Software Foundation and the Open Source Imitative and is classified as being both free software and open source compliant. Even though the license is authored by the Mozilla Foundation and used with the Firefox web browser, the license remains independent of Firefox and can be used for any project.

Issues with the GPL versions 2 and up
Like the MPL, the GPL licenses are copyleft in that they require the code to maintain the original license and source code must be provided if any changes are made and distributed. If GPL code is linked or packaged with code of another license, it converts the license of the other code into the GPL and can create licensing conflicts as it cannot be integrated with proprietary code.

Some popular licenses like Apache 2.0 are not compatible with version 2 of the GPL and even though version 3 of the GPL is compatible with Apache 2.0, version 2 of the GPL is still very popular and used for the Linux kernel and Wordpress. The MPL is compatible with Apache 2.0 and other permissive licenses by leaving their existing licenses alone.

What about the Affero GPL?
The Affero GPL ("AGPL") was created to fix a "loophole" with the standard GPL licenses regarding software provided over a network. The GPL licenses do not require the source code for a network application as the work is not being considered distributed. The AGPL requires that the complete source code be made available to the user of AGPL code licensed code and this includes software run on the server like the PHP scripting language.

The AGPL can pose a problem for companies that write web applications and do not want every bit of their code made available. With server side code like PHP, the scripts are run on the server and HTML is outputted for the web browser to understand.

Under the AGPL, the server side code must be provided to all visitors of the site for them to download, modify, copy, and do what they want with it. This is why the AGPL is not a common license and is tailored towards free software and open source projects.

The Lesser GPL
The MPL and Lesser GPL ("LGPL") are weak copyleft licenses requiring the source code of modified and extended versions of the program to be provided under their original license. Both licenses allow integration and linking with software of different licenses (open or proprietary) with subtle differences.

The LGPL is typically used for libraries, yet Section 4 of the LGPL creates concern with class inheritance by placing heavy restrictions on the suitability of object-oriented classes in LGPL software being inherited by non-LGPL code. These restrictions were described in further detail in the FSF's The LGPL and Java article:

"The LGPL contains no special provisions for inheritance, because none are needed. Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls."

In an article titled Why you shouldn't use the Lesser GPL for your next library, the Free Software Foundation doesn't endorse the LGPL for new projects and instead wants the use of the stronger copyleft GPL licenses. With the FSF not endorsing the LGPL fully, the MPL provides an edge over the current LGPL licenses if you are looking to link with or inherit classes from other software that does not share the same license.

Permissive licenses
Code under the GPL and MPL protect the copyright holder by requiring code to stay under the original copyleft license and any derivative works or "forks" must follow that license. The original copyright holder of the GPL or MPL code can change the license at any time, but the owner of a derivative work cannot change the license and is bound to it as long as the project is made available.

Permissive licenses like Apache 2.0 differ by allowing the modification and distribution of the source code without contributing modifications back to the owner or keeping the same license. An individual or company can take code under a permissive license, integrate it with their commercial application, and make money off of the code without involving the original copyright holder.

Some developers see this as unethical stealing of code, while others see it as a way to get their application used or standardized without restriction. Apple and Google's app stores don't favor the GPL licenses and often the only way to get an application on these stores is to put it under a permissive license.

How we use the MPL
When we complete a project or specific service for a client, the client owns the copyright to the custom code with the source code made available to them following the project and is not under a free software or open source license unless requested. We believe in using free software and open source software when necessary for the needs of our clients (like the jQuery JavaScript framework), but also understand that the code is specific to the client and source code distribution outside the organization is not an option. If the client does want to release part of their code under an open license, we will consider the MPL as it will allow integration with customized code or services without affecting the licensing.

For future free software/open source projects created by us, we pick the MPL as our preferred license to encourage community involvement and allow users to adapt where necessary for personal, educational, or commercial use. As an extra bonus, the custom JavaScript code running in your browser right now is under the MPL, so take a look at the source or the associated source map.

For additional resources, you can read The Mozilla Public License - almost 2.0 (part 1) and MPL 2.0, copyleft, and license compatibility by MPL author Luis Villa. GitHub also provides a nice breakdown of the MPL 2.0 at ChooseALicense.com.

submit to reddit