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.
Please consider the environment before printing this email.
-----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
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