On Fri, May 23, 2014 at 12:12 AM, Radcliffe, Mark <Mark.Radcliffe@dlapiper.com> wrote:
I agree with Richard's summary and will provide some additional information. My understanding during the drafting of the bylaws was that the ICLA and CCLA (which are based on standard Apache documents) had been used from the beginning of the project and had become part of the project's culture. Moreover the form of ICLA and CCLA were sufficiently important to the community that the form of CLAs were "locked" into the bylaws by making them exhibits (with some flexibility granted to the Board) and were included among the limited number of sections whose amendment requires a vote of the Board, the Individual Members, the Gold Members and the Platinum Members.
We have discussed this issue twice at the Legal Affairs Committee, particularly in the context of so called "trivial contributions". Each time we considered the history of the project, the commitments of the existing participants under the CLAs, our perception of the modest "friction" caused by the requirement to click the CLA and the expectations of existing members about future participants providing rights under the CLA. Both times we concluded that change was not appropriate. The Legal Affairs Committee is ready to work with the community to assist the Board to understand the issues in adopting the DCO procedure for some or all contributions. The ultimate decision belongs to the Board.
It would be really useful for those of us interested in this discussion but without the benefit of being present for all of the history you refer to here to have some sort of write-up of the analysis the Legal Affairs Committee has done to help us understand the current position. Does something like that exist?
We should also ensure that we note that the issue of "friction" caused by CLAs may have been misplaced because of confusion about the link between contributors and Individual Members. Until recently the Technical Committee was requiring all individual contributors to become an Individual Members. As I noted in response to that question about a month ago, this condition was a misunderstanding of the bylaws. The bylaws only require that a contributor join if he wants to qualify to vote for the Technical Committee. Anyone can make a contribution if they have signed the CLA.
It was my impression from the summit session where we discussed this that we do want to look into separating foundation membership from the signup process to allow contributions, but that doing so isn't as simple as turning it off because of the way the TC and PTL voter roles are extracted from gerrit. That's not an insurmountable problem, just one that will require some thought and effort. That said, have we had any cases where people *could not* contribute because of the membership requirement? Perhaps some *would not* contribute under those terms? We've certainly had people say the requirement was annoying or surprising or both. Still, it doesn't seem like the sort of roadblock that a requirement to sign a binding legal agreement like the ICLA or CCLA presents to some of the potential contributors detailed in https://wiki.openstack.org/wiki/OpenStackAndItsCLA#Contributor_Friction. AFAICT, the two issues both cause friction for new contributors, but are otherwise unrelated. Doug
-----Original Message----- From: Alan Clark [mailto:aclark@suse.com] Sent: Thursday, May 22, 2014 1:26 PM To: Robert Esker; Richard Fontana Cc: legal-discuss@lists.openstack.org Subject: Re: [legal-discuss] OpenStack and its CLA [was Re: Copyright statements in source]
I also don't know the full background either, but think that it is worth asking the question. I remember discussions of modeling around Apache, Eclipse and similar organizations, it may also be 'historical'. But even if it was for historical reasons, as the paper points out there must have been some underlying basis such as risk mitigation.
So we have 3 1 - historical 2 - modeling from other open source projects 3 - risk Are there others?
Historical and modeling are less interesting. For risk, we can argue if risk mitigation is a valid argument, but by listing the reason we can ensure that with or without a CLA risk mitigation gets appropriate coverage.
-AlanClark
On 5/21/2014 at 09:16 PM, Richard Fontana <rfontana@redhat.com> wrote: The OpenStack Foundation ICLA and CCLA were not written from scratch. The real historical reason for them having the content and structure they have is simply that the Foundation adopted the CLAs that were used by Rackspace with some minor changes. Rackspace for its part had reused the texts of the ICLA and CCLA of the Apache Software Foundation with some minor changes.
- Richard
On Thu, May 22, 2014 at 01:25:52AM +0000, Esker, Robert wrote:
Alan,
You¹d indicated there was a reason the CLA was structured to privilege the Foundation and suggested that Mark elaborate* but I¹m not familiar w/ the background or reasoning - could you expand upon that in advance of Mark amending his treatise?
Thanks!
Rob Esker NetApp, Inc.
On 5/21/14, 5:55 PM, "Alan Clark" <aclark@suse.com> wrote:
Mark,
The "OpenStack and its Contributor License Agreement" paper that you authored shows a lot of thought, time and effort. I can appreciate the amount of effort you and others have put into investigating this issue.
I recognize the need for the paper to be written as a persuasive argument to propose change but there is more that needs to be written for completeness if this is intended as a proposal to the Board. I will leave it to you to determine if that material belongs in this paper or somewhere in addition. I simply know that If we don't write it up, the questions and issues will still come up at the meeting and we will simply chew more time and encounter decision delay. Also to give a little timeline, before putting this on a board meeting agenda I want all the info possible input into a Board packet to be distributed to the Directors 1 week prior to a meeting. I also think that it is important that the information be run through the Legal Affairs Committee for their consideration prior to a Board discussion.
Here's some of the info that may need to be added:
1. What is the real world feasibility / effort required to transition from the CLA to a DCO? I'm familiar with the Linux kernel model, the how, why and impetus for implementing the DCO. Any estimates on the size of effort this would entail? For example, does our current repositories have the data needed to give us a clear chain of trust? How would a transition be handled? What effort would be needed to setup the attestation? (include CI, documentation, education, adoption) My sense is that a DCO system is simpler to maintain (as you argue in the paper), but we do need to understand the effort that would be needed to get there with some confidence that OpenStack could actually do it and at what cost - people, time, impact to release, etc.
2. In the section, "Relationship to the Apache License" the paper makes the statement, "...structured to privilege one entity (the OpenStack Foundation itself)...". The paper makes it sound like the Foundation is an evil empire. (Teasing&Smiling). There is a reason the CLA was setup that way and that reasoning needs to be spelled out. (Does n't mean that it can't change, just makes for a better informed decision.)
3. In "The Need For Change" section, the paper describes the "Contributor Friction". I get the need to make the persuasive argument, but the impact also needs to be explained. There is also a need for a similar section to cover the 'Corporate member / Sponsor Friction'. We have multiple member classes. The proposal should cover all of them, making the persuasive argument as well as describing the impact. The Corporate member section should not only describe the impact to them as a corporate entity, but also the impact to the Foundation in terms of corporate members and sponsors.
Next I have an ask and I am not implying that it is happening. I just want you to be sensitive to it, so that it does not inadvertently happen. My ask is that you be the guard against any alienation between any of the governing bodies, advisory boards and members. It's important to understand that each will look at this issue from differing responsibilities and perspectives, sometimes those perspectives can get minimalized. If we keep the groups focused on providing insight in relation to their areas of responsibility and ensure they respect others responsibilities, we'll arrive to the correct conclusion together and the community will be stronger from it.
Thanks, AlanClark
> On 5/13/2014 at 03:28 PM, Mark McLoughlin <markmc@redhat.com> wrote: Hey
Along the lines of what I laid out in below email from January, Richard and I completed a first draft of such a document last Friday:
https://wiki.openstack.org/wiki/OpenStackAndItsCLA
It's a 5000 word document that attempts to capture as much of the nuances of this as we could.
No doubt there are many conflicting opinions about this and much discussion is needed ... just as we anticipated in the below email.
Please do feel free to react here to any of the points made in the wiki page. Any and all feedback is welcome.
We also had a design summit session today where we gathered some feedback from the technical community, particularly about where we're seeing the CLA cause contributor friction or an image problem for the project. See here:
https://etherpad.openstack.org/openstack-and-its-cla
My interpretation of the session is that there's a good level of consensus amongst the technical project leadership that there are issues and a change to the DCO should be seriously considered.
Thanks, Mark.
On Thu, 2014-01-23 at 10:55 +0000, Mark McLoughlin wrote:
I think it's worth having a properly informed discussion involving the Foundation Board and Legal Affairs Committee.
To do so, we'd need to pull together some points into a document:
- why the CLA process is causing friction
- a review of practices adopted by some other large, well known and comparable projects
- how OpenStack's process differs from other projects using CLAs, like the ASF
- enumerating the perceived benefits and explaining why they are a misconception, not a major benefit or that a similar effect can be achieved differently
- a concrete proposal for a change to DCO, including infra changes, education, bylaws amendment, etc.
- a FAQ section which anticipates additional concerns people may have
I'd take this to the TC first to double-check that there's consensus amongst the contributor community to make a move like this.
Unfortunately, there's no quick way to make this happen, but I think if we can get the process moving we should be able to make it happen.
Mark.
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss Please consider the environment before printing this email.
The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please reply to the sender and destroy all copies of the message. To contact us directly, send to postmaster@dlapiper.com. Thank you.
_______________________________________________ legal-discuss mailing list legal-discuss@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss