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 On Wednesday, 28 October 2015 12:44:54 UTC+1, Tim Graham wrote: > > Avoiding unnecessary work appeals to me, so I think it would be great to > check with the lawyers before proceeding. > > On Tuesday, October 27, 2015 at 8:33:21 PM UTC-4, Russell Keith-Magee > wrote: >> >> Hi Tim, >> >> On Wed, Oct 28, 2015 at 12:50 AM, Tim Graham <[email protected]> wrote: >> >>> 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/ >>> >>> 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 %-) >> >> >> >> -- 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 [email protected]. To post to this group, send email to [email protected]. 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.
