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. On 11 January 2018 at 15:49, Carlton Gibson <carlton.gib...@gmail.com> wrote: > 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 > > > > > > > On Thursday, 11 January 2018 16:08:04 UTC+1, Tim Graham wrote: >> >> 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/a7665045-8212-479d-8da1- > 82e105b68bbc%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/a7665045-8212-479d-8da1-82e105b68bbc%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAMwjO1GUcQ%3DA%2B5ioSvV88_QOFteEeHvaEt5rZ8zze7pvGF5N2g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
