Open Stack

On Thu, May 22, 2014 at 11:12 PM, Radcliffe, Mark <
Mark.Radcliffe at 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.
>
> 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.
>

Ah, this aspect is good to uncover, especially for documentation. Does the
infra team have a task to decouple the "join the Foundation" steps and
identity from the git review required setup steps?

Anne



>
> -----Original Message-----
> From: Alan Clark [mailto:aclark at suse.com]
> Sent: Thursday, May 22, 2014 1:26 PM
> To: Robert Esker; Richard Fontana
> Cc: legal-discuss at 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 at 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 at 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 at 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 at lists.openstack.org
> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
> >> >
> >> >
> >> >_______________________________________________
> >> >legal-discuss mailing list
> >> >legal-discuss at lists.openstack.org
> >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
> >>
> >>
> >> _______________________________________________
> >> legal-discuss mailing list
> >> legal-discuss at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
>
>
> _______________________________________________
> legal-discuss mailing list
> legal-discuss at 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 at dlapiper.com. Thank you.
>
>
> _______________________________________________
> legal-discuss mailing list
> legal-discuss at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/legal-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/legal-discuss/attachments/20140523/a4e16aed/attachment-0001.html>