-
Notifications
You must be signed in to change notification settings - Fork 3
Should we require a CLA for code contributions? #24
Comments
👍I think this would be a good idea. I think we should consider trying to make the CLA and licensing of the projects adopted as compatible/mindful of Go's own CLA and licensing, so that it would be possible to take packages we have here and propose them to be included in the stdlib or similar. I'm not proposing that we make that our goal, but that we could make that possibility easier to occur. |
I am not sure how much a CLA would help. We would still need to track down the original owners/contributors. |
IANAL. Reading through the Google CLA, it seems to me like the agreement is made between the copyright owner or legal entity authorized by the copyright owner, and Google. If the Gofrs were to adopt a CLA, contributors (the copyright owners) would make an agreement with The Gofrs, but it is unclear to me if The Gofrs is any kind of entity that can make such an agreement, in such a way that the agreement has legal value. It would be great if someone could clarify this. Perhaps a CLA would be worthwhile for clean room projects developed by the gofrs themselves. |
Yes. That's something to consider as part of this. I know there are "Legal Entity" requirements for CLAs, and if we feel it would be a good investment it would be good to see what is needed to make that work. |
One good recent example why having CLA is a good idea lerna/lerna#1622 But then - CLA must be compatible with all the original licences of the adopted projects and new licences (in case if any of those would be relicensed). A MANDATORY WARNING: not a lawyer here |
Wouldn't we have to get contributors from before we adopted a project to sign off on a license change too? |
I'm undecided, but I did want to mention that Hugo uses https://cla-assistant.io/ https://cla-assistant.io/gohugoio/hugoDocs Here's the related issue to use a Google bot for the fsnotify CLA -- fsnotify/fsnotify#193 |
Yes. A CLA would make sense if we plan to ever relicense a project. As I don't see a need for us to re-license away from BSD or MIT for any project, I don't personally see the need for a CLA. |
I think a CLA makes sense, just to avoid any legal hassle later. Either that or make license an explicit part of the acceptance criteria for adopting a project. |
This is kind of a good point. What happens if a project approaches us with "less free" licensure? Do we demand they change it? I think that requires an enormous amount of effort with some licenses (requires voting and removal of less-free code). |
Some interesting thoughts on the subject from a GitHub Project Manager; https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/ I would echo that generally I find CLAs to be obnoxious if all I intend is a small one or two line commit or a documentation change I'm left to ask myself "do I care that much"; generally I think most humans are lazy and will tend to lean in this direction. |
FWIW I've had the CNCF/Kubernetes CLA fail multiple separate times, so much so that I've been unable to commit single line changes to upstream Kubernetes. Placing a burden on contributions to already abandoned projects would prevent contributors (or leave contributions in limbo). |
Could any CLA just be a case of "You have permission to, and grant permission to, use contributed code under the exsisting license"? |
This was raised as a question at the Gofrs community table, and I think it's better for us to answer this sooner as a group. CLAs have benefits, one example being that it makes it so that we don't need to track down individual contributors if we want to change licenses (not that I suspect we ever would). With everyone being welcome in the organization, they would still have a say in any sort of changes.
@gofrs/all, what do you think?
The text was updated successfully, but these errors were encountered: