Open Source Contributors Agreement

[jonathan]

What would be really cool would be if the lawyer were willing to post their comments here. Can that be achieved? ;-)

[Joerg]

I asked our open source lawyer to provide feedback on the contributor agreement related questions in this thread. Summary of the feedback below, please see github for detailed comments:

1) Do you need contributors to warrant that they have the right to contribute the code?
Yes.

2) Do you want a contributor agreement at all?
Absolutely.

3) Is Section 2.2(b) redundant?
Sort of.

4) Is Section 2.2(d) needed?
Not necessarily.

5) Do you want to broaden the patent license grant in Section 2.2(c)?
Maybe.

Now moving to github for the details https://github.com/xcore/Community/issues/9.

Joerg

[jonathan]

I'm not into splitting discussions across multiple places. Joerg, can you paste the full text here, since more people read this and this is where the discussion was raised?

[Folknology]

I don't see anything like 3.a in the Apache contributor license

Section 3: AGREEMENT
You agree and warrant that:
a. You have the legal authority to enter into this Agreement.

If you don't have the authority to enter into this agreement then clearly you can't enter into this agreement!

regards
Al

[jonathan]

I don't see anything like 3.a in the Apache contributor license

Section 3: AGREEMENT
You agree and warrant that:
a. You have the legal authority to enter into this Agreement.

If you don't have the authority to enter into this agreement then clearly you can't enter into this agreement!

regards
Al

I could be wrong but it looks like this clause is an hangover from similar agreements relating to individuals representing companies or portfolios of IP that they do not own. In particular, when the individual works for a company which has patents and copyright over various bits of code, and the individual certifies that they have the legal authority to enter into the agreement with respect to anything they submit.

I guess theoretically this means that if company X says employee Y was not entitled to enter into the agreement, and sues "the project" over the code release, this clause technically might make "the project" less responsible, and would certainly give "the project" the right to take action against (presumably, ex-)employee Y.

Bit far-fetched for what we're talking about, and these things should always be utterly minimal if possible.

[Joerg]

Right - its never a good idea to have the same information in two different places.

Dave L. opened a repository on github for the refinement of the contributor license, I posted the detailed legal feedback on the repo https://github.com/xcore/Community/issues/9 - its only one click away :) and the summary is available in the forum here.

Looking forward to an updated version of the contributor agreement.

Joerg

[jonathan]

The only thing worse than having information in two different places is dividing a conversation across two different rooms.

Hopefully this will now make it easier for people to discuss and contribute to this thread if they have a view.

1) Do you need contributors to warrant that they have the right to contribute the code?

Yes.
The question asked on the XCore forum seem to be "whether this is more than is required by law” or “is this unnecessary because it’s covered by law.”
In a public forum like the XCore project, you are open to two real possibilities:
(1) a minor contributes code (and minors do not have the right to enter into contracts), and (2) (even worse) someone contributes code which is actually owned by someone else (including, e.g., their employer) and they don’t actually have the right to enter into the agreement with respect to that code. So making someone sign up to “I have the right to be doing this” is an important point (and in agreements like these, generally a very important point).

2) Do you want a contributor agreement at all?

Absolutely. One of the reasons is noted above (does the contributor even have the right to make the contribution?). It’s also important to make sure that it’s clear what can be done with the contribution. If it’s not set forth in a license agreement/contributor agreement, then you will have pretty limited (“common law”) rights in the code, at best. You also want to ensure that the code is covered by a consistent license (as opposed to a hodgepodge of various and possibly conflicting license terms).

3) Is Section 2.2(b) redundant?

Sort of. But you’re trying to deal with two different licenses (hardware and software). And in addition, you’re referencing a link (which could end up not working or be out of date, or just be eventually linked to a different license). So normally, you at a minimum want to have the contributor agreement actually embody grants of certain rights to you. Plus, specifically adding provisions granting the right to relicense code is an important clarification

4) Is Section 2.2(d) needed?

Totally up to you to decide. By contributing to the repository, your name appears in public by default.

5) Do you want to broaden the patent license grant in Section 2.2(c)?

Maybe. As Richard rightly pointed out, the Project has the right to sublicense the patent grant. The questions is what we think our contributors and users want? It’s fine to have the patent grant run to everyone who gets the code. This (broadening the scope) is less of a legal question and more of a community question.

Here is the text, above.

Joerg's view:

Based on this feedback:

- Section 2.2(b): should stay for the legal reasons noted above
- Section 2.2(c): makes sense to broaden - we'll get legal language drafted
- Section 2.2(d): Since contributing to the repositories makes a contributors name public anyway, IMO, this clause just sets expectations and avoids unwelcome surprises at a later point. I recommend it stays. Does anyone have an issue in stating this explicitly?

Here is the legal reviewed, broadened section 2.2(c).

You grant to the Project, and to all recipients of Code distributed by the Project, a perpetual, worldwide, non-exclusive, transferable, royalty-free, irrevocable license under the Patent Claims owned by You or controlled, directly or indirectly, by You, with the right to sublicense these rights to multiple tiers of sublicensees, to make, have made, use, offer for sale, sell, import and otherwise transfer the Code and the Code in combination with other works, in each of the foregoing cases under any license, including commercial or proprietary licenses, as determined appropriate by the Project.

My view is that the purpose of reviewing this document was, if anything, to simplify and reduce it if possible. The result appears to have been to actually slightly lengthen and complicate it.

In more detail:

1) I don't actually agree with the explanation of point (1) - it seems vague. Surely if someone does not have the right to enter into an agreement then the agreement is not binding? And if someone does not have the right to enter into the agreement (e.g. they are a minor, or do not own their code) there is nothing stopping them from agreeing anyway. It strikes me that the only reason to include this statement is to have an explicit term (rather than an implicit one) in the agreement that they would be in breach of - and therefore enable you to go after them if there were ever a problem... That said this is such a triviality, forget it. If someone is particularly attached to it for some reason, then keep it.

2) Fine

3) Strikes me that if the main reason to include this is "just in case a link breaks" then it is redundant. But again, if there is massive attachment to this for some reason, just keep it. All I would say is that the WORDING of said section should match exactly the wording of the licenses if the purpose of it is to ensure that if the licenses change/link breaks/etcetc you have the same agreement in place. Remember Richard was offering suggestions that enabled you to do away with the wording that mentioned "The Project" - can you ask the lawyer what happens if these words remain (under different jurisdictions) bu "The Project" has no formal status?

4) Since it's totally up to us, I think you should just remove it. Simplify + lower potential barriers to entry: even if you don't see them as barriers, someone else might.

5) Do we really want all this stuff covering patent claims? Given that the licenses used don't mention patent claims at all, how can the project relicense patent claims anyway - under what exact terms (it seems they would be bound entirely by this contributor agreement)? Do we actually need to write something explicit about patents? Moreover, the text on patents suggested above looks like a copy-paste job from the bit about code, so switches back to talking about "Code" after a few lines rather than "Patent Claims".

And a final question, under what law does this agreement apply? UK/US/etc. This is presumably important for the definition of what "The Project" actually is amongst other things.