In my previous posts, I discussed the new features of the MPL and the new compatibility between MPL and other licenses. In this final post, I'll summarize a few other small details about the new MPL that may be of interest to opensource.com readers.
Why Does MPL Matter?
Whenever you consider writing a new license, there is an obvious question: why? Purely from the perspective of the MPL, the question is fairly easy: over the past ten years, how open source software is developed, how copyright licenses are interpreted and enforced, and the overall state of the art in free software licensing has changed. In light of these sorts of changes, it makes sense to reevaluate licenses on a regular basis and make sure that we're still offering the best license we can. Of course, you can go overboard - no one wants to train lawyers and developers on a new license on a regular basis. The decade we waited seemed like a pretty good time period to us, and we hope that (barring significant changes in the law) this one will last another decade or two.
In the more general sense, it's possible to ask "why do we need a mild copyleft license? Aren't Apache or LGPL good enough?" The MPL's mild copyleft strikes a balance that has worked well for Mozilla, and so Mozilla wanted to keep using it. That was a good enough reason to embark on the project. Over the course of the project, I also personally came to realize that there is an important place in the spectrum of free software licenses for a license that requires some sharing, but makes that sharing simple, clear, and without any strings attached. This is a common desire, but people aren't always able to articulate it, and so they sometimes choose licenses that don't do a good job of matching their needs. MPL has been that license in the past for a number of non-Mozilla projects and I hope that, with the new version, it will find even wider acceptance.
What Took So Long?
Another common question has been "what took so long?" If you're brilliant, like Mitchell, you can write one in a brilliant flurry of a few weeks, but for the rest of us, it takes time to get it right. Andrew Macgillivray of Twitter explained many aspects of the problem when discussing writing contracts:
[I]imagine the contract as a computer program. In each the object is to be able to interpret the words and have that interpretation drive a result. Now imagine that there is no compiler for your program and that you can't run any tests. All debugging must be done only theoretically and in your head. ... You and the other [coder] take turns editing the code but without a common coding environment or standard tools to figure out whether the other person (or you) goofed it up. Then imagine that the code you are writing has a high probability of only ever being "run" through two different interpreters with significantly conflicting points of view about desirable outcomes and you likely won't get to see the result of any of these "runs."
And Andrew was only describing a contract negotiated between two parties! In our case, all the factors he describes play into it, and many different constituencies had to be consulted. Each piece of their input had to be weighed carefully - both for the legal impact and to understand the possible motivations behind the suggestion. All of that without the equivalent of test-driven development.
Time constraints on a variety of the people involved also played a role, of course, but the generosity of my new boss both before and after I joined Greenberg Traurig helped deal with that, in a way that was more than most young lawyers have any right to expect.
Open Source Tools
Three open source tools have been so helpful in our process that I'd like to give public thanks to their authors:
-
pandoc: The master document has been kept in the markdown format, and pandoc has been used to produce basically all versions of the document that you can see at mpl.mozilla.org (though some have been post-processed in a variety of ways). Responses to my occasional odd post to the mailing list have always been helpfully dealt with.
-
dwdiff: It's important for lawyers to be able to see the difference between versions, but regular diff doesn't cut it, because if you change one word, the entire paragraph shows up as changed. The solution was dwdiff. Not only has the tool filled an important gap for us, the author was kind enough to make some fixes in the code as well, making it easier for me to use.
-
co-ment: Besides traditional feedback tools like a mailing list and (gasp) the telephone, we've been using co-ment to gather comments and changes throughout the process. It's been very valuable, and the comments collected there have led directly to changes in the MPL at each stage of the process, even from RC 1 to RC 2.
Who Helped?
The list of people who helped with the new MPL is insanely long, so I'll avoid a name-by-name review that will inevitably leave people out. That said, there are several classes of people who helped. The usual open source licensing suspects were all there: FSF, OSI contributors, and lawyers from major open source participants like Red Hat and Novell all read, reviewed, and had substantive comments. Major users of open source (some you've heard of like Intel and HP, and some you haven't) also gave detailed and thoughtful analyses, particularly early in the process. Several independent lawyers (most notably members of the Freedom Task Force list) gave good feedback, particularly on European issues. A variety of Mozilla community members had thoughtful feedback, especially in explaining how and why MPL 1.1 had rough edges that needed to be identified and trimmed.
Finally, I'd particularly like to thank the great number of non-Mozilla, non-lawyers took the time to read the drafts carefully and give us feedback, whether through co-ment or other channels. This can't have been fun; while MPL 1.1 was better than most legal documents, and MPL 2 (we hope) is even better, it's still non-lawyers volunteering to slog through a legal document. That's a big commitment to make, and many people did it anyway. Equally importantly, many of their suggestions bore fruit, both by giving us a sense of how the license is used in the real world and often by catching wording or language that was unclear and could be improved (that vs. which, for example). As a result, the final product was even better - and because of people who really probably had more fun things to do.
Where Next?
We hope to finalize the license in the very near future, and with it, get OSI and FSF approval. In parallel, Mozilla (after some discussion) will adopt it for Mozilla products. After that? Well, I hope to be a great help to whoever writes MPL 3.0, and I hope that process happens in 2030 or thereabouts ;) See you then!
Comments are closed.