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. On Thursday, January 11, 2018 at 9:27:17 AM UTC-5, Carlton Gibson wrote: > > 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 <timog...@gmail.com> 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 django-developers+unsubscr...@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/779bc19e-f88b-450c-9504-0c462b44b78d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
