[HN Gopher] You probably shouldn't add a CLA to your open source...
___________________________________________________________________
You probably shouldn't add a CLA to your open source project (2018)
Author : Amorymeltzer
Score : 21 points
Date : 2021-10-19 20:54 UTC (2 hours ago)
(HTM) web link (ben.balter.com)
(TXT) w3m dump (ben.balter.com)
| mcphage wrote:
| It's kinda weird to write an entire article talking about CLAs
| but not actually say why they're being adopted (instead saying
| they're being adopted because maintainers don't consider the
| costs, which is the opposite of a reason). Namely, to prevent
| contributors from withdrawing the project's license to their code
| after the fact, like what happened with Mojang's Forge.
| phendrenad2 wrote:
| I don't get the point of CLAs. Will they prevent you from being
| sued, or help your case if you are? Will they allow you to avoid
| removing copyrighted code that was contributed under false
| pretenses? Has any of this been tested in an actual court?
| Croftengea wrote:
| CLA == Contributor License Agreement
|
| "You can think of a CLA as somewhat of a "reverse open source
| license". Whereas open source licenses are a copyright grant for
| users to use the project, a contributor license agreement, at its
| core, is the right for the project to incorporate a contributor's
| code."
|
| CLAs are bad because:
|
| * "CLAs create a contribution-hostile developer experience"
|
| * "CLAs require significant administrative overhead"
|
| * "CLAs shifts legal blame to the party least equipped to defend
| against it"
|
| You're welcome :)
| warkdarrior wrote:
| > * "CLAs shifts legal blame to the party least equipped to
| defend against it"
|
| I don't really get this one. The argument in the post is that
| the contributor does not the money/knowledge to make the legal
| decision required to sign the CLA. But typically the CLA
| requires the contributor to confirm that the contributed code
| is theirs to give away. The contributor should be able to make
| that determination!
| csnover wrote:
| Most of the arguments against the use of a CLA in this essay feel
| like legitimate but generic laments of the complexity surrounding
| software licensing and employment contracts, not actually
| relevant to whether or not most projects should adopt CLAs.
|
| CLAs can be written to be confusing (like anything), but in my
| experience they are no more confusing than open source licenses
| themselves. Suggesting using Apache License to avoid the
| confusion of a CLA is particularly weird to me since that is a
| long and complicated license compared to the most common OSS
| licenses.
|
| Bad process can also make CLAs hard, but that's not any
| fundamental problem with the concept of a CLA. As someone who
| also worked on improving the CLA process for a non-profit OSS
| foundation, I can say with confidence that the administrative
| burdens are insignificant when your process isn't broken. It
| feels to me like saying "you probably shouldn't use code linters"
| as a blanket rule because some projects use some uncommon coding
| style.
|
| Even after reading this I don't really understand why the author
| seems to think that CLAs mostly exist to shift liability toward
| third parties. It's not as though the project still gets to use
| the IP-infringing code just because the person who put it there
| signed a CLA, and it's not as though the absence of a CLA keeps
| all parties from being sued. The legal entity that owns the
| project would probably be able to avoid any claim of wilful
| infringement, but I can't think of any other way that a CLA
| _shifts_ legal blame. (However, IANAL.)
|
| On the other hand, I've been involved in OSS projects where a
| contributor didn't sign a CLA, contributed code, then became
| acrimonious after some of their other ideas were rejected and
| threatened to sue the project if their code wasn't removed. While
| it would've been extremely difficult for them to do so, it
| created a lot of problems that simply wouldn't have existed if
| there were a signed CLA to point to.
|
| The fact of the matter is that the long tail of OSS projects are
| not owned by big megacorps with endless pockets for lawyers; most
| are either part of 501(c)(6) non-profits like the Linux
| Foundation or just solo developers, and for those projects having
| a CLA is probably _even more_ valuable.
| glonko wrote:
| I've only signed a CLA to contribute to emacs, even as a big
| supporter of the GPL and understand why they want a CLA, its a
| pretty huge pain in the hole to contribute with fairly little end
| user or even contributor benefit. It just slows down development
| so much, at least for new developers I guess.
| judge2020 wrote:
| > "CLAs shifts legal blame to the party least equipped to defend
| against it"
|
| Ah, I forgot about the hundreds of thousands of dollars of
| retainer every open source maintainer has dedicated to defending
| against copyright lawsuits. Silly me.
| splix wrote:
| If I have an OS project and someone submitted a Pull Request with
| something they cannot really publish. Like a piece of proprietary
| code from their work. Without a CLA, I have full responsibility
| if I accept it, so their lawyer can easily sue me for that piece
| of code.
|
| I mean, that actually happened to me a few years ago, and their
| lawyers forced me to completely delete the whole project, just
| over a few lines of someone's code. So as for me, CLA gives at
| least some additional protection against lawyers trying to shut
| down some competing OS project.
| RyJones wrote:
| As someone that has a huge bet on DCO - for you, as a
| contributor, is DCO better?
| splix wrote:
| That's an option too. Though as for me it's the same efforts
| for a contributor.
|
| Unless you require the CLA physically signed on paper.
| Otherwise there are GitHub addons that do CLA just with one
| click once after making a first Pull Request.
| RyJones wrote:
| I'm thinking more `git commit --amend -s ...`
| drekipus wrote:
| Forgive my ignorance, but why couldn't you work to replace it,
| or at least revert the commit?
|
| If it was completely open source, they would have to prove that
| you accepted code maliciously, ie: knowing that the code was
| proprietary and for unfair advantage, etc.
|
| Do you feel like they were bluffing? Because I definitely do.
| phendrenad2 wrote:
| Lawyers will always ask for the most favorable outcome for
| their client, which in this case was the GP deleting the
| project. Had the GP gotten their own lawyer (or even "call
| their bluff" by letting them either take it to court or
| GTFO), I'm guessing they could have kept the project. (Of
| course, if GP knew before merging the code that it was
| someone else's code, then things are likely different, and
| going to court might not be favorable)
| judge2020 wrote:
| They could argue that the git commit history being immutable
| means that they have to delete the entire repository to
| remedy the existence of the proprietary code being available
| for download. The best way to continue would be to either
| rewrite history (eg. with BFG) or fix it, destroy the git
| history, then start from scratch.
___________________________________________________________________
(page generated 2021-10-19 23:01 UTC)