Closed Bug 369879 Opened 13 years ago Closed 11 years ago

Create contributor agreement for use by corporations, others

Categories

(mozilla.org :: Governance, task)

PowerPC
macOS
task
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: hecker, Assigned: hecker)

Details

Attachments

(1 file)

Per a suggestion in bug 342029, I propose that we create a contributors agreement for use by corporations and others that want to make blanket contributions of code  to the Mozilla project. Note that the purpose of such an agreement would simply be to confirm that employees of the corporation are authorized to contribute code, and that the code can be distributed under appropriate licenses. It is *not* the intent for us to start requiring formal assignment of copyrights or anything like that.

Here are a couple of examples of contributor agreements used in other contexts:

http://www.apache.org/licenses/cla-corporate.txt
http://code.google.com/legal/corporate-cla-v1.0.html

Please feel free to submit other example agreements, along with your comments on the pros and cons of each.
As a point of interest, the Google agreement appears to have been closely modeled on the Apache agreement; they appear to be almost identical. One substantive change I noted is that the Apache agreement contains the following language not in the Google agreement (immediately after the sentence beginning "You accept and agree ..."):

"In return, the Foundation shall not use Your Contributions in a way that is contrary to the public benefit or inconsistent with its nonprofit status and bylaws in effect at the time of the Contribution."

Similar language would IMO be appropriate for any Mozilla contributors agreement.
I have put an initial copy of the Apache Corporate CLA here:
http://wiki.mozilla.org/Corporate_Contributor_Form
It comes from the Apache version and so includes the paragraph Frank mentions in comment #1.

I have not made any Mozilla-specific suggested modifications to it as yet.

Some things I noticed:

- The Apache CLA is a sort of joint copyright - that is, while the contributor retains all the rights to their contribution, they also give a general copyright license to the Foundation and to everyone else to do anything they want with the software (section 2). In other words, the grant does not itself put software under the Apache License.

- The CLA has a limited patent retaliation clause. Adopting it would make the Mozilla Foundation de facto take a position on patents.

Gerv
Please make sure that the new form is VCS-independent, as we're using a lot more than CVS now.
Reed: the Apache form is VCS-independent.

