Mozilla releases a beta of the revised MPL

The Mozilla Foundation released "beta 1" of its upcoming revision to the Mozilla Public License (MPL) last month — the license's first update in more than a decade. Mozilla first set out to shorten, simplify, and modernize the MPL in March of 2010, developing the preliminary revisions based on feedback from its own license compliance team and talks with the Free Software Foundation (FSF) and Open Source Initiative (OSI). MPL 2.0 Beta 1 is open for public comment, which the project hopes to incorporate into a final release candidate in the coming months.

Rewriting in public

The current MPL is at version 1.1, which debuted in 1999. Back at the beginning of the update effort, Mozilla defined a set of issues it wanted to address in the new revision. These started with simplifying both the language of the license as well as its requirements; common terminology in software licensing has changed over the last ten years, and downstream MPL users found several of the notification and re-licensing requirements confusing or difficult. Although the MPL is specific to Mozilla, and derivative licenses could alter jurisdiction-specific terms, Mozilla's global developer community reportedly had trouble with US-centric copyright- and contract-law language, necessitating some globalization work.

Perhaps the most far-reaching changes to the MPL are those that affect its compatibility with the other top-tier FLOSS licenses: namely the GPL, LGPL, and the Apache license, which is a popular choice for web-oriented projects. In addition to Mozilla itself, some high-profile projects use derivatives of the existing MPL, including Sun's Common Development and Distribution License (CDDL), the Yahoo Public License, and several individual projects, such as Erlang and SugarCRM.

Mozilla made it clear at the outset that it was committed to remaining an open source license as defined by the OSI and both a copyleft and free software license as defined by the FSF. However, the project also stated clearly that it would not be considering two potential changes: moving from the existing "weak copyleft" to a "strong copyleft," and incorporating a Software-as-a-Service (SaaS) clause à la the AGPL. Mozilla reasoned that the former change would radically impact the way Mozilla projects function, and the latter — although an important issue — is controversial enough that it would overshadow the work of updating and modernizing the rest of the license.

The first "alpha" draft of MPL 2.0 was released in July, written by Mozilla's MPL team, and was followed by two more alphas in September and October. Although the initial feedback mechanism was the MPL-Update mailing list, beginning with alpha 2 an HTML version of the license was published at the web-annotation site co-ment.com so that interested parties could mark up and comment on specific lines and phrases. Using that system, interested parties can add comments to a shared version of the the current revision, which will be reviewed by the project team.

The co-ment.com utility is very easy to work with, although it allows any user to attach a name and email address to their mark-up without address verification — so be wary if you spot suspiciously-exuberant cheers attributed to key FSF officials (for the record, I did submit four grammatical comments under the username "n8willis" just to see how it worked). Mozilla notes that co-ment.com itself was inspired by the FSF's online annotation tool used in the GPLv3 comment process. It seems a bit ironic that Mozilla chose to utilize a closed-source tool rather than the original — although FSF's own description of the tool as "daunting-to-install" suggests one simple explanation.

The MPL 2.0 alphas were low-profile announcements, but the December beta was the subject of a blog announcement by Mozilla's Mitchell Baker, soliciting comments from the public at large. The draft license is available as plain text, HTML, and PDF, and is accompanied by a discussion document [PDF] that includes justifications for the major changes, plus a full diff between beta 1 and alpha 3 and a full diff between beta 1 and MPL version 1.1.

The terms they are a-changin'

Most of the changes, naturally, took place between MPL 1.1 and the alphas, though 2.0 beta 1 brought its share of tweaks. The new license is approximately 38% shorter (2289 words, down from 3702), thanks to the removal of several definitions in section 1 and some redundant language, plus the consolidation of several sections (such as independent references to requirements that persist in future versions of the MPL). The substantive changes begin with the removal of all instances of the terms "Original Software" and "Initial Developer." These terms were used in MPL 1.1 to make distinctions between the creator of an MPL-licensed work and subsequent contributors; now all "Contributors" and "Contributions" are treated equally.

There are also simplifications in section 3 about distributing executables. MPL 1.1 spends some time discussing the differences between distributing source code and executables, enumerating rules about placing source code on the same physical media as executables, and honoring written offers. The 2.0 beta dispenses with most of that in favor of a much shorter "You must inform third-party recipients of the Executable form how they can obtain a copy of such Source Code form by reasonable means, at no more than a nominal charge." In a related change, section 1 also abbreviates the older version's discussion of what constitutes "source code" — calling it the "form of the work preferred for making modifications." This is meant to simplify debate over things like scripting languages, where the line between executable and source becomes fuzzy.

The beta also simplifies the notification process required of derivative software makers in section 3 considerably. MPL 1.1 required them describe any changes that they made to the MPL source code, to inform their users of all third-party intellectual property claims they were aware of that pertained to the code, and to document API changes that would be affected by patent claims. In several places it even specified that these notifications must be done in a file named LEGAL.The revised section 3.1 states that source distribution requires you to "inform recipients that the Covered Software is governed by the terms of this License, and how they can obtain a copy of this License." Section 3.2 says that executable distribution requires you to make the source available as described in 3.1, and "inform third-party recipients of the Executable form how they can obtain a copy of such Source Code form by reasonable means, at no more than a nominal charge." Reasonable means and nominal charge are not explicitly defined.

