The CLA Denial-Of-Service attack
I just stumbled upon this weird mind bender this morning. I have found what I believe is a simple typo in the Ganeti documentation which has a trivial fix. But then, before I submitted a PR to fix it, I remembered that I had trouble getting stuff merged in Ganeti before. That's because they require a CLA (which is already annoying enough) that requires a Google account to sign (which is simply unacceptable). So that patch has been sitting there for months, unused and I haven't provided a patch for the other issue because of this very problem.
But that got me thinking. If I would want to mess things up real bad in a CLA-using project I don't like and:
- find a critical bug
- figure out a patch for the bug
- publish the patch in their issue tracker
- forever refuse to sign the CLA
Then my patch, and any derivative, would be unmergeable. If the bug is trivial enough, it might even be impossible to fix it without violating the letter of the law, or at least the process that project as adhered to.
Obviously, there's a flaw in that logic. A CLA is an agreement between a project and a (new) contributor. A project does not absolutely requires the contributor to sign the agreement to accept its contributions, in theory. It's the reverse: for the contributor to have their patch accepted, they need to accept the CLA. But the project could accept contributions without CLA without violating the law.
But it seems that projects sometimes end up doing a DOS on themselves by refusing perfectly fine contributions from drive-by contributors who don't have time to waste filling forms on all projects they stumble upon.
In the case of this typo, I could have submitted a patch, but because I didn't sign a CLA, again, the project couldn't have merged it without breaking their own rules, even if someone else submits the same patch, after agreeing to the CLA. So, in effect, I would have DOS'd the project by providing the patch, so I just opened an issue which strangely — and hopefully — isn't covered by the CLA.
Feels kind of stupid, really...
Instances of known self-imposed CLA DOS attacks:
- Ganeti (ganeti-instance-debootstrap)
- Kubernetes (kubespray, note that k8s "discussed" switching to DCO and the conclusion was that "DCO tooling needs improvement" so it can't be used)
It could accept the patch, yes. But if project wants to redistribute your code under licenses other than the one you contributed it under (e.g. commercially) - including future licenses that have not yet been written, it would not be able to do that without violating your copyright.
And looking at the Google CLA, §2 reads:
(emphasis mine)
It's not such an issue here, as Ganeti is 2-BSD licensed, so any contributions could be folded into proprietary offerings anyway, but for any projects that started off life under a more copyleft-ish license it would be. So Google just makes everyone sign the CLA to contribute to any of their projects anyway.
To sublicense is to grant a sublicensee some of the rights you have as a licensee yourself. It's not changing a license or relicensing. I don't think that the Google CLA as quoted would allow Google to change the license of contributed code in arbitrary ways.
Sorry, I didn't make my point in full.
As well as making your contribution under the project license, (like the BSD 2-clause) the Google CLA makes you give Google an additional license - the "perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of [...] and distribute" license described in that clause, and you've given them right to sublicense your contribution under that license.
So they can relicense all the code in the project that they wrote themselves (because they're the copyright holder), and they can sublicense all the code that was contributed by outsiders under a blanket "reproduce, modify and distribute" license that imposes no further obligations on them.