Over the past 18 months, the Mozilla community has been revising the Mozilla Public License. See earlier post. We recently announced, in true community development fashion, a release candidate--the text that we hope will become MPL 2.0 after one last set of eyes review it. This piece is a brief backgrounder on what has changed in the new MPL, explaining why we're proud of this work and we hope you'll consider reviewing it - and maybe even using it for your next project.
Clarity
One of the goals of the MPL has always been simplicity. For example, take the MPL's copyleft. The rule is essentially a simple, bright-line test: does your file include part of an MPL-licensed file? If so, then the MPL governs; if not, then you can use the license of your choice for your code and the resulting binary. This is simpler and more straightforward than the tests for some other copyleft licenses.
With MPL 2.0, we've taken the focus on clarity and simplicity and extended it in two ways. First, and most obvious, we spent a lot of time carefully wordsmithing, even when we weren't trying to change the meaning of the license. A good example of this was the language around "Initial Developers" in MPL 1.1. This language was originally intended to address important, but nuanced, issues around the timing of patent grants. After a lot of work, we were able to address the timing issue without using the "Initial Developer" concept - allowing us to make the license shorter and simpler.
Second, we worked to understand how the MPL was actually being used in practice, and simplify by bringing the license into line with that practice. Remember that when MPL 1.1 was written (starting in the late '90s), large-scale community-driven software development was still relatively rare. It made sense to codify some rules and requirements in the license. Now that many of these community development practices are better understood, we could step back and see what we still needed to be specific about, and what we could be flexible about. For example, to the best of our knowledge, only one project ever used the LEGAL file discussed in MPL 1.1 Section 3.4(a). So we removed that requirement. (If you want to have such a file, the new Section 3.4 still ensures that it can't be removed.) We also simplified the license header boilerplate - maybe the single most-requested change by Mozilla hackers.
Internationalization
Mozilla has always tried to be a global project, but we were aware that the MPL had some clauses that made non-American users less comfortable with the license. One of these was the section on U.S. Government End Users. This was intended to protect the interests of all contributors to MPL-licensed projects, not just Americans, but to a non-lawyer (and even to many European lawyers) the meaning of the section was opaque. Our legal research, and the experience of the past 10 years, suggested it could be removed without impacting the U.S. government's procurement process, and so we did so. Similarly, we've discussed every draft with FSF Europe's European Legal Network, to help ensure that the new language works across jurisdictions, and brought the jurisdiction language into closer alignment with the practices of other open source licenses.
Patents
In response to the changes in the patent landscape over the past decade, the patent language has been changed as well. In particular, suing someone over patents in MPL-licensed software will cause the litigant's rights to that software to be terminated. This should help protect small contributors who don't have patents, since copyrights - and other contributors' patents - can now be used defensively. At the same time, the defensive clauses are now triggered only by a lawsuit over the MPL-licensed software, which should reduce uncertainty for some large companies.
License Compatibility
At the request of our community, one of the focuses of MPL 2.0 was compatibility. We wanted MPL users to be able to use code from other permissively-licensed projects (particularly Apache-licensed code), and likewise to allow the broadest scope for reuse consistent with our copyleft. In short, we achieved that, but this issue is complex enough, and important enough, that I'll write a post here at opensource.com about it in the near future.
What's Next
Because we published the release candidate in true community development fashion, we are also getting another typical part of the open source experience - people coming out of the woodwork with detailed observations close to the final release. This is great; it's hard for laywers to to a .0.1 release, so the more eyes looking at our "code" the better. You can help too by reading the license.
Comments are closed.