Anti-CLA action: what to do when you encounter a CLA

We need to do something about the scourge of software keeping a rug-pull in their back pocket through the use of CLAs with copyright assignments. This thread serves to organize action against these projects.

What is a CLA and why is it bad?

A CLA is a “contributor license agreement”, which is a statement that contributors to a free software project are asked to sign before the upstream maintainers will accept their contribution. These take many forms, not all of which are harmful,[1] but most of them include a clause similar to the following (this example is taken from MongoDB):

By submitting a Contribution, you assign MongoDB all right, title and interest in any copyright you have in the Contribution, and you waive any rights, including any moral rights, database rights, etc., that may affect our ownership of the copyright in the Contribution.

Another common form of copyright license looks similar to this:

  1. Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to Ant Group and to recipients of documentation and software distributed by Ant Group a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.

The purpose of these clauses is to give a single entity, the project steward, a special license distinct from the one that everyone else gets, so that they may use your contribution in any way they please, irrespective of the license terms you get to use. Generally speaking, the only reason to do this is to allow them exclusive access to commercial exploitation of the software, or to set them up for a future rug pull in which they change the software to a proprietary license (again, to advance their private commercial interests).

Further reading on CLAs:

What to do when you encounter a CLA?

You do not have to sign the CLA. You should refuse and publicly state the reason for your refusal. State clearly that they may use your contribution but only under the original license terms that you received the original software under, e.g. BSD, MIT, GPL, etc.

You can make use of your changes privately, and distribute them yourself. Put up your modified version on your favorite source code repository service. Talk to your Linux distro about including your patch downstream.

Then, consider the following:

Direct action against CLAs: hard fork the project

This is where the political part comes in: you can take direct action against the scourge of CLAs by making a hard fork of the project.

  1. Rename the project. Be wary of any trademarks held by the project’s stewards.
  2. If it uses a permissive license, consider adding a copyleft license to protect your changes from being taken by the original project stewards.
  3. Publicize the fork. Seek out contributors and users. Adopt it as your own and market it as such.

You can take changes from the upstream project and incorporate them into your fork. Treat it as your own project now, and make it clear that anyone who wants their copyright respected is encouraged to contribute to your fork rather than sign the upstream CLA.

Consider offering to abandon your fork and merge with the original upstream project again if they agree to remove the CLA.

This thread on WFS

Feel free to ask questions here about CLAs and discuss them generally, as well as post projects which use CLAs and organize action against these projects.

Now go forth and defend free software!

List of projects using a CLA

  1. Some CLAs are designed to simply establish provenance, which is to say, it’s a cover-your-ass move which makes the contributor liable for the originality of their code by making you say “yes, this is my original work, or I am authorized to release it under the license terms applicable to this project”. This kind of CLA is fine, but the DCO is better. ↩︎


Also: please post it here when you encounter a project with a CLA regardless of what you decide to do about it, so that we can keep track of them.

1 Like

Products of the Qt Company, notably Qt and QtCreator.

The “Direct action” advice falls apart here: those are big projects relative to the number of people interested in maintaining them. When Qt Company started lagging releases, KDE still didn’t decide to fork.

I’m still kinda interested in forking QtCreator and adding Rust debugging support, but I don’t have enough time to maintain a fork on my own. Any collaborators?

I could contribute patches to downstream distros, but even if they take it, what happens next - what’s the mechanism of change? Will they be interested in maintaining the patches forever? If patches keep appearing, how likely is it that the distro stops accepting them versus convinces the upstream to drop CLA?

I think you could bring up a fork with KDE, they have the labor pool to maintain it. Did they ever discuss this?

Depends on the size of your change. A small patch is more likely to be carried downstream than a bigger change. But if you’re in a position to make bigger changes you might also be in a position to maintain a bigger fork.

I have a vague recollection that this was considered. A quick search gives me very little info:

Maybe I should ask at the source.

I think a serious discussion about a Qt fork could go well with KDE. This is actually a case where I think there does exist a sizable labor pool ready to take on a fork, without having to build it from scratch.

Signal Messenger is another large project that requires a CLA, featuring this clause:

  1. Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to Open Whisper Systems and to recipients of software distributed by Signal Messenger a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, and distribute Your Contributions and such derivative works, as well as the right to sublicense and have sublicensed all of the foregoing rights, through multiple tiers of sublicensees, provided that in all cases, Signal Messenger will make Your Contributions available under an OSI-approved open source license.

Some projects to add to the list:

  • Audacity
  • Synapse (the Matrix server implementation)

(also Aseprite, which used to be GPLv2, but they eventually used the CLA power to become proprietary)

Audacity was forked:

That’s true, although Audacity still exists and is GPL afaik.

Aesprite was also forked: GitHub - LibreSprite/LibreSprite: Animated sprite editor & pixel art tool -- Fork of the last GPLv2 commit of Aseprite

I know, that’s where I got the commit link from. Libresprite is very based :smiley:

1 Like

The Unicode Consortium also requires a CLA for contributing to their libraries:

Canonical recently added a CLA to LXD. I imagine there’s other canonical projects with the same.

I find their wording a bit sneaky:

All contributors must sign the Canonical contributor license agreement, which gives Canonical permission to use the contributions. The author of a change remains the copyright holder of their code (no copyright assignment).

and then similar on their legal/contributors page:

It’s the easiest way for you to give us permission to use your contributions. In effect, you’re giving us a licence, but you still own the copyright — so you retain the right to modify your code and use it in other projects.

They make it sound like this is simply required for use, but the actual CLA text is a few pages and far more widespread, including:

(2.1,b) To the maximum extent permitted by the relevant law, You grant to Us a perpetual, worldwide, non-exclusive, transferable, royalty-free, irrevocable license under the Copyright covering the Contribution, with the right to sublicense such rights through multiple tiers of sublicensees, to reproduce, modify, display, perform and
distribute the Contribution as part of the Material; […]


(2.3) Based on the grant of rights in Sections 2.1 and 2.2, if We include Your Contribution in a Material, We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses. […]

Their CLA FAQ makes not mention of possible re-licensing.
Some additional context and license info by Stéphane Graber here.

Wow, that’s fucking disgusting. That’s one of the most misleading ones I’ve seen.

their enforcement of that is unclear to me, btw. the signal-desktop repository has a CI-like check for your commiter e-mail address, but i’ve contributed to their fork of the boring-sys crate (MIT), and tried contributing to libsignal (AGPL-3.0-only!) and their fork of webrtc (BSD-3-Clause) - these PRs were closed, but for completely different reasons, and the CLA wasn’t checked at all in that process. i haven’t signed that CLA as an especially abusive one, since they require providing a physical address and a phone number

Incus is worth mentioning here: Linux Containers - Incus - Introduction

There’s Gitea, who require listing “The Gitea Authors” as copyright holder, effectively requiring copyright assignment. (Forgejo does not require such a thing, and is a hard fork of Gitea.)

WriteFreely, AGPL-3.0 (only? later?) with CLA.

Deno (MIT), a JS runtime, has one:

You hereby grant, and agree to grant, to Deno Land a non-exclusive, perpetual, irrevocable, worldwide, fully-paid, royalty-free, transferable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, and distribute your Contributions and such derivative works, with the right to sublicense the foregoing rights through multiple tiers of sublicensees.