[legal-discuss] What are the minimum set of things we believe need the CLA?

Richard Fontana rfontana at redhat.com
Sat May 31 16:21:23 UTC 2014


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)

* 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

* 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

* 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

* 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).

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

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

* 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?)

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

Thanks,
Richard




More information about the legal-discuss mailing list