In the previous post, I analyzed the LGPLv3 in the context of looking for a license for the Hel standard libraries. In this post, I'm going to analyze the Mozilla Public License 2.0, or MPL for short. The MPL is not as well known as other free software licenses, but it's an interesting license, so it's worth taking a look at it.
Wikipedia actually has a pretty good summary of the license, and Mozilla has an FAQ about it, but here we go.
[Disclaimer: I am not a lawyer, this is not legal advice, etc.]
The most interesting aspect of the MPL is that it applies copyleft at the file level. Section 1 defines "Covered Software" as:
[…] Source Code Form to which the initial Contributor has attached the notice in Exhibit A, the Executable Form of such Source Code Form, and Modifications of such Source Code Form, in each case including portions thereof.
and "Larger Work" as:
[…] a work that combines Covered Software with other material, in a separate file or files, that is not Covered Software.
Section 3.3 allows distributing a Larger Work under terms of your choice, provided that the distribution of the Covered Software follow the requirements of the license.
In other words, the boundary between software covered by the MPL and other software is defined at the file level, and the license allows distributing a combination of MPL and non-MPL code under another license, provided that the MPL parts still remain under the MPL. Modified versions of the MPL-covered parts, if distributed, must be available in source-code form, but this requirement does not apply to files that were not originally part of the MPL-covered software.
One consequence of this is that one might take a library under the MPL, put all substantial changes in separate files, and release the resulting code in object form, but not the source code for the new files. Contrast this with the LGPL, which has terms specifically to prevent additions to the library from being 'isolated' from the LGPL by distributing them as part of the application rather than the library: as we have seen in the previous post, Section 2 of the LGPL requires that the library does not depend on functions and data provided by the application, unless you switch to the GPL (thus requiring the application to be GPL-compatible too).
Section 3.2(a) allows distributing the code in executable form, provided that the source code for the Covered Software is available, and recipients of the executable are informed how they can obtain it "by reasonable means in a timely manner, at a charge no more than the cost of distribution to the recipient".
Section 3.2(b) states that the executable may be distributed under the MPL or under different terms, provided that the new terms do not limit the access to the source code form of the Covered Software (i.e., the files originally under the MPL).
This means the MPL imposes no restrictions on static linking, other than that the MPL-covered source code remains available, and you tell users how to get it.
Section 1 defines "Secondary License" as one of the GPLv2, the LGPLv2.1, the AGPLv3, or any later versions of those licenses.
Section 3.3 provides that if the software is distributed as part of a Larger Work which combines MPL-covered software and software under any of the Secondary Licenses, the MPL allows the MPL-covered software to be additionally distributed under the terms of that Secondary License.
An important point here is the "additionally" part: the Covered Software is to be distributed under the *GPL license in addition to the MPL, i.e., the resulting code is effectively dual-licensed. Recipients of the larger work may, at their option, choose to redistribute the originally MPL-covered part of the work under either the MPL or the Secondary License(s).
This provision makes the MPL GPL-compatible: you can incorporate MPL-covered code in GPL projects.
The author of an MPL-covered work can opt out of GPL compatibility by adding a specific note saying the code is "Incompatible With Secondary Licenses" (Exhibit B).
Section 2.1(b) ensures that all contributors automatically grant a license for any patents they may hold to use, modify, distribute, etc., the covered software. Section 11 of GPLv3 has similar terms.
Section 2.3 is very careful to state that each constributor grants all and only those patents necessary for use, distribution, etc., of the their contributor version. It does not cover, for example, licenses for code a contributor has removed from their contributor version; or for infringements caused by further modification of the software by third parties (GPLv3 also has similar wording).
Section 2.3 also explicitly states that the license does not grant rights in trademarks or logos. This makes sense in light of Mozilla's fierce hold onto its trademarks and logos, which in the past led to the rebranding of Firefox as Iceweasel in Debian until an agreement was reached between Debian and Mozilla.
Like the Apache License, The MPL has a patent retaliation clause (Section 5.2): it states that if a patent holder sues someone alleging that the Covered Software infringes a patent of theirs, they lose the rights granted by the license to use the Covered Software. This is meant to discourage recepients of the software from suing the authors for patent infringement.
MPL is a weak copyleft license, providing a middle ground between the liberal MIT/BSD/Apache licenses and the *GPL licenses. It makes it really easy to incorporate the code into larger works, regardless of whether this is done via static or dynamic linking. On the other hand, the fact that it does not automatically extend to other files within the same project makes it easy to extend a library without releasing the relevant additions as free software.
I might use the MPL in the future for libraries in situations where the most convienient way to use the library is to just copy the damn files into your codebase (e.g., portable Scheme code). For larger libraries and projects where I want to ensure contributions remain free, I'm not so sure.
I would like a license that's midway between the MPL and the LGPL, allowing generation of statically-linked executables distributable under different licenses like the MPL, but with the boundary between the copylefted and non-copylefted parts defined more like the LGPL (though I'm sure the devil is in the details when crafting a license like this). If you know some license with terms closer to this, please mention it in the comments.
So far the interwebs have pointed me to:
The 0mq license, which is the LGPLv3 with an exception allowing the distribution of executables under any terms. However, the exception "relieves you of any obligations under sections 4 and 5 of this license, and section 6 of the GNU General Public License", which seems to imply you don't have to distribute the source code for modifications at all if you use a modified version of the library in your executable. That's even weaker than the MPL.
(As a side note, it also states that "[i]f you modify this library, you must extend this exception to your version of the library", which I would interpret as a "further restriction" under Section 7 of GPLv3, which therefore can be removed. The 0mq project itself is moving to the MPL, according to their website.)
The wxWindows license, which seems to effect a similar weakening of the LGPL copyleft (see above).
The MPL states:
- 1.10. “Modifications”
means any of the following:
any file in Source Code Form that results from an addition to, deletion from, or modification of the contents of Covered Software; or
any new file in Source Code Form that contains any Covered Software.
A possible solution would be to use a license exactly like the MPL, except with an extra item like:
any new file in Source Code Form that other Modifications in senses (a) or (b) depend on.
The exact wording (to pin down the meaning of "depend on") would have to be figured out.
Copyright © 2010-2024 Vítor De Araújo
O conteúdo deste blog, a menos que de outra forma especificado, pode ser utilizado segundo os termos da licença Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.
Powered by Blognir.
proaxis, 2020-09-17 22:49:25 +0200 #
I also think a viral library version of MPL would be the perfect copyleft compromise. In your Addendum [2] instead of "depend on", I think "explicitly access" would be better. That way the Covered Software needs to explicitly access the new file in order for it to be considered a Modification. I'm pretty sure this would cover the case where functions in the Covered Software get passed data or functions from other files. Those functions or data would not be considered Modifications because they are not explicitly accessed, they are accessed through a function parameter which could be anything.