Image Description
Mozilla Public License 2.0
The MPL sits in a rather useful middle ground.
It has copyleft, but the copyleft works at the level of covered source files rather than simply saying every file in a larger project has to use the same licence.
What does it mean in normal English?
Very roughly: if you change MPL-covered files and distribute them, those covered files stay under the MPL and their source remains available as required. But separate files in a larger program can use other licences.
What does "file-level copyleft" mean?
Imagine a program has twenty source files. Two came from an MPL project and eighteen are your own.
If you modify the two MPL-covered files, the MPL continues to apply to those files. Your separate files do not automatically become MPL merely because all twenty files are used to make one application.
Can MPL code be used in closed-source software?
Yes, it can be combined into a larger work with files under different terms.
The MPL-covered files still need to be handled according to the MPL, including its source-code requirements.
What if I distribute only an EXE?
MPL 2.0 allows executable form to be distributed under different terms, but it also has requirements for making the Source Code Form of the covered software available and telling recipients how to obtain it.
Your executable terms cannot take away the rights recipients have to the MPL-covered source.
Can I sell MPL software?
Yes. Commercial use is allowed.
Does MPL deal with patents?
Yes. MPL 2.0 contains a patent licence from contributors for relevant patent claims and includes termination provisions.
As ever, if patents are actually important to your business or project, read the real thing and get qualified advice when appropriate.
MPL or LGPL?
Both can be useful when you want some copyleft without necessarily applying the same licence to every part of a larger application.
They go about it differently. MPL's boundary is based around covered files. LGPL has rules designed particularly around libraries and combined works.
An example
You take an MPL-covered file, fix a bug in it and include it in a much larger application containing your own separate files.
When you distribute the application, the changed MPL file remains covered by MPL and its source needs to be available as required. Your own separate source files do not automatically become MPL.
Why might I choose MPL?
It can make sense when you want improvements to particular covered files to stay open, while still making it practical to combine those files with a larger project using other licensing terms.
Further reading and external resources
Previous: GNU AGPL | Next: Creative Commons licences and software