MPL Beta 2- as FAQ

I’m still working, albeit sometimes slowly, on the new MPL. Two days ago we announced the release of Beta 2– you should go read it :)

FAQ, by photosteve101/planetofsuccess.com, used under CC-BY

Besides the usual (small tweaks to some language in a further attempt to get it Just Right; improvements to the GPL language; etc.) I also published a bit of an experiment: a draft of the license which replaces the traditional section headers with FAQ questions, like so:

Traditional:

2.2. Grants.

Each Contributor hereby grants You a world-wide, royalty-free, non-exclusive license: . . .

FAQ-style:

2. What rights are granted to me by this license? Who are these rights granted by?

Each Contributor hereby grants You a world-wide, royalty-free, non-exclusive license: . . .

The inspiration for this came from the apartment lease I signed in December, which was done in this style and (oddly) almost a pleasure to read.

This approach has two advantages. First, it helps you draft and organize things more clearly. Since every paragraph was the answer to a question, things were broken up into what normal human beings would consider more logical units, instead of the giant blocks of text legal documents sometimes sprawl into.  Preparing the FAQified version of Beta 2 made us aware of some MPL sections that had this problem, and it helped us reorder and reorganize text as a result- something which you can see in (for example) the new Section 8 of MPL 2 Beta 2, which is part of the old Section 9 broken out so that it makes more sense independently. Because of this, these changes will help every reader of the license, even if we never publish another “FAQified” version.

Second, the questions clue a reader in to the key concepts of a section. It is important that people still read everything. We’ve tried to ensure that the questions do not change the meaning of the “answers;” i.e., the body of the text, both by ensuring that the “answer” or body text is the same between both versions and by disclaiming any changes in the license itself. In other words, this will help non-lawyers understand- but if for some reason, you need to be absolutely sure, you (and possibly your lawyer) need to read the whole thing carefully and without reference to the questions.

We’re looking forward to feedback on this, both from non-lawyers (does this help you understand?) and from lawyers (this is an unusual technique, and so suggestions on how to do it better are welcome). So download it, read it, and let us know what you think.

[postscript: The first comment reminds me that this is only one of the steps we’ve taken to simplify and clarify the license. Most notably, Beta 2 is almost exactly 1/2 the length of  MPL 1.1, but we’ve also worked with Mozilla folks to simplify requirements where the old license was over-specific, and with lawyers with a reputation for good writing on how to simplify language and remove redundancy. But there is still time to make it even better, so please continue reading and giving feedback!]

