[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