improving our Contributor License Agreement process

[Tim Graham]

In 2014 I started to research if we could offer a Google Summer of Code project aimed at improving Django's process for collecting and organizing CLAs. I didn't complete that proposal when I found some existing solutions, in particular https://cla.puppetlabs.com/ which Puppet labs said they were planning to open source. Following up on that now, I couldn't find if they ever did open source it and the contacts I found for the project (Dawn and Jeff) no longer seem to work at the company.

I wonder if anyone has a recommendation for a third-party solution to solve this? Our requirements are roughly outlined below.

Overview
--------

The Django software foundation asks all past and future contributors to sign a contributor license agreement [1]. Every contributor of non-trivial amounts of code (more than just a line or two) to Django is required to sign such a document. If somebody is unable to sign the document, their contribution (whether it be code, or documentation, or string translations) will be removed from Django.

The CLA ensures that the Django Software Foundation (DSF) has clear license to all its contributions, which in turns lets us guarantee to users that we have no "stray" intellectual property or differently-licensed material.

The DSF current process for collecting CLAs involves downloading a PDF and submitting it by mail, fax, or email. This process makes it difficult to audit our commit history by mapping commits to CLAs.

Requirements
------------

Contributors must be able to do an online acceptance of terms and conditions. We present our license terms, and the user puts in name, email address, contact details etc. We validate that the email is valid (by having them verify the email address), and we tie it to their Trac and/or GitHub handle. This allows us to have tracing for every commit. We also have a historical archive of physical documents, which we can use to populate the database (obviously not with verified email addresses, but it works for legal purposes).

We've also got corporate CLAs which need to be signed by a corporate representative, and can cover a bunch of employees (each employee's contributions covered from a specific date).

We should add a pull request check that indicates whether or not a contributor has signed the CLA.

[1] https://www.djangoproject.com/foundation/cla/

[Riccardo Magliocchetti]

Il 27/10/2015 17:50, Tim Graham ha scritto:
> I wonder if anyone has a recommendation for a third-party solution to solve
> this? Our requirements are roughly outlined below.

Not a solution but for comparison Libreoffice requests a blanket statement sent
on a public list then referenced on a wiki page:
https://wiki.documentfoundation.org/Development/Developers


--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

[Russell Keith-Magee]

Hi Tim,

Thanks for driving this.

One option would be to do the same thing the PSF does - an Adobe eSign form:

https://www.python.org/psf/contrib/contrib-form/

(Or, any other analogous service).

I’m also are of CLAHub:

https://github.com/clahub/clahub

It’s “CLA with github integration as a service” - but the owner has flagged that they’re in need of assistance. It’s also a Rails codebase (that’s not a reason to *not* use it -but it’s a reason that we might not be in a position to offer to take over maintenance).

A final option - but this is one the DSF would need to pursue in conjunction with legal advice - would be to abandon the idea of CLAs altogether. There’s a growing body of opinion that they’re not necessary: 

http://www.ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html

Russ %-)

[Tim Graham]

Avoiding unnecessary work appeals to me, so I think it would be great to check with the lawyers before proceeding.

[Carlton Gibson]

I started reviewing patches according to the check-list this morning and, for first-time contributors, I was wondering how to validate the CLA status. Tim pointed me here. 

There is now (what looks like) a viable third-party provider: 

https://cla-assistant.io

Amongst others, Microsoft use this for the VSCode project

https://github.com/Microsoft/vscode/issues/34239

(This looks better than rolling our own. Adding a CI check isn't that hard. There are services which do the document signing. etc. But then I take of the Programmer's Rosy Glasses and wince.)

Can we assess CLA assistant to see if it would fit our needs? 

If we're not going to do something like this then would it be worth making the assessment of dropping the CLA? (If so, how could that be made to happen?) 

Regards,

Carlton

[Tim Graham]

Hi Carlton,

It sounds like you have the enthusiasm for this that I had in 2014. ;-)

You could contact the DSF board if you want to try to get them to consult a lawyer about the necessity of CLAs. I guess opinions might vary from lawyer to lawyer.

Given that Django has been operating for about 13 years without rigorous enforcement of the CLAs, I guess I fail to see why we would need to start rigorous enforcement now. Having CLAs available seems to be a good thing, even if the comfort is mostly cognitive. I'm not sure what sort of legal challenge Django would face where we would need CLAs. Collecting them seems more an issue of purity than of practicality. I'm not a lawyer.

[Tobias McNulty]

FWIW I was immediately discouraged from signing up by the slew of permissions they ask for:

In addition to the permissions shown in this screenshot, it asked for access to my commit statuses, read access to all my organization and team memberships, read and write access to public and secret gists, and access to all my organizations (only if permitted by the organization, of course).

Maybe some folks are okay with that. But it seems like a significant burden to place on contributors (esp. if we were to make its usage mandatory, for example). Personally I'd prefer a lighter-weight solution if we do end up implementing something to assist with the process.

Tobias McNulty
Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8fc47934-f2cb-4b95-9889-a83c9c045b11%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Carlton Gibson]

Hey Tim. 

> It sounds like you have the enthusiasm for this that I had in 2014. ;-)

Yeah. What I liked was that your proposal was like a "I've actually thought about this" version of what I was beginning to ponder myself. :-)

I don't really think we should drop the CLAs. It's just that if they're not enforced then we don't address the issue they're meant to solve (which, if I understand it, is ultimately making sure companies can safely use Django without worrying about a withholding of rights at some key juncture.) 

So better... I thought... was if we can implement a decent, and easy, check. 

If the CLAs aren't really important then, well, I guess I would drop them (but I'm not hooked up on that — it's more a cognitive huh?)

@Tobias, I see your post come in whilst writing this: 

I think the permissions there is for the backend CLA-provider, rather than the end user. i.e. it needs those permissions for the CLA (which you host in a Gist) and the build status for the CI check and so on. 

This is the hosted version you're looking there. I'd imagine we'd host our own, so those permissions would be internal. 

I imagine looking at that to be part of any assessment. 

The individual contributor would need to grant only the Personal Data bit. (I need to look into exactly the levels.) The flow—reading from the VSCode docs—is to fork and then make a PR, as normal, if you've not submitted the CLA you're then prompted to do so.  

https://github.com/Microsoft/vscode/wiki/Contributor-License-Agreement

What I liked about it, is that it seemed to tick all the boxes. 

When Tim first proposed this in 2014 the summary seemed to be "Yes, we should do this, but it might be hard — oh, and we might not need to". 

Given that we still have the CLA, is it not still something that we should do? 

If not no worries. 

Regards,

Carlton

[Marc Tamlyn]

Accessibility of contributing > Leal protection

We shouldn't drop the idea of CLAs, they're there so that an organisation or individual who wants to do things "properly" can still do so. But I don't think we need to enforce it for any contribution.

The CLA story for Django is already hazy, as we don't require it for "trivial" changes - https://www.djangoproject.com/foundation/cla/

I guess I'm with the "13 years with no problems". My understanding is they protect Django (and its users) from someone claiming that a contribution was made without license, and asking for it to be removed. This seems pretty unlikely.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a7665045-8212-479d-8da1-82e105b68bbc%40googlegroups.com.

[Carlton Gibson]

On Thursday, 11 January 2018 18:01:23 UTC+1, Marc Tamlyn wrote:

 But I don't think we need to enforce it for any contribution.

OK. I think that's the key. If that's the view then we can go on as is. 

Thanks all.  👍

C.