Mail (will not be published) (required)
October 28, 2013 at 11:06 pm
I agree. The ‘exclusive’ granting here isn’t right… No one in their right mind would do that for a free project and it really makes it more complicated for anyone to use their work again. I think you should make it non-exclusive and remove the license back to you in section 2.3
See in context
October 23, 2013 at 10:59 am
> You hereby grant to Us a worldwide, royalty-free, exclusive, perpetual and irrevocable license
Why would any developer grant an exclusive right to any entity if this entity isn’t paying a lot of money for his/her work? Any OSS organization should be happy about any contribution and it should not matter if the contributed code is exclusively licensed or not. Both Outercurve Foundation and Apache Foundation do not require any exclusive rights (see Outercurve Foundation Contribution Agreement and Apache ICLA).
October 23, 2013 at 8:57 am
I must strongly agree with Bradley. You could just change “exclusive” to “non-exclusive” and the whole section 2.3 would become obsolete. This is also the way it is done in the Oracle Contribution Agreement (OCA) which is used for example for the OpenJDK project:
It would also be nice to have a clause which obligates the contribution receiver (i.e. “Us”) to always make the contribution available under an OpenSource license as this is done in the OCA.
September 20, 2013 at 3:39 pm
What about other artifacts like pictures, sounds, etc. Like for documentation, a different set of licenses may be preferrable for those.
September 20, 2013 at 3:36 pm
Option Three should be split into tow option. One for OSI approved licenses (permissive and copyleft) and one for the FSF recommended copyleft licenses. Combining these prevents s.o. from permitting copyleft licenses only.
September 11, 2013 at 8:58 pm
As a policy matter, I disagree. Your proposal here seeks in most of its forms to give special rights to the controller of the contributor agreement, even while the primary goal of software freedom is to give equal rights in the software to all. It seems to me this project is therefore taking the position: “We don’t think contributors and users of Free Software should all be treated equally under the licenses and law”. That’s a rather Free-Software-unfriendly position to take.
September 11, 2013 at 8:56 pm
My point is that you haven’t made the case that contributor agreements solve a problem not already solved by FLOSS licenses themselves. Also, “adding more options” to me seems very similar to the issue of license proliferation. If the goal isn’t to replace existing CLA/CAAs, then Isn’t this project promulgating contributor agreement proliferation?
September 10, 2013 at 7:37 am
There is a wide range of contributor agreements in use in FLOSS projects. By offering a discussion about improvements to these already existing agreements, we don’t intend to make the case that light wight solutions such as DCO are inadequate and we don’t suggest to replace any of the existing options. The goal of standardized contributor agreements is to offer improved resources and to add more options to the ecosystem.
September 10, 2013 at 7:36 am
See statement on website and in articles - We realize that contributor agreements are one available tool out of many in an overall legal strategy for open collaborative projects, and we don’t intend to suggest that contributor agreements are necessary for all successful legal strategies.
First principle is that contributors to FLOSS projects and projects are free to decide the terms on which they will contribute and accept contributions. Adding more options to this principle doesn’t suggest any violation of governance structures but extends possibilities and offers resources and options when making the choice.
September 5, 2013 at 7:58 pm
This violates a key community governance rule of inbound=outbound. The default agreement in the overwhelming majority of FLOSS projects is simply this: each contributor agrees to license each contribution using the project’s specified copyright license (or a license compatible with the project’s license).
This clause creates an inequitable situation. The recipient of the CLA receives a broad copyright license while on the outbound side, everyone else is bound by the terms of the copyright license.
This section and the one that follows us should be rewritten to say:
“You hereby retain Your Copyright and grant Us permissions under the [INSERT PROJECT LICENSE]“
This site is built using WordPress (GNU GPL; sources) and CommentPress Core (GNU GPL v2; sources).