14 thoughts on “MPL Beta 2- as FAQ”

  1. This is a really great, smart approach to take and makes the whole thing a lot more interesting to read. Yay!

    I did take some notes, but not many:

    Question 1 feels like it should logically come after Question 2 — I actually had to read it more than once to realize that the first one started with “When are rights…”, not “What rights are…”. My brain just really wants “What” to be first, with “When” as a follow up.

    I would kill for this to be hyperlinked, or at least to have hover-over tooltips for definitions :) It might be worthwhile to emphasise the bit about definitions in the preamble a bit more — maybe give that part its own sentence/paragraph? I found it jarring to leap immediately from the preamble into a sentence that used Contributor and Contribution multiple times without having those defined up front. (I might just be used to old skool licenses though.)

    References to answer numbers followed by section numbers is a little confusing. I can find “Answer 25” just fine, but I have no way to identify “Section 11” which is apparently the same thing. Not sure what that’s about — are the section numbers maintained in a non-FAQified version? That maybe could be clarified in the preamble.

    That’s really all I had. I love this format.

  2. I hope that next week I will post an HTML version and beg for help on that :) I have one already, whose HTML is almost identical to this stunning piece of web c. 1999: http://www.mozilla.org/MPL/MPL-1.1-annotated.html So, you know, this being 2011 and all, and some MPL-impacted people having “web skillz” maybe we could do better :)

    You’re also not the first to want “what” before “when”; I’m guessing we’ll probably switch that back.

    I’m not really sure about the questions/section numbers; that’s still a bit of a work in progress. I think the tentative idea was to publish both versions (faq-ified, non-faq-ified) with only the “standard” version being official, so some reference to sections probably makes some sense. Open to suggestions there.

  3. Some sections work really well as questions (“What must I do when I distribute this source code?”, though I might change it to something like “…if I want to distribute…” since “when” makes it sound almost mandatory). But other questions just sound silly (“What additional grants do contributors make to me if I choose to use another license?” No one would ever actually ask that question.) This might be fixable with more reorganization.

    ALSO, IT’S 2011. CAN’T WE DO BETTER THAN ALL CAPS YET? ESPECIALLY SINCE IT’S WELL ESTABLISHED THAT BEING IN ALL CAPS MAKES IT HARDER TO READ AND UNDERSTAND THE TEXT, WHICH IS PRESUMABLY EXACTLY THE OPPOSITE OF WHAT IS INTENDED. HA HA. THAT WOULD BE PRETTY FUNNY IF SOMEONE IN COURT CLAIMED THAT THE AUTHOR OF A LICENSE/CONTRACT WAS INTENTIONALLY TRYING TO DECEIVE THEM BY HIDING IMPORTANT DETAILS IN ALL CAPS, AND SO THEREFORE THAT SECTION OF THE LICENSE/CONTRACT SHOULD BE IGNORED.

  4. Ping me if you want help with any thing…next week is busier than usual (allhands), but should be around on IRC here and there.

  5. But other questions just sound silly … This might be fixable with more reorganization.

    Please flag any others that sound silly to your ear. There is only so much we can do, but we’ll give it a shot.

    re ALL CAPS: See discussion at http://www.typographyforlawyers.com/?page_id=1772, but also note the comments about some jurisdictions requiring limitations of liability to be “conspicuous,” and in some cases even literally all caps. That’s a strong tradition among lawyers, and I’m not sure there is that much we can do to change it. That said, I will see if, at least for the web version, we can do something else to make it better- maybe small caps?

  6. Interesting, didn’t realize that the standard MPL allows licensee to pick any later version (GPL leaves that choice to the copyright holder).

    The language of section 11 is a bit confusing to me. What does “Unless the Covered Software is Incompatible Software” mean? Is that for software covered by both MPL and another GPL-incompatible license, or for a software allowed under MPL but not under GPL (i.e. because it, in turns, link to a GPL-incompatible library)?

    Also, the FSF seems to think that MPL is GPL-incompatible due to “some complex restrictions” (it is unfortunate that their license incompatibility page is so vague and does not carry specific arguments). Are all those addressed?

    If so, and if CDDL follows suit, the only GPL-incompatible license left will be the EPL :)

  7. Michel: Yes, MPL is different from GPL on the impact of new versions. You’re not the first to be a bit surprised by that, but it has been there for a long time :)

    Sec. 11 is designed to take effect only where the original author intended to allow compatibility, since this is such a big change. So, if the software is Incompatible (either because the author specified it as such by adding the header, or because they used MPL 1.1 without the tri-license) then you can’t take advantage of the additional GPL compatibility.

    We have dealt with some of the FSF’s objections (for example by tweaking the patent language.) Some were not resolvable directly, so we devised Sec. 11 to resolve the remainders.

    Let me know if this answers your questions; I’m not sure it did :)

  8. […] MSCD has extensive discussion of how documents should be structured (Chapter 4). Because of the overall simplicity of this document, I have not changed much. However, it recommends providing headings for sections (MSCD 4.15-21). As with many of the things that seem nitpicky at first, attempting to apply MSCD’s rules can expose substantive problems. In this change, I drafted headings for each section, but my attempt to write a meaningful heading for Sec. 3 suggests that it is not well-organized, and could be usefully split up into smaller sections. (A common problem; I ran into it with MPL.) […]

Comments are closed.