Section 5.2 is the "patent defense" clause, stating that initiating litigation (against any entity) involving a patent claim against the software terminates the license. This section was rewritten so that its language was compatible with the Apache license, closing a much-lamented inconsistency between the two. It also explicitly excludes several types of defensive litigation (such as seeking a declaratory judgment) from triggering the termination clause, and clarifies some grace-period language pertaining to restoring someone's right to redistribute the software if they come back into compliance with the license.

The globalization improvements are found in the "Miscellaneous" section, section 8. While the MPL 1.1 specified that litigation about the license could only be brought in the Northern District of California, the new license requires it to be brought in "the courts of a jurisdiction wherein the defendant maintains its principal place of business and such litigation shall be governed by laws of that jurisdiction" — which is seen as simplifying the situation for third-party code contributors.

Section 9 updates and clarifies the Mozilla Foundation as the sole steward of the MPL, removing all lingering mention of Netscape Corporation, and simplifies the language dealing with creating new licenses based on the MPL (essentially, references to Mozilla must be removed and the name of the license changed).

Compatibility with the FSF's license portfolio is dealt with in a new manner in section 10. While MPL 1.1 touched on other licenses only in a "Multiple Licensed Code" section which permitted the Initial Developer to provide a license choice, MPL 2.0 beta 1 allows anyone to designate their own contributions as "Compatible Software" with the GPL (2.0 or later), LGPL (2.1 or later), or AGPL (3.0 or later). Section 10.3 further specifies that developers may distribute a combined, derivative work based on MPL 2.0 code under one of those licenses, provided that they make their own contributions available under the MPL.

These requirements attempt to deal with one of the Mozilla community's unique sticking points, the "single-license fork". The problem occurs when a project builds on top of Mozilla code (which is tri-licensed under the MPL, GPL, or LGPL), but only releases modifications under one of the non-MPL licenses, thus effectively cutting it off from use by other tri-licensed Mozilla projects.

Impact

The revised MPL will probably only have a direct impact on two distinct sets of users: contributors to official Mozilla projects that live in non-US jurisdictions, and developers of outside, derivative projects. The former group benefits from the clearer language around copyrights and patents along with the generalized rules about litigation and jurisdiction. The latter group gets a mixed bag; better compatibility with GPL and Apache licensed works is a definite plus, while those players not interested in licensing their contributions under the MPL may not like the closing of the single-license fork loophole.

On the other hand, the reorganization and simplification of the license text benefits everyone. Ten years is a long time in this industry, and although most people's understanding of the issues and terms used in the MPL has not changed in that time, Mozilla has learned from experience that some of the requirements and clauses were not having the desired effect. The principle example of this is MPL 1.1's section 3.3 — the requirement that downstream redistributors describe all modifications made to the original code and include a statement telling users that the files have been modified from their original forms. Mozilla admits in practice this requirement is usually ignored, and in the era of distributed version control it adds little value.

It will be interesting to see how many of the changes proposed for MPL 2.0 are adopted by downstream licenses. Some, particularly those from projects that build on the Mozilla codebase like Celtx, will likely release new versions of their own licenses to maintain language compatibility.

It's less clear what will happen to the corporate controlled licenses like CDDL. CDDL has entertained proposed revisions on its own development path since its creation, and few if any of Sun's CDDL-licensed products interact with official Mozilla code. It is interesting to note, however, that several of the changes made to CDDL from MPL 1.1 are also incorporated in MPL 2.0 beta 1: use of the term "Software" instead of "Code," elimination of several definitions, and simplifying the distribution requirement language.

On that subject, however, it is also interesting that the CDDL's authors chose to widen the definition of distribution so that it includes application service providers, while Mozilla chose not address network applications at all. The project clearly needs to do so at some point, not just because of its stated commitment to the open web philosophy, but because it develops several high-profile web applications itself: Bugzilla, Bonsai, Tinderbox, Skywriter, Firefox Sync, and the Mozilla Labs Raindrop experiment.

Looking at the comments and the mailing list, there does not appear to be much call from the public as a whole for Mozilla to take a stronger copyleft stance. To review, MPL is regarded by the FSF as a "weak" copyleft because it uses a "per file" copyleft model. In other words, if you make changes to a source file, the modified file must be released under the MPL. But you can link the original MPL-ed software to other code that is published under any license at all (including a proprietary one). In contrast, the LGPL regards linking two applications or libraries as triggering the LGPL's license on the combined work.

Luis Villa, who has spearheaded the public comment and feedback process for MPL, says that the final MPL 2.0 is a "'release when ready' old-school open source process" that may involve another beta before any release candidate version is published, if there are enough comments or questions. The comment system for beta 1 remains open to the public until the team decides otherwise, as does the MPL-Update mailing list. Finally, for those with comments they wish to share away from the public's prying eyes, Mozilla has also established a "private feedback" email address.

Licenses are rarely regarded as exciting and cool, but as everyone in the FOSS universe knows, they constitute the backbone of what keeps free software free and open source open. Of the major licenses in use today, MPL is the second oldest in terms of when it was last updated — only the minimal and unrestrictive MIT/X11 license has gone longer without a refresh. Opportunities to participate in the license-drafting process are rare — so if you have a concern, the time to speak up is now.