Last week the Mozilla Foundation released version 2.0 of the Mozilla Public License. Immediately recognized as a free software license by the Free Software Foundation and approved as an Open Source license by the Open Source Initiative, MPL 2.0 is a well-crafted modern license that ought to be considered by any open source project desiring a weak copyleft licensing policy.
MPL 2.0 preserves the main features of its predecessor, though with clearer and more concise language. It remains a "file-based" copyleft. While the association of weak copyleft scope with the source file boundary has been the subject of occasional and reasonable criticism, it has the great advantage of certainty. (I generally view other varieties of weak copyleft licenses as reducing to file-based copyleft in many, if not most, circumstances.) The MPL continues to have a somewhat more robust approach to patent licensing and patent termination compared to other popular contemporary open source licenses (apart from the GPLv3 family). Like other weak copyleft licenses, MPL 2.0 continues to allow the licensing of executable versions under more restrictive terms. On the other hand, the new license now states quite explicitly that the MPL is appropriate to use as a sublicense for binaries built from MPL-licensed source code, which will be the approach taken by any mainstream Linux distro.
Without question (at least to us libre license geeks), the most interesting feature of MPL 2.0 is its new mechanism for achieving compatibility with the GNU license family. (It is also a feature of MPL 2.0 to which I feel I may have made some small contribution through discussions with representatives of Mozilla, the FSF and the Software Freedom Law Center.) A detailed discussion of license compatibility is beyond the scope of this article. It is sufficient to be aware that the MPL and the GPL have historically been regarded as having conflicting license requirements that prevent licensees from forming distributable GPL-licensed works partly out of MPL code. Mozilla eventually addressed this problem for most of its own projects by disjunctively "tri-licensing" them under the MPL, GPLv2-or-later, and LGPLv2.1-or-later. This did not solve the compatibility problem for code that was solely MPL-licensed, of course.
MPL 2.0 provides a more elegant internal solution, available to new MPL projects (and to upgraded MPL 1.1 code that was also licensed under a GNU license), although MPL licensors may opt out of the compatibility scheme. In essence, MPL licensees distributing "Larger Works" formed by combination with GNU-licensed code are permitted to additionally distribute the MPL-covered portion of the work under the GNU license, which then gives downstream recipients a disjunctive MPL/GNU license for the upstream MPL portion. For good explanations of this compatibility mechanism, see the FSF's comments on MPL 2.0 and Mozilla's own FAQ on the subject.
Though it is far from obvious, MPL 1.1 had some influence on the drafting of GPLv3, which I worked on in a former life. The "lawyerliness" of GPLv3, which admittedly has been the subject of some criticism, was inspired at a general level by the style of MPL 1.1. GPLv3 also borrowed the ingenious concept of the "contributor version" from the MPL, similarly using it in its patent license grant provision. I therefore delight in seeing the direct influence of GPLv3 on MPL 2.0 in two provisions: the two-part cure opportunity and the explicit assurance that downstream upgrading to a later license version adds no new obligations on upstream licensors.
Despite its merit, I do not expect MPL 2.0 to see wide adoption as an open source license outside the Mozilla project universe (which was not a goal of Mozilla for MPL 2.0, much as wide adoption was not a goal of the FSF for GPLv3). I have three reasons for this prediction; of course I would be happy to be proved wrong.
First, MPL 1.1 never gained sufficient popularity among developers outside the Mozilla community to establish the MPL as a popular license "brand" (for lack of a better term). (By contrast, the popularity of GPLv3 among younger projects seems mainly to be a consequence of the pre-GPLv3 strength of the GPL brand.) As I noted in my 2010 article on the MPL revision launch, MPL 1.1 did enjoy a more dubious form of popularity, which is unlikely to recur. During the strange era of the open source bubble, MPL 1.1 served as a basis for many ill-conceived derivatives, which at best were corporate "vanity licenses", and at worst were quite undeserving of the "open source" label. These MPL derivatives collectively covered very little software, most of it now obsolete. The one important exception to these generalizations is Sun Microsystems' CDDL, which was a true improvement on MPL 1.1, and which continues to cover a substantial amount of important open source software. I encourage Oracle, the current CDDL steward, to consider relicensing its CDDL code under MPL 2.0, which is as worthy a successor to CDDL 1.0 as it is to MPL 1.1.
Second, and in a sense a corollary to the preceding point, the MPL is tied closely to the great success of the Mozilla brand. This strong brand association will probably limit uptake of MPL 2.0 outside of Mozilla, somewhat paradoxically. Another meritorious weak copyleft license, the Eclipse Public License, suffers from a similar problem. To be sure, free software licenses with such brand associations do sometimes overcome them and go on to enjoy extraordinary popularity well beyond the project community of origin. This happened, of course, with the GPL and LGPL in the 1990s, and has happened more recently with the Apache License 2.0.
The final reason is suggested by that last observation of the ascendancy of the Apache License. Though it is speculation based only on my personal impressions, I believe that the concept of weak copyleft has been losing relevance, with community projects increasingly choosing between either strong copyleft or a standard noncopyleft license. Developers who favor copyleft will tend to favor strong copyleft, while those who prioritize technology adoption over commons preservation will naturally favor permissive licenses. The clarity of the MPL's file-based copyleft illustrates why this might be so. Copyleft advocates may see the weakness of this copyleft as ease of circumvention, as Richard Stallman himself did in his 1998 critique of the MPL's ancestor, the Netscape Public License (see the section titled "Not a copyleft"). Those who seek widest possible reuse of their software may find the relatively minimal copyleft requirements of the MPL no less of an obstacle to that goal than the requirements of the GPL, AGPL and LGPL.
1 Comment