Hi Alan, Thanks for the thoughtful response, and apologies for the slowness of my response. Just catching up now. On Wed, 2014-05-21 at 16:55 -0600, Alan Clark 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.
I'm happy to try and capture any relevant information in the wiki page. That was the intent all along - do our very best to capture as much as possible, then invite others to fill in any gaps. We've also tried to be even handed in our analysis, but it's pretty clear we've come to a pretty strong conclusion. I'd imagine it would be a pretty futile effort to capture other strong conclusions in the opposite direction and debate the nuances of every point within the same wiki page, so I'm totally happy for there to be separate writeups of any opposing viewpoints.
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.
Sounds good. I would like us to figure out some way for the input from the Legal Affairs Committee to be shared openly, though. There's now a lot of people interested in any nuanced discussion on this topic.
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.
Cool. Happy to do that, and it was obviously something we were going to have to dig into sooner or later. We didn't spend much time on it in advance, though, because the implementation details here are pretty straightforward.
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).
The full sentence is: https://wiki.openstack.org/wiki/OpenStackAndItsCLA#Relationship_to_the_Apach... The OpenStack CLAs are contracts that are structured to privilege one entity (the OpenStack Foundation itself), whereas the Apache License is a typical open source license in that it is granted to the general public. I really don't think we're painting the Foundation as evil, but the simple fact of this being an asymmetric arrangement is concerning to some. And it's important to recognize that way the Foundation's governance is dominated by paying sponsors means some assume the Foundation is (or will be in the future) evil. That's also covered by this section: https://wiki.openstack.org/wiki/OpenStackAndItsCLA#Developer_Recruitment_and...
There is a reason the CLA was setup that way and that reasoning needs to be spelled out. (Doesn't mean that it can't change, just makes for a better informed decision.)
The reason the CLA was setup this way is covered by: https://wiki.openstack.org/wiki/OpenStackAndItsCLA#History We're obviously interested to hear about angles which aren't already covered there.
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.
Hmm, we try hard to describe that impact: https://wiki.openstack.org/wiki/OpenStackAndItsCLA#Contributor_Friction There have been a number of concrete examples of the impact of the CLA requirement publically raised recently: There were some other anecdotes offered during the design summit session that I have yet to capture in this section.
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.
I think we cover cases of contributor friction describing friction caused by both the CCLA and ICLA, so I think this covers some of the impact you're talking about here - i.e. the CCLA can hinder some corporate members from contributing while they get legal clearance for the agreement. But I think you're looking for something more here - a description of the positive impact that the CLA has by creating the impression of "legal hygiene" - i.e. something similar to: http://www.eclipse.org/org/#IP%20Management The Eclipse Foundation also undertakes a number of steps to attempt to ensure the pedigree of the intellectual property contained within Eclipse projects. Sure we can add that, but bear in mind we're also saying that such arguments don't make sense given the context: https://wiki.openstack.org/wiki/OpenStackAndItsCLA#CLA_Use_Outside_of_OpenSt... The vast majority of the projects that provide the code used as library and system dependencies of all OpenStack projects do not use any sort of CLA. This is particularly important when you consider that only a tiny proportion of code in a typical OpenStack deployment is actually code that can be said to originate (as Apache License 2.0 code) from the OpenStack Foundation, or at least from the collective body of OpenStack developers.
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.
Absolutely. What you're talking about is building and maintaining trust between all parties involved in this process. IMHO that is best achieved by regular and open communication. I'm very keen to see all input captured in a way that is visible to everyone interested. The body of input on this is building. The wiki page, slides, etherpad from the design summit: https://wiki.openstack.org/wiki/OpenStackAndItsCLA https://docs.google.com/presentation/d/1_7rbUpz6NPWLnVMLXEr-msKsR-NUyy9vksHo... https://etherpad.openstack.org/p/openstack-and-its-cla and the archives of this mailing list. I'll make my usual effort to summarize any board discussions on the topic. Any TC discussions will be automatically archived and minuted. The main discussion forum where we're not capturing the discussions is the Legal Affairs Committee. I'd love to see one of the attendees of those meetings send a brief summary of the discussion to this list. Thanks, Mark.