New Committer's Agreement
Gervase Markham
Agreement[0], which used to be the CVS Contributor Form. This is the
document everyone signs in order to get permission to check in to our
repositories. There's a FAQ[1] about the new version. Among the changes are:
* Generalise to all SCMs and accounts;
* Agreement is now with the Mozilla Foundation, a real legal entity;
* Information on permitted licences has been updated;
* ...and various other tweaks to match current practice. See:
http://wiki.mozilla.org/Committers_Agreement:Changelog
We would like all existing Committers to sign a copy of the new
agreement. Details of what to do are in the FAQ[1], but if you are
coming to the Firefox Summit, there'll be an opportunity there and we'd
actually prefer it if you wait. Less hassle all around.
If you aren't coming, there's no rush at the moment, so add it to your
ToDo list. After the Summit (which is at the end of July) we'll be
chasing people who haven't filled one in yet.
If people have questions, comment here.
Gerv
[0]
href="http://www.mozilla.org/hacking/committer/committers-agreement.pdf
. Yes, we had the apostrophe discussion. My current view is that it's
each copy is an agreement for a single committer, and so the apostrophe
goes before the S.
Johnathan Nightingale
I have a question about section 5:
> You understand that cryptographic Code may be subject to government
> regulations with which the
> Mozilla Foundation and/or entities using such Code must comply. Any
> Code which contains any of the
> items listed below must either be checked-in to a module explicitly
> identified as containing cryptography,
> or must not be checked in until the Mozilla Foundation has been
> notified and has approved such
> contribution in writing.
> a) Cryptographic capabilities or features; or
> b) Calls to cryptographic features; or
> c) User interface elements which provide context relating to
> cryptography;
> d) Code which may, under casual inspection, appear to be
> cryptographic.
Aside from the parenthetical that MUCH of our code may "appear to be
cryptographic" (har har), my question is around 5c).
Much of the code I work on (and would be committing-- HAVE been
committing) is quite aptly described as "user interface elements which
provide context relating to cryptography." Ref, for example, Larry,
security page info, and the Firefox-specific overlays to the PSM SSL
error pages.
Are these check-ins verboten under this agreement? They would seem to
be, to me, unless "browser" is "a module explicitly identified as
containing cryptography" which I don't think it really ought to be.
That phrase, to me, sounds like a FIPS-style notion of a "cryptography
module" like NSS, which Firefox is not. I recognize that language
substantially identical to this was in the old agreement as well, I
guess I'm just trying to understand why it was kept intact, given the
current development (and crypto-political) landscape.
The FAQ attempts to address this, insofar as it says "this mostly
applies to NSS" and "ask Frank if you're not sure" but that still
leaves things pretty open. Can this post be taken as asking Frank,
for the record? And can his reply maybe augment the current FAQ
content? I am obviously far from the only one who would be doing this
kind of check-in.
Cheers,
Johnathan
> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance
---
Johnathan Nightingale
Human Shield
joh...@mozilla.com
Axel Hecht
Right, I guess that each and every localizer does that, too.
Axel
Frank Hecker
> Much of the code I work on (and would be committing-- HAVE been
> committing) is quite aptly described as "user interface elements which
> provide context relating to cryptography." Ref, for example, Larry,
> security page info, and the Firefox-specific overlays to the PSM SSL
> error pages.
>
> Are these check-ins verboten under this agreement?
I'll take a shot at answering this, under the usual disclaimer: I am not
a lawyer, this is not legal advice, this is not an official statement of
the Mozilla Foundation, this is my personal opinion only. I apologize in
advance for dumping a lot of background information on you, but IMO
that's the best way to understand why agreements like these are written
the way they are.
First, "cryptography" vs. "encryption": Strictly speaking US export
control regulations were and are most focused on code that does
encryption. Cryptographic operations whose primary function is not
encryption, e.g., hash functions ike MD5 and SHA-1, were for all
practical purposes not subject to US export control; ditto for things
like digital signature verification. However there was some fuzziness on
this topic (e.g., since the RSA algorithm could be used for both
signature verification and encryption), so lawyers writing agreements
like this tended (and still tend) to use the more general term
"cryptography".
Second, the issue of crypto-related UI elements, crypto APIs, and so on:
The US export control regulations envisioned a "sealed box" model where
users got crypto functionality that was tightly controlled, and they
couldn't "reach in" and mess with the controls, particularly to increase
the encryption strength. So, for example, the regulations attempted to
control things like UI that had to do with key size and related
parameters, and also control APIs that called into crypto libraries
(because of the possibility of replacing the original library with one
hacked to support stronger encryption). Again, this broadness in the
regulations got reflected (and still is reflected) in legal documents
like the committer's agreement.
Third, why this is still relevant: For many years now US export control
regulations have permitted unrestricted export via anonymous download of
encryption code that's open source in nature. (The exact definition in
the export control regulations includes everything we'd think of as open
source or free software, but also includes some other "free as in beer"
code as well; for example, I think at least some Microsoft "shared
source" might qualify.) So from that point of view the issues I
discussed above (cryptography vs. encryption, core crypto code vs.
related code) really don't matter, in the sense that you could put
encryption code anywhere you wanted in the tree and it wouldn't affect
the exportability from our point of view.
However, while "going wild" with encryption code wouldn't affect us in
normal circumstances, it *would* affect downstream licensees that use
our code to build proprietary products, because the US export control
exemption we take advantage of (technically, the ability to export under
license exemption TSU) doesn't apply to traditional proprietary
products. Instead they have to go through export review like in the old
days, and that review is more complicated if encryption code is
scattered willy-nilly through the codebase instead of being isolated to
one or two modules.
So, the bottom line: It is in our overall interest to keep track of
where people are putting crypto code in general and encryption code in
particular, and to isolate that code into as few modules as possible.
That's why crypto code is still called out as a special case in the new
committer's agreement. As to the UI issue, IMO the major concern is with
UI that directly affects encryption strength, e.g., selection of TLS/SSL
ciphersuites, and UI that has to do with selection of underlying crypto
libraries (e.g., the UI to load and enable PKCS#11-compliant crypto
modules). Other UI like display of certificate data is IMO not really an
issue, since it is not directly related to encryption.
Do the above comments address your concerns?
--
Frank Hecker
hec...@mozillafoundation.org
Johnathan Nightingale
On 11-Jun-08, at 10:31 AM, Frank Hecker wrote:
> I'll take a shot at answering this, under the usual disclaimer: I am
> not
> a lawyer, this is not legal advice, this is not an official
> statement of
> the Mozilla Foundation, this is my personal opinion only. I
> apologize in
> advance for dumping a lot of background information on you, but IMO
> that's the best way to understand why agreements like these are
> written
> the way they are.
> So, the bottom line: It is in our overall interest to keep track of
> where people are putting crypto code in general and encryption code in
> particular, and to isolate that code into as few modules as possible.
> That's why crypto code is still called out as a special case in the
> new
> committer's agreement. As to the UI issue, IMO the major concern is
> with
> UI that directly affects encryption strength, e.g., selection of TLS/
> SSL
> ciphersuites, and UI that has to do with selection of underlying
> crypto
> libraries (e.g., the UI to load and enable PKCS#11-compliant crypto
> modules). Other UI like display of certificate data is IMO not
> really an
> issue, since it is not directly related to encryption.
>
> Do the above comments address your concerns?
First of all, thanks for the background - I don't think I had properly
considered the impact it would have on prioprietary downstreamers
before.
I think this mostly answers my question, or at least, I think it
certainly answers it for people like Axel. It sounds to me like
you're saying that l10n changes and other things which are peripheral
to "doing" cryptography are perfectly fine to go on as usual. It also
helps answer it for UI developers who might be working on presentation-
level changes to our identity & security UI; they too seem clear.
I'm less clear about things like the exception dialog in PSM, or
future work I might do on, e.g., our client certificate management
UI. Those also aren't "doing" crypto, but like selection of
ciphersuites, they have a direct impact on the crypto that gets done.
I *think* I understand you to be suggesting that those too are not an
issue, since there is no new "weapons-grade" cryptography being added,
and hence nothing new that would complicate auditing of code, or
otherwise risk contravening export restrictions.
I don't want to sound like I'm splitting hairs nor trying to play
lawyer. It sounds to me like you're suggesting the acid test here is
really something like "does this alter the magnitude or breadth of the
(ahem) weapons we are exporting?" to which I think I can confidently
answer in the negative.
Thanks again for the explanation - if I've gotten things wrong here
let me know.
Cheers,
Johnathan
Frank Hecker
> I'm less clear about things like the exception dialog in PSM, or future
> work I might do on, e.g., our client certificate management UI. Those
> also aren't "doing" crypto, but like selection of ciphersuites, they
> have a direct impact on the crypto that gets done. I *think* I
> understand you to be suggesting that those too are not an issue, since
> there is no new "weapons-grade" cryptography being added, and hence
> nothing new that would complicate auditing of code, or otherwise risk
> contravening export restrictions.
That's a reasonable interpretation IMO.
> I don't want to sound like I'm splitting hairs nor trying to play
> lawyer. It sounds to me like you're suggesting the acid test here is
> really something like "does this alter the magnitude or breadth of the
> (ahem) weapons we are exporting?" to which I think I can confidently
> answer in the negative.
Again, I think your interpretation is reasonable.
Really, the major concern I have (much more so than UI issues) is people
implementing their own encryption code outside the context of places
like NSS where encryption is supposed to be done. First, the encryption
implementation could be bad (doing encryption correctly is hard, as the
recent Debian weak key problem shows). Second, it complicates export
review for those downstream licensees who are subject to it. Third, it
causes problems for US government users who rely on FIPS 140-2
validation of NSS, since it introduces non-validated crypto code into
the products.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
John J. Barton
> We've just published version 2.0 of the Mozilla Committer's
> Agreement[0], which used to be the CVS Contributor Form. This is the
> document everyone signs in order to get permission to check in to our
> repositories. There's a FAQ[1] about the new version. Among the changes are:
>
> * Generalise to all SCMs and accounts;
> * Agreement is now with the Mozilla Foundation, a real legal entity;
> * Information on permitted licences has been updated;
> * ...and various other tweaks to match current practice. See:
> http://wiki.mozilla.org/Committers_Agreement:Changelog
>
> We would like all existing Committers to sign a copy of the new
> agreement. Details of what to do are in the FAQ[1], but if you are
> coming to the Firefox Summit, there'll be an opportunity there and we'd
> actually prefer it if you wait. Less hassle all around.
>
> If you aren't coming, there's no rush at the moment, so add it to your
> ToDo list. After the Summit (which is at the end of July) we'll be
> chasing people who haven't filled one in yet.
>
> If people have questions, comment here.
A persistent issue in open source code evaluation concerns the authority
of the committer when they are employed by a corporation. Often the
corporation has an explicit claim on the employees professional output,
whether or not the employee expects it. I don't know the legal
situation, but I imagine that any US employee who is "exempt", meaning
among other things they don't clock hours, may find their off hours work
to be on hours after all.
So the clause about committing on behalf of your employer may be broader
than many people realize.
John.
Gervase Markham
> A persistent issue in open source code evaluation concerns the authority
> of the committer when they are employed by a corporation. Often the
> corporation has an explicit claim on the employees professional output,
> whether or not the employee expects it. I don't know the legal
> situation, but I imagine that any US employee who is "exempt", meaning
> among other things they don't clock hours, may find their off hours work
> to be on hours after all.
>
> So the clause about committing on behalf of your employer may be broader
> than many people realize.
That may be true. It's the responsibility of each committer to make sure
that they have rights to the code they commit. It's not really something
we can police.
Gerv
Justin Wood (Callek)
possible way to submit online (without a physical paper), is there any
information on "when" we need these in by?
/me doesn't want to bother with extra ink/paper/mail if its not needed.
--
~Justin Wood (Callek)