Why attempts to protect your project with legal voodoo are likely to backfire on you.

I have a little list (they never will be missed) of stupid things that open-source projects should stop doing. High on this list are CLAs (Contributor License Agreements) and their cousin the mandatory CA (Copyright Assignment).

In this article, I explain why CLAs and CAs are bad ideas and what we ought to be doing instead. In obedience to custom, at this point I issue the ritual disclaimer "I am not a lawyer", but one does not have to be a lawyer to understand the law and game out the ways CLAs and CAs fail to achieve their intended purpose. And, I have researched these failure modes with both lawyers and executives that have literally billions of dollars at stake around IP violations.

I've made a distinction between CAs and CLAs; we can make a further one between ICLAs (Individual Contributor License Agreements) and CCLAs (Corporate Contributor License Agreements). While all are about equally useless, they have slightly differing failure modes.

First, let's consider the ICLA. Some projects require that you sign one before being allowed to submit changes to their repository. Typically, it requires you to assert that (a) you affirmatively choose to license your contributions to the project, and (b) you have the right to do that.

Here's the problem. If you are employed, you almost certainly cannot make claim (b), and the project you are probably trying to help is only setting itself up for trouble if it behaves as though you can. The problem is that most employment contracts define any software you write on working hours or even off hours in connection with your job as "work for hire", and you don't own the rights to work for hire—your employer does.

CAs, such as the Free Software Foundation requires, have exactly the same problem. You don't own the copyright on a work for hire either. Therefore, you can't assign it. I'll get to the case of individual developers not in a work-for-hire situation in a bit.

The CCLA exists as an attempt to address the problems with ICLAs. It's not an agreement that you sign, it's an agreement your employer has to have pre-negotiated with the project to which you want to contribute. You then have to offer the project an identity that it can associate with that CCLA so it knows your contributions are covered.

That at least sounds like it might be useful. Why isn't it? To understand this, we need to do a bit more threat modeling. What is it that open-source projects hope to prevent using CCLAs?

Let's start with the one people tend to think of first: revocation. Say a code owner attempts to withdraw a contribution, either by claiming it was never made or by revoking the permission on the contribution. It's pretty obvious that a CCLA cannot prevent the claim that a contribution was never made; only tracking and attributing inbound contributions—which a version-control system does for you—can do that.

But a CCLA doesn't really help with the second case either. No CCLA is ever drafted in a way that makes it irrevocable, because corporate counsels rightly think it's their job to avoid that extreme of a commitment to any relationship; thus, a company that wants to defect can find a way to cancel the CCLA.

Anybody who thinks contributions made in good faith while the CCLA was in force aren't in jeopardy after such a defection has never witnessed what a big IP lawsuit looks like. I have been on the inside of one, and I can tell you that if the defecting EvilCorp wants to find a theory that implicates every line of code its employees—or an innocent third party—ever shipped to GoodProject under a CCLA, such a theory is going to be manufactured. And then GoodProject is in court, with the process as punishment.

(We should now all pause for a moment to spit in the direction of SCO.)

Another thing that people sometimes think CCLAs prevent is well-poisoning—that is, a malicious contributor from EvilCorp pushes patented code into GoodProject, and then EvilCorp sues to shut down the project or own it. Again, the existence of a CCLA between GoodProject and EvilCorp changes nothing; the obvious next move is for EvilCorp to fire the contributing employer and then loudly proclaim that while he/she was authorized to contribute code, nobody below Executive VP was authorized to sign away patent rights—a claim that has the advantage of generally being true.

The underlying reality here is that a CCLA can't protect GoodProject against EvilCorp defection from it because nothing can protect against EvilCorp defections. That's just the way it is, and performing ritual gestures like requiring that contributors come in under a CCLA is about as useful as pointing a hex sign on your house to ward off fires and floods.

A friend who manages IP risks for one of the FANGs says, from the inside:

If any player tries to take CCLAs seriously, they cause an N-squared-times-M combinatoric explosion where N is the number of companies in the world and M is the number of open-source projects in the world. Nobody actually keeps track of that; it is just kabuki theater that everyone hopes won't explode in everyone's face someday.

Are matters any better when there's no work-for-hire clause in the picture? No, not really. In that case, your contributors indeed have the right to license or assign something...but you have no practical way to audit their claim that they do in fact own what they submit, and in some cases (such as patented algorithms), they may not know themselves.

If someone with lawyers and money wants to use code nominally covered by an ICLA to damage GoodProject or (say) extort money from one of its sponsors, the ICLA is not going to stop that from happening. A well-intentioned contributor won't be able to stop it either.

The only case where an ICLA can help you is when an individual contributor wants to revoke a grant without EvilCorp backing, thinks it's valuable enough to go to court on, and can nevertheless be deterred from going to court by the agreement.

