Hi Tim, On Wed, Oct 28, 2015 at 12:50 AM, Tim Graham <timogra...@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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84-gY4s6nFt6Vr6faB_hYLZmrpopQ1xUfFafjztp0_LMaw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
