On 05/31/2014 12:21 PM, Richard Fontana wrote:

On Sat, May 31, 2014 at 07:00:06AM -0400, Sean Dague wrote:

...

An interesting conversation happened when I put up a review to pull in devstack-vagrant to gerrit from github - https://review.openstack.org/#/c/96835/ about what in gerrit requires the CLA. I specifically don't want the CLA required on this, as I've actually gotten organic contributors on github because people found it useful to show up and throw a patch my way (then came back because the round trip from patch submission to merge was very short). [...] About 1/2 our dev tools in openstack-dev are not currently CLA required. It actually makes me wonder if any of them need to be. As these tools typically won't be part of an OpenStack release, it makes me wonder if we can drop the CLA on them entirely as a technical matter. For instance, why is there a CLA on devstack?

Given that the board still seems stalled on approving a transition to the contribution framework the development community wants, I wonder if we can at least reduce the number of projects that are creating new developer friction by having a clearer view on what in gerrit we believe has to have the CLA, and ask all the other projects if they want to remove CLA enforcement.

This is a good example of why I think this issue can't be resolved in an informed way without active consultation from the technical community.

Bearing in mind I still don't currently have much understanding of gerrit or really any of the details of OpenStack development, I get the sense from this discussion as well as some other conversations that the situation today is something like this:

* A project in the openstack repository namespace is seen as unquestionally covered by the (external to gerrit) CLA requirement (or maybe I have that backwards)

