-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
horcrux should enforce a contributor licensing agreement #200
Comments
@beckettsean - I think that employing a standard CLA is a very good idea, even for contributions to projects published under an Apache 2.0 license. By requiring contributors to attest to their ownership of/license rights to the code they contribute, a CLA insulates us from liability in the event that the contributor, or a third party, later claims to own (or hold an exclusive license to) code that has been contributed to Horcrux by someone outside of Strangelove. I'm actually not sure that I completely agree with the author of the StackExchange post that Sean links to above. While I agree that paragraph 5 of the Apache 2.0 license protects the project owner from future claims by the contributor, I'm not certain that this language provides the same protection with respect to a claim by a third party who alleges that the contributor committed their code without permission. I'd have to do a little more digging here, but my understanding is that a key feature of any CLA is that it gives us someone to "point the finger at" in the event of such a claim by a third party. Anecdotally, the Apache Software Foundation appears to universally use CLAs for contributions to its projects published under Apache 2.0. I'd also be interested to hear from anyone who is concerned about the "friction"/chilling effect on contributions that might result from imposing a CLA. I'm assuming that any such effect would be de minimis and, therefore, easily outweighed by the benefits of implementing a CLA. But, I'm completely open to arguments to the contrary. If there is a real concern that a CLA will significantly affect folks' willingness to contribute to the project, then I may need to reconsider my calculus. |
@chipcope @beckettsean is this done? What's the next action here? |
The next action is to approve a CLA for our repos and add it to them. Currently none or our repos have this. It's a low priority as the risk is only present IF someone submits a PR that is approved AND later decides they retained the IP, or their employer decides the same, AND they decide to sue. Best practices, but nothing urgent. |
This should be covered by Apache2 license. We may need to revisit this for SOC2, but otherwise iceboxing |
Phrased as an imperative, but it's open to debate:
What is a CLA?
https://en.wikipedia.org/wiki/Contributor_License_Agreement
It's good because it requires contributors to attest that they have the rights to make the contribution they are submitting.
It's bad because it creates friction for first-time contributors:
https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/
It's probably redundant for Apache 2.0 licensed code, as long as that license won't ever change:
https://opensource.stackexchange.com/questions/5585/benefits-of-a-cla-when-using-apache-2-0-license
If we do use one, don't roll our own:
https://www.man.com/use-a-standard-cla-please
cc @chipcope for a legal perspective
The text was updated successfully, but these errors were encountered: