6 ms·
I contribute pull requests to quite a few github projects. However I avoid contributing to (or even using) projects with a Contributor License Agreement. Such p
by yetanother1 10y ago
I contribute pull requests to quite a few github projects. However I avoid contributing to (or even using) projects with a Contributor License Agreement. Such projects are too bureaucratic.
- pcl 10y ago> I avoid contributing to (or even using) projects with a Contributor License Agreement. That's a pretty tough thing to do. Most (all?) Apache projects require a CLA, as does Go, Java, Mysql, Cassandra... It's pretty standard for any project that is both managed by a corporation and accepts third-party contributions. EDIT: removed Postgres. Thanks, 'anarazel!
- Nadya 10y agoAll of those projects also have alternatives that don't require a CLA. The solution is to avoid projects by bureaucratic corporations.
- yetanother1 10y ago~~You got me on Postgres. Don't use the others.~~ Edit: another post states that Postgres doesn't require a CLA for contributors. So I don't use any software requiring a CLA.
- anarazel 10y agoPostgres doesn't have a CLA.
- shadowfacts 10y agoWhy? Aside from having to click a button saying that you agree to the CLA, how does it affect you in any way? CLAs aren't about making a project more bureaucratic, they're about transferring the rights over the code you're contributing from you to the project, so that there's no dispute over who the code belongs to.
- yetanother1 10y agoI don't like the idea of handing over my contributions to another party under their terms. Either release software under a common open source license (BSD, MIT) or not. Don't add additional terms with some custom license that certainly wouldn't help me.
- edgyswingset 10y agoAnother aspect of a CLA is the ability for a company to cover themselves legally. Say I work at MegaCorp (they make heavy use of Go in some backend systems), and didn't bother making sure I had permission to contribute on MegaCorp time (and thus, contribute MegaCorp IP). I make some PRs to Go which improve the Go garbage collector, which Google happily accepts. These changes help Google and they could help MegaCorp if some of their projects use Go. Hooray! Somewhere down the line, someone at MegaCorp notices that I've been contributing to Go's garbage collector on MegaCorp time without permission. I may or may not be fired. However, Google has now benefited from what is legally MegaCorp IP without the permission of MegaCorp. If this is in the USA, there's a decent chance that MegaCorp tries to sue Google. That's a headache that I'm sure nobody at Google would want to deal with. If there was a CLA which I had to sign, saying that I had permission to contribute MegaCorp IP, Google has a document clearly saying that I had permission to contribute MegaCorp IP. This is a far better situation for Google than if they had no such document.
- paulddraper 10y agoI don't understand. Whether you had the document or not, MegaCorp's lack of permission remains the same. And Google's benefit from your MegaCorp contributions remains the same. MegaCorp legal recourses remain the same. The situation is exactly the same.
- traviscj 10y agoNo, because before Google was guilty of using MegaCorp IP, but now, you're guilty of telling them they could, so you are responsible now, not Google.
- wyldfire 10y agoI agree that CLAs are a bit of a hassle, but it makes things much saner for licensors and licensees alike. One high profile project that doesn't use them is the linux kernel. It's mostly only the uniformity of mind among contributors that keeps things on course. Can you imagine the consequences if one or more developers decided that they wanted to change the terms for their contributions? --- scratch that! Ok, I'm a bit out of date: linux's DCO solves this problem without requiring a DCA. But think of other projects that want to have long term growth and what challenges could arise in the face of changing attitudes over time.