Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alterations to contributors license agreement #9

Open
ghost opened this issue Mar 10, 2011 · 2 comments
Open

Alterations to contributors license agreement #9

ghost opened this issue Mar 10, 2011 · 2 comments

Comments

@ghost
Copy link

ghost commented Mar 10, 2011

Following from this thread:

http://www.xcore.com/forum/viewtopic.php?f=32&t=1068

There is a suggestion to change the contributors agreement which seems sensible, particularly:

Section 2.1 states that the contribution is made under the project's open source license. This open source license already covers redistribution of the code. Given this it seems that most of Section 2.2 (b) is redundant is it describes rights already granted by agreeing to section 2.1.

Section 2.2 (b) seems to grant the permission to the "the Project" to relicence the contributed code under any licence. This seem unnecessary as the open source license is already extremely permissive. This appears to be the only additional permission granted by 2.2 (b) not covered by the open source license.

Because of this it seems like you easily could get rid of section 2.2 (b).

Section 2.2 (c) talks about patents. I assume the goal here is to keep each project unencumbered so the code can be used freely without paying royalties. However the text only grants a license to "the Project", it does not grant a license to users who download the code. "the Project" is given the ability to sublicense so I guess it is assumed that "the Project" would in turn sublicence to everyone downloading the code, but this isn't explictly stated anywhere.

Would it be possible to reword section 2.2 (c) so that it grants a patent license to anyone receiving the code. Together with the removal of section 2.2 (b) this would remove all references to "the Project" and so avoid the need to define what "the Project" means. The rights you grant by agreeing to the contributor agreement would apply equally to anyone receiving the code, and there would be no entity ("the Project") with special rights.

I think XMOS has agreed to get a lawyer to look at these changes to check they are OK should we wish to make them.

@joergbertholdt
Copy link

Here are the details from the legal feedback on the contributor agreement questions.

  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.

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?

Joerg

@joergbertholdt
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant