Skip to content
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

Open
beckettsean opened this issue Sep 13, 2023 · 4 comments
Open

horcrux should enforce a contributor licensing agreement #200

beckettsean opened this issue Sep 13, 2023 · 4 comments
Labels
Type: Documentation Improvements or additions to documentation

Comments

@beckettsean
Copy link
Contributor

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

@beckettsean beckettsean added the Type: Documentation Improvements or additions to documentation label Sep 13, 2023
@chipcope
Copy link

@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.

@akc2267 akc2267 self-assigned this Oct 23, 2023
@jonathanpberger
Copy link

@chipcope @beckettsean is this done? What's the next action here?

@beckettsean
Copy link
Contributor Author

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.

@akc2267
Copy link
Contributor

akc2267 commented Jan 29, 2024

This should be covered by Apache2 license. We may need to revisit this for SOC2, but otherwise iceboxing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

4 participants