gwt-gradle-plugin icon indicating copy to clipboard operation
gwt-gradle-plugin copied to clipboard

Get automatic CLA agreement using whatever gwtproject site uses

Open JamesXNelson opened this issue 10 years ago • 4 comments

Reading your README, it seems you are concerned about potential CLA issues. Although I don't think you would have any problems, I do know it is possible to use github to check CLA using webhooks like how https://github.com/gwtproject/gwt-site/ does. Perhaps @jdramaix or @tbroyer might know more.

Also, Thomas has the experience of maintaining the maven plugin for a while now, so he might be able to shed light on when, if ever, you might need to be concerned about the CLA.

JamesXNelson avatar Feb 07 '15 00:02 JamesXNelson

If you want/need a bot, have a look at https://www.clahub.com/ gwt-site uses Google's bot which works a bit differently, but is equivalent in the end, except it has to be setup by Google and uses Google's CLA database.

For the Codehaus gwt-maven-plugin, I honestly don't care; it was there long before I started contributing. No CLA required (the code says it's "licensed to the ASF" and talks about CLAs and a NOTICE file but I was never asked to sign a CLA before contributing and as a result I don't ask anyone to sign one –and if it were Apache CLAs, I haven't found public records of who signed them so I couldn't check anyway–, the code is quite obviously not licensed "to the ASF" –I suspect a bad copy-paste when trying to apply the ASL–, there's no NOTICE file in the project). But I don't care because I'm not the "project owner" and would happily sign a CLA if there was one, and I'd rather see this project die. That said, I should probably care more, but I'm a bit lazy. FWIW, Jenkins doesn't have a CLA and AFAICT give commit rights to almost anybody who ask for them; I'm not aware of any issue with that approach (even though I wouldn't adopt it for my own projects).

So no, I don't have much experience with CLAs. I know I should setup a CLA for my own projects, and I'll eventually do it. FWIW, I'd probably copy the CLA from Square or Google or the ASF and setup an automatic check on pull-requests with ClaHub.

tbroyer avatar Feb 07 '15 11:02 tbroyer

A couple links about CLAs: https://www.clahub.com/pages/why_cla & https://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/ TL;DR: you don't have to worry too much when you use the ASL (which is the case of the gwt-gradle-plugin), though it's a good idea to have one.

tbroyer avatar Feb 07 '15 11:02 tbroyer

A simpler alternative to the known CLA is the Developer Certificate of Origin (DCO) introduced and used by the Linux Kernel. A contributor has to sign-off his/her commit and by doing so he/she accept the text published at http://developercertificate.org/ .

The DCO text is way easier to read and understand, it is easier to "sign" (just git commit using -s parameter), you can have multiple signed-off per commit if multiple authors have written the code (e.g. multiple commits squashed into one), and last but not least all the information is stored in VCS so you don't have to keep track of it manually.

Beside Linux Kernel other popular projects like Docker and Samba use the DCO mechanism.

If you want to reuse the wordings that Linux Kernel uses then a good starting point is https://github.com/wking/signed-off-by .

I would really like to see GWT also adopting DCO because then we should be able to integrate Gerrit + Github and finally allow Github pull requests for GWT without much hassle.

jnehlmeier avatar Feb 07 '15 16:02 jnehlmeier

Stumbled on https://wiki.openstack.org/wiki/OpenStackAndItsCLA while looking for DCO vs. CLA. Subtitle says “Or, if there was ever a license for which CLAs were unnecessary it's the Apache License.” They advocate against the CLAs currently used by OpenStack and suggest “ that the project takes a close look at the DCO and seriously considers moving to this approach.”

I didn't know about DCOs, thanks for the information @jnehlmeier

tbroyer avatar Feb 08 '15 00:02 tbroyer