If you think this is an even remotely plausible scenario, can I interest you in a sure-fire bank transfer from a Nigerian prince? Because with individuals, as with EvilCorp, if they're capable of suing and think there's enough payoff on the line to sue, that ICLA is not going to keep you out of court. And, once again, the process would be punishment even if GoodProject actually won in the end.

Now let's back away from all these hypotheticals for a moment and consider reality. As I write this in April 2019, there is neither statute nor case law establishing that a CLA protects you from any kind of legal risk at all. A case of first impression could sweep away all these ritualistic gestures in a heartbeat.

That said, it's not quite true that the set of hypotheticals in which a CLA might be useful is empty. You could hit that narrow window where the expected payoff to the bad guy is little enough more than the cost of suing, that the CLA is an effective deterrent without having to test your CLA in court. So now let's consider how much you're paying to cover that unlikely case. What does a CLA cost your project?

First, a CLA costs your project contributions. Some potential contributors will be barred from signing CLAs by their employers. A much larger set (including me) are highly allergic to paperwork and process friction and have to get very invested in using a project with a CLA before they'll sign one.

In effect, whatever you think you're getting from a CLA, you're paying for in lost patches. Especially drive-by patches. Lots of people who might become casual contributors won't. Your many-eyeballs benefits will be lost to an extent that's difficult even to estimate.

Unfortunately, there's a more pernicious cost. CLAs might create the very ills they intend to prevent.

Every time a project says "we need you to sign a release before we'll take your code", it helps create a presumption that such releases are necessary—as opposed to the opposite theory, which is that the act of donating code to an open-source project constitutes in itself a voluntary cession of the project's right to use it under terms implied by the open-source license of the project.

Obviously one of those theories is better for open source—no prize for guessing which.

If it ever comes to a court case, one of the first things the judge is going to look at is community expectations and practice around our licenses. A jurist is supposed to do this in contract and license cases; there's some famous case law about the interpretation of handshake contracts among Hasidic Jewish diamond merchants in New York City that makes this very clear and explicit. Where there is doubt about interpretation and no overriding problem of of equity, the norms of the community within which the license/contract was arrived at should govern.

So, if the judge thinks that CLAs are best practice because we expect contribution permissions to fail closed unless explicitly granted, he/she is more likely to make that happen. On the other hand, if he/she thinks that community norms treat contribution as an implied cession of certain rights in exchange for the benefits of participating in the project, that is more likely to be how the ruling will come out.

CLAs are is yet another case of "Be careful what reality you assume. You might create it."

Turning to our penultimate topic, if CLAs are such a bad idea, why do any projects require them at all? Surely all those high-powered corporate lawyers can't be that wrong, can they?

That depends on what utility function you think they're maximizing. There is a common variety of lawyer who, under the banner of risk mitigation, advises his/her clients to perform legalistic gestures that are essentially voodoo invocations—not responses to reality but to weird, hypertrophied theories of future legal risk that all have one common factor. They make the lawyers important. Gee, what a surprise!

If your project takes its cue from one of these lawyers, it may very well develop an institutional habit of requiring a CLA/CA that is hard to shake, because doing so would mean admitting that all the costs sunk into that poor decision have been wasted. The voodoo can also be locked in place by a tacit assumption that Having a Process means you are Serious—bureaucratic behavior as a kind of status-seeking.

Okay, so what to do instead?

I have two recommendations. Both of them are also voodoo—at the present unformed state of the law they can't really be anything else. But they are, at least, low-cost voodoo that won't tend to drive away contributors and create presumptions that might steer a judge in a bad direction.

The first is a simple contract of adhesion. The NTPsec project has this language at the top of its guide for contributors:

By submitting patches to this project you agree to allow them to be redistributed under the project's license, according to the normal forms and usages of the open-source community.

If you know what a clickwrap agreement is, you may not be happy that they're enforceable and ubiquitous; I'm not, myself. But as long as they are, the good guys might as well get some use out of that. This language depends on the fact that contributions leave a signed record in your repository, and uses the same mechanism as clickwrap to turn contribution into an affirmative act that has no worse a chance of actually protecting your project than a CLA.

(How dare I make that last claim despite not being a lawyer? Remember, this is all voodoo; given the absence of governing law, nobody actually knows anything. Distrust any lawyers who try to tell you differently; if they are not trying to fool you, it's because they have already fooled themselves.)

The last bit, "according to the normal forms and usages of the open-source community", is important battlespace preparation. Remember those Hasidic diamond merchants? If this language ever comes up in litigation, probably the best defense we can have is for the judge to know up-front that there are normal forms and usages.

If NTPsec's clickwrap widget (full disclosure: I wrote it) is not heavyweight enough for you, you can do what the Linux kernel does with the Developer Certificate of Origin and "Signed-off-by" lines. Again, a contract of adhesion using the project repository to document affirmative consent.

Again, these are not magic bullets, because nothing is. But they have one virtue CLAs and CAs do not: they do no harm.