Committers Agreement Update

The currently-used Mozilla project CVS Contributor Form (PDF) is a piece of project history. The website shows it being checked in back in 2001, and I’m sure it was pretty much the same even before that.

However, the ravages of time have not left it unaffected. It barely squeaked by the change to the tri-license, due to some far-sighted provisions about “other licenses acceptable to mozilla.org”. But as the day when we move away from CVS gets ever-closer, its very name spells its doom.

The editable version of that document is lost in the mists of time. So, one short bit of retyping later, I’ve done a draft update for the form, now titled the Mozilla Foundation Committers’ Agreement. This fixes the issues I know about – it removes explicit references to CVS, and generalises the idea of Code to cover contributions to e.g. our website repositories. The agreement is also now with the Mozilla Foundation, a legal entity. Comments are welcome.

Note that this has not yet been through any sort of legal review, and so will almost certainly change, possibly substantially, before it comes to replace the existing agreement.

12 thoughts on “Committers Agreement Update

  1. “You identify the author of such Code in a checkin comment that includes the name and email address of the author”

    Oops, I’ve just been using names or irc nicks when I commit for others (along with bug numbers from which you can get the contributor’s email address).

    “You make reasonable and appropriate efforts to ensure that such Code complies with the terms of this agreement.”

    Am I the only one who read “Code complies” as “Code compiles” the first time? I got garden-pathed by that misreading.

    “Your name and account will be visible worldwide via the Internet.”

    You mean name and username, right? Where are real names visible?

  2. Jesse: Good points. All bug numbers must lead to email addresses, because the person needs an account to attach the patch. But they don’t necessarily lead to names. Should we permit pseudonymous contributions?

    I don’t know about “code complies”; I’m not sure how to reword it to prevent the problem you had.

    As for “will be visible worldwide”, perhaps it should say “may be visible”, given that yes, it probably isn’t now, but we don’t know what might happen in the future.

  3. I think we should continue allowing people with CVS access to commit patches submitted by pseudonymous contributors for two reasons:

    1. Some security researchers have chosen to be pseudonymous (for legal reasons?) and at least one of them contributes patches to the JavaScript engine.

    2. I can’t easily tell the difference between a real name and a pseudonym that sounds like a real name. When I committed patches by Andreas Lange and Giacomo Magnini and Ryan Polk (Quark), I didn’t do a background check to make sure those were real names.

    Is there any reason not to use patches contributed pseudonymously?

  4. Jesse: You raise good points about the practical problems of mandating that people use their real names. On the other hand, pseudonymous people are harder to find for something like e.g. the relicensing (although I hope we never have to do that particular thing again).

    I’ve had a crack at rewording that part. Tell me what you think.

    Sam: Thanks; I’ve switched to “conforms to”.

  5. “You will verify that committed Code contains appropriate boilerplate licensing text.”

    Is it absolutely necessary? It feels redundant to have a two-line unit test with 20-line license boilerplate. It also inflates the tree size.

  6. Nickolay Ponomarev: Sadly, yes. Section 3.5 of the MPL begins: “You must duplicate the notice in Exhibit A in each file of the Source Code.” We don’t always to do this, which is bad.

    I agree it inflates the tree size; the only way around that is changing the license. However, it doesn’t have to inflate the download size; we can preprocess interpreted files to “compile” them and remove the boilerplate. I have a bug somewhere on doing that.

  7. Do the small NPOB files (I’m still thinking of unit tests) have to be under MPL though? Can we easily have them under a less restrictive license with a one-line boilerplate?

  8. There are no licenses in common use with a one-line boilerplate.

    You could probably submit test cases under the MIT license (the same one used by code snippets on devmo). If you want to do this, let me know and I’ll make certain it’s OK.

  9. “There are no licenses in common use with a one-line boilerplate.”

    It’s a pity.

    Myself I’m guilty of creating testcases with no copyright information in them and don’t think a MIT license is a big improvement over MPL here. What is the reason the code (even tests) must have a license boilerplate in it? Is putting it in public domain with the notice as simple as sqlite’s (http://www.sqlite.org/cvstrac/fileview?f=sqlite/src/analyze.c&v=1.1) an option? Most tests are pretty trivial anyway.

  10. Putting things in the public domain is, at least according to the Creative Commons people, not as easy as it should be in some jurisdictions. Their attempt is still pretty long and still based on US law.

    Everything should really have a license boilerplate because otherwise there’s uncertainty about what terms apply. We haven’t reached that happy state yet in practice, but maybe we will one day.

    Of course, PD dedications are not restricted by the MPL requirement to have the boilerplate in one file. So we could put a file at the root of the CVS tree, and reference it. That would produce one-line boilerplate. Something like:

    “Dedicated irrevocably to the Public Domain. See the file PUBLIC-DOMAIN or
    http://creativecommons.org/licenses/publicdomain/

    Are you interested in having this option available?

  11. I don’t care much about the license on trivial tests, but having an option to put a short sentence in those files instead of the long boilerplate required by the MPL would be great, yes.

    As for the tests without the license I committed, should the MPL boilerplate text be added sooner rather than later, or is it acceptable to wait until we settle down on a solution with shorter boilerplate? How much trouble do such files cause?

    Thank you for your time.