Gerv
(In reply to comment #1)

> "In return, the Foundation shall not use Your Contributions in a way that is
> contrary to the public benefit or inconsistent with its nonprofit status and
> bylaws in effect at the time of the Contribution."

Bear in mind that above is really what the law may well require of the non-profit or non-for-profit. So it is fairly 'fluffy'. 

While I have seen it having the downside of 'panicing' corp. laywers as it is a bit open ended or ill-defined from their end.
Eek - you want to remove the patent retaliation claused form the apache sample - as you have not yet taken 'any' patent position. And doign so would make you do so.. 
(In reply to comment #6)
> Eek - you want to remove the patent retaliation claused form the apache sample
> - as you have not yet taken 'any' patent position. And doign so would make you
> do so.. 

I'm working with a lawyer to create an initial draft of a corporate contributors agreement; it is not a clone of the Apache agreement, and we did not include the Apache patent retaliation clause.

(In reply to comment #5)
> (In reply to comment #1)
> 
> > "In return, the Foundation shall not use Your Contributions in a way that is
> > contrary to the public benefit or inconsistent with its nonprofit status and
> > bylaws in effect at the time of the Contribution."
> 
> Bear in mind that above is really what the law may well require of the
> non-profit or non-for-profit. So it is fairly 'fluffy'. 

If I understand you correctly, you are proposing that we *not* include the above language from the Apache agreement. If so, I agree with you: The Mozilla Foundation is already subject to US and California law requiring it to act in accordance with its nonprofit status, so the language is strictly speaking redundant, and thus can be omitted.

Also, I didn't make this clear in my last comment, but my intent is to work internally within the Foundation to create an initial draft of a corporate contributors agreement, and to post that draft for public comment once it's completed.

Comment from one of our lawyers about the old agreement. Here for posterity:

I'd say at least one issue I have with the CLA is that is seems to indicate employer approval is necessary only if you are contributing using an account associated with an employer. Frequently, you are obligated to assign IP rights to an employer whether or not a personal email address is used for commits. The CLA does indicate that to the best of the contributor's knowledge the contribution doesn't violate the rights of other persons or entities but this language could definitely be stronger. The "Remember" section of the agreement would probably not be binding on the contributor if the CLA superseded it.

(here's the remember section)

Remember,
Anything you check in must belong to you, or you must have full rights to publish and license it.
In particular, if you are contributing code using an account associated with your employer, you must have permission from your employer as discussed in the contributor form. Also, if you are checking in code written by someone else then you must have their permission to do so.
Your CVS account is for your own use only. Do not let others use it. If you find or suspect that someone else is using your account, notify us of the problem by filing a bug in the "mozilla.org" product, "CVS Account Request" component.
If you check in something for others, attribute them in the CVS log, including their name and email address.
(In reply to comment #9)
> Comment from one of our lawyers about the old agreement. Here for posterity:

Some quick points in response to these comments:

First, the comments in question are with respect to the mozilla.org CVS Contributors Form, which is a form signed by individuals who may be checking code on behalf of themselves or others (including their employers). Gerv is working to update that form; see bug 342029 for more information.

This bug is about a proposed Corporation Contributors Agreement, which is a form signed by organizations (more correctly, an authorized manager of an organization) who have employers or contractors who may be contributing code (regardless of whether or not they actually check the code in).

Second, the "Remember" section quoted is actually from the page describing the CVS Contributors Form, not from the agreement itself. So I do agree that its legal status is questionable.
I've posted a draft of the proposed corporate contributor agreement for public comment. My apologies for the delay in getting this drafted and reviewed internally. For more information about this draft please see

http://hecker.org/mozilla/corporate-cla-public-draft

Specific comments on the language of the draft can go here, general discussion should go to mozilla.legal.
I'd like to see a text/html version of this document.

I've extracted a text/plain version from the pdf, and would attach it if 
anyone wants it.
(In reply to comment #12)
> I'd like to see a text/html version of this document.

Are you asking for the text/html version as an "official" alternative to the PDF version? (In other words, either would be authoritative and a corporation could sign either one.) Or are you recommending we have the text/html version instead of the PDF version? Or are you just asking for a text/html version for convenience in reviewing the draft and tracking changes to it?
I have no problem with saying that people must use the PDF to sign and send
in, but before they get to that stage, people will want to read the document
and study it.  IMO, html is much easier to read, with text whose size is adjustable and rewraps to fit the window, and needn't have excessive whitespace.  
PDF gives the reader none of that flexibility.

I'd like people to be able to read pretty/friendly html while they're 
investigaing & considering.  The official page on the web site should be html
IMO, with a link to the PDF for signing.  People can print the pdf if and 
when they're ready to sign.  The two should contain identical text, so both 
should be equally authoritative.  
Frank: is this now done?

Gerv
The status here is that there's currently a private "Draft 2" of an agreement like this. It has at least one missing word (in the final sentence) so probably is not considered quite ready for prime time yet.

Gerv
(In reply to comment #15)
> Frank: is this now done?

No. What was previously posted was a draft. I was waiting for comments, particularly from the company that originally requested we create such an agreement. (I've now forgotten the name of the company.)

I suggest that you talk to Harvey Anderson and others about whether or not we wish to revive this effort and produce a final draft.
Harvey: is this still something that would be useful? Frank's comment suggests not really...

Gerv
Resolving WONTFIX. We can reopen this bug, or file another one, if this document ever comes back to life.

Gerv
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Gervase, Frank: Do you know if anything was ever done with this?  My company is also interested in becoming a contributor.
Nothing was done more than is documented here. Your company does not have to sign anything to be a contributor; we have many companies contributing to Mozilla already. You merely need to be willing to provide your contributions under the appropriate open source licence (which depends on what you are contributing to), with whatever associated grants and guarantees that involves.

Gerv
You need to log in before you can comment on or make changes to this bug.