Comments by Commenter
Instead of assignments, we suggest to offer exclusive and nonexclusives licenses. For details, please see the legal opinion on drafting options, available at http://script-ed.org/wp-content/uploads/2013/08/engelhardt.pdf
Enable a click-through process that collects contacts details of each contributor and asks whether the name should be mentioned and whether personal information can be distributed. For details on signature formalities, see the Comparative Analysis on Copyright Assignment and License Formalities by Andres Guadamuz and Andrew Rens.
Implement a choice-of-law-clause as suggested by Axel Metzger in his paper on aspects of internationalization available at http://script-ed.org/wp-content/uploads/2013/08/metzger.pdf
Offer different “Outbound” License Options for the project to choose.
How can we define “defensive purpose” more precisely? Seems that a “thread” is not sufficient but a patent infringement lawsuit should be required.
How can we create an optional scheme for patent provisions in contributor agreements where a contributor is given the choice o 1) identifying specific patents and receiving a broader defensive termination right in exchange for that transparency or 2) licensing without any identification of patents that relate to the contributors contribution?
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.
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.
This project generally does not seem necessary. The case has not been made for why existing light-weight solutions such at the DCO and using the Free Software licenses themselves is not adequate.
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]“
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?
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.
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.
What about other artifacts like pictures, sounds, etc. Like for documentation, a different set of licenses may be preferrable for those.
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
> 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).
Hi, this is a comment.
To delete a comment, just log in and view the post's comments. There you will have the option to edit or delete them.
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.
October 28, 2013 at 11:06 pm
See in context
October 23, 2013 at 10:59 am
October 23, 2013 at 8:57 am
September 20, 2013 at 3:39 pm
September 20, 2013 at 3:36 pm
September 11, 2013 at 8:58 pm
September 11, 2013 at 8:56 pm
September 10, 2013 at 7:37 am
September 10, 2013 at 7:36 am
September 5, 2013 at 7:58 pm
This site is built using WordPress (GNU GPL; sources) and CommentPress Core (GNU GPL v2; sources).