Currently, yes, openstack/* projects are all CLA enforced as far as I know.

* For projects under stackforge, it is seen as unquestionably correct that the CLA requirement is discretionary (for whoever has the discretion); the decision is influenced by the nature of the project

Correct.

* Any project under 'openstack-{something}' is seen as probably subject to the CLA requirement, except this is not completely adhered to via gerrit and there is some feeling it may not be correct in all cases

Actually, most of openstack-infra is not under the CLA, and openstack-dev (which is sort of vestigial) is mixed.

* Projects that would otherwise naturally be under openstack-dev, at least, can avoid the uncertainty of the previous point by moving the project to stackforge

Yes, definitely.

* If a project is assumed to be covered by the external-to-gerrit CLA requirement (or someone with discretion decides to assume this) this is then always implemented by setting the gerrit property that says a contributor agreement is required. This then, I assume, is enforced through gerrit, except it can't currently be enforced for the CCLA, just for the ICLA (see Stefano's recent posting).

Correct. It will actually prevent code upload to those projects if there is not an active ICLA, which is one of the cryptic errors that new users often hit and are confused about.

* Gerrit (as a general observation) is designed to facilitate use by projects that require "contributor agreements" as well as the DCO, in the sense that you have those flags for requireContributorAgreement and requireSignedOffBy. I assume that implies that at least some administrative aspects of switching to a DCO system would be low cost, and also (see previous point) might (arguably) have some advantages over the current way the CLA system is administered through gerrit.

Yes. It's just another flag.

* Projects in gerrit that *do* have the CLA requirement (in the gerrit sense) may have in an earlier stage of their existence not operated with any comparable CLA requirement - I suppose that is something that was obvious, but it's probably worth noting, somewhat akin to the useful point you make about risk at http://lists.openstack.org/pipermail/legal-discuss/2014-April/000243.html What I mean by that is, for example, if devstack-vagrant were judged to be covered by the CLA requirement, no one seriously thinks you're going to go back to the github contributors to devstack-vagrant and demand that they and their possible employers sign OpenStack CLAs.

Correct.

* I assume that the namespaces are for more than mere organizational convenience (what's the practical significance if devstack-vagrant goes from openstack-dev to stackforge?)

Yep, mostly just logically grouping. It makes sense to have the core team for devstack-vagrant be the existing devstack team, so putting it in the same place in the tree makes sense.

How much if any of the assumptions above did I get right?

I think that's a pretty fair assessment. I also think that it's worth noting that often times CLA enforcement on projects even in stackforge wasn't something people actually directly wanted, but was a thing that they copy / pasted from a template not realizing it was a decision in the first place. -Sean -- Sean Dague http://dague.net

I will supplement Alan's comments by noting that I am working with the Foundation to review the current procedures to see if we can streamline them and the Legal Affairs Committee will be discussing these issues in the near term so we can present the issues to the Board. As Alan noted, the bylaws which were adopted by the Foundation imposes certain requirements on use of the CLA (see Article VII of the bylaws) and changes to this Article require a vote by the Board, Platinum Members, Gold Members and Individual Members. -----Original Message----- From: Alan Clark [mailto:aclark@suse.com] Sent: Saturday, May 31, 2014 9:34 AM To: Sean Dague; legal-discuss@lists.openstack.org Subject: Re: [legal-discuss] What are the minimum set of things we believe need the CLA?

...

...

On 5/31/2014 at 05:00 AM, Sean Dague <sean@dague.net> wrote: An interesting conversation happened when I put up a review to pull in devstack-vagrant to gerrit from github - https://review.openstack.org/#/c/96835/ about what in gerrit requires the CLA. I specifically don't want the CLA required on this, as I've actually gotten organic contributors on github because people found it useful to show up and throw a patch my way (then came back because the round trip from patch submission to merge was very short).

This in stark contrast to a conversation I had to have with a new contributor that wanted to patch the README on one of our projects, which I had to sheepishly point to our how to contribute page. Every single time I have one of these conversations I feel terrible, and that I should apologize profusely, because what we ask new contribs to go through is insane. As someone who's contributed to lots of Open Source on my spare time, a CLA is basically something that I'd never bother to touch.

About 1/2 our dev tools in openstack-dev are not currently CLA required. It actually makes me wonder if any of them need to be. As these tools typically won't be part of an OpenStack release, it makes me wonder if we can drop the CLA on them entirely as a technical matter. For instance, why is there a CLA on devstack?

Given that the board still seems stalled on approving a transition to Sean - I am going to differ with your opinion here. I realize you are trying to push action but please be more accurate as to not lead people feel the board is somehow the bad guy. The board is not stalled. When this topic started a couple months back a response was given and posted. I get it that some don't like the answer given and are pushing for change. Much of that discussion started at the Summit after the Summit board meeting. Please recognize that the Board has not met since that date, nor was it on the agenda at the Summit board meeting. You may also have seen my recommendations to Mark for information and actions needed before placing it on the agenda at the July board meeting.

Please also recognize that the changes being asked for are not quick changes if they entail bylaw changes, changes to member agreements, etc. Sean - Please note that I am not trying to fight the change, I simply have to ensure that it is the right change for the interest of the full community of individual and corporate members and sponsors.

the contribution framework the development community wants, I wonder if

I don't necessarily dispute your statement of "the development community wants..." but with over 2000 code contributors and 16,000 members I'd be curious if you have any supporting data? I'm not asking for you to do a poll, am just curious if you have data that I haven't seen. We have a sample number on this mailing list, some ideas of the interest from the BoF at the Summit and comments made on other lists, etc. I guess the ultimate answer on that question will be through polling the membership on a bylaws change. -AlanClark

we can at least reduce the number of projects that are creating new developer friction by having a clearer view on what in gerrit we believe has to have the CLA, and ask all the other projects if they want to remove CLA enforcement.

-Sean

-- Sean Dague http://dague.net

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

On Mon, Jun 02, 2014 at 09:46:57AM -0400, Sean Dague wrote:

And realistically, at this point, I'd like to find various ways that we can lesson it's impact within our existing framework. Which was really where this email started. Because if we can at least agree the chunk of code that parties believe has to be under the CLA we might provide some great places for people to collaborate, become involved in our community, and onboard more quickly outside of that.

Sean is suggesting that (possibly but for the bylaws) some categories of software could be usefully identified as clearly excludable from the CLA requirement. This is already happening today in a kind of de facto unofficial way, arguably, depending on how draconian the CLA requirement is assumed to be, and there's probably some concern over the propriety of this degree of flexibility introduced into the CLA system. There is to my knowledge no official or explicit subject-matter carveout for projects that don't have to opt in to the CLA system. What the bylaws say is that "The Foundation shall generally accept contributions of software made pursuant to" the CLAs. I don't recall the history of that word 'generally' but to me it can be read in two opposing ways ('as a general requirement, without exception' or 'in the general case, with some exceptions'). If it means 'without exception', and if 'the Foundation [accepting] contributions of software' is supposed to encompass all software development activities involving official OpenStack infrastructure, then I'm guessing the bylaws have never matched reality. I also think what Sean is suggesting is that one sensible line would be (or would have been) whether a project is, or is reasonably likely to become, part of an OpenStack release. - RF