Open Stack

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_Apache_License

  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_OpenStack.27s_Image_Problem

>    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_OpenStack

  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-NUyy9vksHoOD0WW5o
  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.