Open Source Contributors Agreement

XCore Project reviews, ideas, videos and proposals.
User avatar
davelacey
Experienced Member
Posts: 104
Joined: Fri Dec 11, 2009 8:29 pm

Open Source Contributors Agreement

Post by davelacey »

Hi,
Jonathan made some points in another thread which I thought were best separated out for discussion.
For those who are still looking around, here is a quick summary:

1. Code written for repositories in the github xcore organization is to be covered by the derivatives of the he University of Illinois/NCSA Open Source License found here: https://github.com/xcore/Community. This license governs use and redistribution of the code.

2. If you want to contribute to the code (i.e. commit to a repo, maintain a repo, create a new repo etc.), then you need to sign a contributor license to do so. This license is there to ensure fair usage in the sense that everyone who contributes and wants their code in these repositories does so under the open source license mentioned above. Note that you don't need to agree to this license if you are just using the repos (or modifying them outside of the XCore open source project).

To paraphrase Jonathan (who can correct me if I am wrong), there are several points which may merit discussion here:

1. Do we want a contributor license at all?
2. Is clause 2.2 (d) needed? Currently if you sign the license you agree to have you name added to the list
here: https://github.com/xcore/Community/wiki/Who's-who (note that your name will be public due to
the commit logs anyway)
3. The license grants rights to "The Project" but it is perhaps unclear what the project is.

Comments welcome here (not just on the above but on anything related to the contributor license). I will get some feedback on legals by the people who drafted the license (I have no knowledge here I'm afraid, but it was checked by an open source specialist lawyer) but the general idea of the contributor agreement is to get people who put things into the project to do so in an open way.

Dave


User avatar
Joerg
Member++
Posts: 27
Joined: Wed Jan 27, 2010 7:07 am

Post by Joerg »

Great summary Dave and good questions.
To provide some background how we got here:
1. Do we want a contributor license at all?
The goal of the contributor license to provide clarity for contributions. Dave stated it perfectly well:
quote]This license is there to ensure fair usage in the sense that everyone who contributes and wants their code in these repositories does so under the open source license mentioned above[/quote].
Using a contributor agreement is quite common, e.g. the contributor agreement for Apache is here.

2. Is clause 2.2 (d) needed?
Dave again covered this one well.
(note that your name will be public due to
the commit logs anyway)
.
To avoid any surprises, its probably best to be upfront about it in the contributor agreement.

3. The license grants rights to "The Project" but it is perhaps unclear what the project is.
Agreed. "The Project" currently is relatively loosely defined. As outlined in the manifesto, XMOS is "sponsoring the XCore Open Source Project...by offering stewardship...".
That's what we believe is necessary to get "The Project" off the ground. As mentioned earlier today "A lot of work remains...We look forward to working together in enabling the XCore community to take the next step".
That's it - we need to discuss together where we want to take "The Project".

Joerg
User avatar
jonathan
Respected Member
Posts: 377
Joined: Thu Dec 10, 2009 6:07 pm

Post by jonathan »

OK.

If others are happy to sign up to and agree with the terms of the contributor license, which I find a little OTT, then that's fine! I guess time will tell if it works.

The element that I think *is* important is the status of "the project" - to which rights are assigned. I think it's important to both recognise and empower this entity and ensure it's as democratic and independent as possible. I have some suggestions for how this might be achieved. The more democratic, independent and empowered, the more appealing it becomes to overcome issues that might prevent people or companies from contributing to its success.

I'll post some more details/suggestions up later on today.
Image
User avatar
jonathan
Respected Member
Posts: 377
Joined: Thu Dec 10, 2009 6:07 pm

Post by jonathan »

Posted some ideas and suggestions on http://blog.xfund.com/2011/03/08/your-c ... help-them/

Can reply on the blog, here, or via Twitter @jonathan_may
Image
richard
Respected Member
Posts: 318
Joined: Tue Dec 15, 2009 12:46 am

Post by richard »

My thoughts on the agreement are as follows:

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.
User avatar
jonathan
Respected Member
Posts: 377
Joined: Thu Dec 10, 2009 6:07 pm

Post by jonathan »

I actually think it's a good idea to have a formal third-party - there are good reasons why these third parties exist. However, I do agree that the license could be simplified. The only kind of third-party that is a bad idea is a loosely-defined one with no formalised role - this kind of thing is often open to abuse. Better off with either nothing, or something more established.
Image
richard
Respected Member
Posts: 318
Joined: Tue Dec 15, 2009 12:46 am

Post by richard »

jonathan wrote:I actually think it's a good idea to have a formal third-party - there are good reasons why these third parties exist. However, I do agree that the license could be simplified. The only kind of third-party that is a bad idea is a loosely-defined one with no formalised role - this kind of thing is often open to abuse. Better off with either nothing, or something more established.
You could still have a formal entity plays a role in the direction / management of the project without it being mentioned in the contributor's agreement. As far as I can see you only reason to mention the third party in the contributors agreement would be if special permissions are granted to that third party.
User avatar
jonathan
Respected Member
Posts: 377
Joined: Thu Dec 10, 2009 6:07 pm

Post by jonathan »

richard wrote:
jonathan wrote:I actually think it's a good idea to have a formal third-party - there are good reasons why these third parties exist. However, I do agree that the license could be simplified. The only kind of third-party that is a bad idea is a loosely-defined one with no formalised role - this kind of thing is often open to abuse. Better off with either nothing, or something more established.
You could still have a formal entity plays a role in the direction / management of the project without it being mentioned in the contributor's agreement. As far as I can see you only reason to mention the third party in the contributors agreement would be if special permissions are granted to that third party.
Excellent, that clears that up. Sorry, got the wrong end of the stick.

I completely support Richard's proposals. Now... to whom should they be put for a vote? "The Project?" ;-)
Image
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Post by Folknology »

Can someone justify :
Section 3: AGREEMENT
You agree and warrant that:
a. You have the legal authority to enter into this Agreement.
Surely this is surplus to requirement.

regards
Al
User avatar
davelacey
Experienced Member
Posts: 104
Joined: Fri Dec 11, 2009 8:29 pm

Post by davelacey »

The action to alter the agreement has been recorded as an issue against the Community repo (this seems a good way to record possible actions like this):

https://github.com/xcore/Community/issues/9

Basically, there seems to be consensus on this so unless someone objects massively here or on the github issue. I can get it changed pending the lawyers comments.

Dave