# Why you probably shouldn't add a CLA

**TL;DR:** Contributor license agreements greet new contributors with a legal contract, add administrative overhead for everyone, and shift legal blame onto the people least equipped to defend against it. Unless you're dual licensing, rely on the open source norm of inbound = outbound instead.

Published 2018-01-02 · [View on Ben Balter's site](https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/)

---

Contributor license agreements (or CLAs for short) have gained a lot of visibility in recent years as some prominent open source projects have opted to adopt them. If all the cool kids are doing it, should your open source project? Probably not. Here's why:

## What is a CLA?

If you're new to concepts like copyright, patents, and licensing, this primer on [everything an open source maintainer might need to know about open source licensing](https://ben.balter.com/2017/11/28/everything-an-open-source-maintainer-might-need-to-know-about-open-source-licensing/) may provide some helpful background.

In short, think of a CLA as a "reverse open source license." Whereas open source licenses are a copyright grant for users to use the project, a contributor license agreement grants the project the right to incorporate a contributor's code. Contributors may also be required to attest that they have the right to submit the code, or the CLA may include an explicit patent grant. Some CLAs go so far as to actually assign the developer's copyright to the project.

Unlike licenses, however, contributor license agreements, or CLAs, are not standardized, meaning if you're a contributor, you'll have to read each CLA to determine what legal rights you're giving away, before contributing (and hope you can parse what's often dense legalese if you're not yourself a lawyer).

## Why projects adopt a CLA

I suspect projects often adopt a CLA because they don't consider (or underestimate) its impact on potential contributors and how likely those people are to contribute. Or they deliberately put minimizing legal risk ahead of maximizing the project's potential community. There's not a lot published in support of CLAs, but Julien Ponge, a CS professor, [writes](https://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/):

> Requiring a contributor license agreement is a sign that you intend to sustain your project in the long run with responsible practices regarding intellectual property management. Responsible open source developers aren't afraid of signing contributor license agreements: they simply understand the legal implications of sharing source code with the rest of the world.

I'd push back on the assertion that "responsible" open source developers appreciate CLAs (or that "fear" should be the bar for adoption), as well as the implication that projects should only cater to established developers. Much of open source is about growing communities around code, and a big part of that is inspiring the next generation of software developers, especially those from non-formal backgrounds.

CLAs are generally a [cover-yourself measure](https://en.wikipedia.org/wiki/Cover_your_ass), meant to keep maintainers (or the project or its corporate backer) from facing legal trouble over the community contributions they accept. They are one way to manage a maintainer's exposure to intellectual property liability, especially if that maintainer is a for-profit business. Specifically, they make ownership of (and liability for) the project's intellectual property explicit.

> **What if the business model is selling exceptions to the GPL?** Then a CLA is the cost of that business model, so be honest about who pays it. Dual licensing (copyleft for the community, a proprietary license for anyone willing to pay, the way MySQL and Qt have done it) only works if the company can relicense every line, including the ones volunteers wrote for free. Contributors notice when their gift becomes someone else's product. And the same control that lets you sell exceptions lets you change the license outright. When HashiCorp did that to Terraform, and Elastic and Redis made similar moves, forks followed (OpenTofu, OpenSearch, and Valkey), and plenty of the community went with them. A CLA can protect your revenue. It can't buy back goodwill. If all you need is to know contributors have the right to submit their code, a [Developer Certificate of Origin](https://developercertificate.org/) does that without the paperwork.

## Maintainers should advocate for their community's needs

The role of an attorney, especially a transactional attorney, is to minimize legal risk. For most intellectual property transfers in the business world, that means lots of corporate paper and due diligence. When one company buys another company's software, be it a procurement or an acquisition, it often involves lengthy negotiations resulting in contracts with tens or hundreds of pages to ensure both parties exchange exactly what they intended to transfer, no more, no less. When dealing with other corporations (and their attorneys), there's often little downside to doing so, but a big potential downside if they don't (and something goes wrong).

Contrast that with open source licensing, which often carries equal legal weight, but almost exclusively without those heavyweight legal safeguards (or a corporate entity on the other side of the negotiating table to serve as a counterbalance). With that "traditional" baseline in mind, it's natural then, for corporate counsels to suggest the company take steps to "paper" the transaction (and in doing so, maximize the company's legal rights). From the attorney's standpoint, adding more paper can only help to firm up the transaction (and move the risk needle closer to zero). By role, though, they don't necessarily advocate for the needs of the project as a whole, or represent the project's contributors (who look to maintainers to represent their interests in those internal discussions).

As project maintainers work with their corporate counsel to decide if they should add a CLA to their project, keep in mind that legal's role (and area of expertise) is to advise business owners how to minimize risk, not how best to run a successful open source project (the maintainer's area of expertise). Such risk mitigation measures (and the likelihood that the feared harm might occur) must be balanced against your business motivations (such as your project's goals and its long-term viability), and I'd argue, should be resolved in favor of contributors, not the corporation.

## CLAs create a contribution-hostile developer experience

I spend a lot of my day helping open source maintainers to [grow healthy and vibrant communities around their projects](https://ben.balter.com/2017/11/10/twelve-tips-for-growing-communities-around-your-open-source-project/). If one of the most common reasons to open source a project (and indicators of success) is to receive contributions from others, why then would a project maintainer add significant [friction](https://ben.balter.com/2013/08/11/friction/) to advancing one of their primary goals? CLAs require that the first interaction between an open source project and a potential contributor involve a formal and complex legal agreement which signs away their legal rights. That's no way to greet a newcomer. Submitting one's first contribution to an open source project is already scary enough as it is, even without the threat of a lawsuit as the first volley.

Most open source developers aren't lawyers, and they shouldn't have to be to contribute. If a project optimizes for developer experience to maximize contributions, it makes no sense to require contributors to hire outside counsel to evaluate what they're agreeing to. Often they'd also need sign-off from their employer's corporate counsel before they're allowed to contribute. That can stretch even the smallest contribution from minutes to weeks, assuming approval comes at all, which many corporate cultures don't guarantee.

Imagine the "give a penny, take a penny" dish at your local convenience store. It's a win for both customers and the business by facilitating faster cash transactions. It works because dropping a penny in the dish is a near-frictionless experience. Now imagine instead, the corporate counsel walks by seeing this and says "Whoa, whoa, whoa! We don't know where that money's from or if they even intend to donate it!" All of a sudden, customers must now sign and date a "short and simple" two-page contract before they're permitted to drop a penny in the dish. Even though the risk that a bank robber is going to make a beeline for chips and a soda and leave a stack of freshly stolen $100 bills in the dish is close to zero, you've now also made the likelihood that a well-intentioned customer will leave a penny almost as unlikely due to the transactional overhead involved.

In the software world, potential contributors silently opt out. That means downstream consumers fix more bugs and implement more features without contributing them back to the community (and the project never learns those contributions were chilled).

## CLAs require significant administrative overhead

CLAs are legal contracts contributors agree to prior to contributing to a project, intended to minimize maintainer risk. How then, does a project know when a contributor has "signed" a CLA?

As with many things in law, digital contract formation offers a spectrum of options, depending on how much risk the maintainer is willing to accept that a contributor might later claim that they never agreed to the contract. Put another way, it's a question of how "signed" you want the CLA to be. At one end of the spectrum, it might be a link to the CLA with some sort of "by submitting you agree…" disclaimer ("browserwrap") or an explicit "I agree to the CLA" checkbox that enables the submit button ("clickwrap"). At the other extreme might be the requirement that developers print the CLA and submit a physical "wet" signature before they can contribute (sadly, still not uncommon among older projects). Most projects that have adopted CLAs land someplace in the middle, treating electronic signatures as sufficient, but even electronic signatures create lots of administrative overhead, both for the contributor and for the maintainer.

For the contributor, CLAs require the contributor to parse an often dense and complex bespoke legal document. Even if they are able to do so, if they work for a company that produces software, there's a good chance that they'll need to get sign-off from their employer's lawyers, a non-trivial process. The reason being, CLAs require that developers certify they own the copyright to their code, and that their contribution does not infringe on the rights of others, two non-obvious determinations in the case of professional software developers. For one, depending on the time of day, computer used, type of contribution, or even employee handbook, the code may be the property of the employer. For another, the employee may have theoretical access to trade secrets and other confidential information, meaning they may inadvertently jeopardize a corporate patent or agreement, even if they didn't intend to do so.

For the maintainer, the project needs to stand up a system to track every potential contributor that has signed the agreement, as well as a CI-like mechanism to ensure commits cannot be merged unless covered by the CLA. Yes, there are services out there like CLAHub, but in my experience, since CLAs are non-standard, so too are the processes required to implement them, meaning many projects will need to create their own acceptance experience. Regardless of the means, unlike say, a license, in almost all CLAs, assent isn't manifested by use (or in this case submission), meaning maintainers must stand up and maintain an additional system, custom or third-party.

## CLAs shift legal blame to the party least equipped to defend against it

From a maintainer's perspective, CLAs make a lot of legal sense. "We shouldn't accept code unless we know it's clean." The problem comes when you take a step back and look at the system as a whole. At least among projects that implement CLAs, the maintainer is most likely a corporation or a non-profit, both sophisticated organizations that likely have intellectual property attorneys on staff or on retainer.

Contributors, on the other hand, are most often individuals. If they're a student or hobbyist, they likely don't have (or can't afford) an attorney, and are less likely to have extensive training in intellectual property best practices. Even if they work for a company that produces software, the corporate attorneys that they would consult represent the best interests of the company, not the employee, even if it's the employee's name ultimately on the commit.

Ultimately, you have a highly sophisticated, highly resourced legal entity, and an individual with little to no legal training. When designing a system intended to foster the free flow of information, where would be the best place to allocate legal risk? CLAs shift the legal risk for copyright infringement, patent infringement, or other bad acts, intentional or otherwise, from the project (the entity best positioned to defend a legal claim, and often the one most directly benefiting financially), to the contributor (the one in the least advantaged negotiation position, often volunteering their time for the project's benefit).

## If a license isn't good enough for maintainers, you shouldn't subject users to it

For a long time, [the basic norm of open source licensing has been `inbound = outbound`](https://opensource.com/law/11/7/trouble-harmony-part-1#contribution-policies-and-free-software-tradition), meaning that a contributor contributes to a project under the terms of its open source license. Think about it logically: if I submit code to be incorporated into an open source project, with the knowledge (constructive or actual) that it will be distributed under a certain license, I must intend that code to be licensed similarly. Sure, there's still that "well they could argue…" factor, as with digital signatures, but more recently, [GitHub made that relationship explicit by incorporating an `inbound = outbound` clause into its Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license), meaning if a pull request is submitted via GitHub, it is submitted under the project's open source license.

The question then becomes, if the project's open source license isn't enough for maintainers to feel comfortable accepting code, why should end users be expected to feel comfortable enough to do so? Put another way, why should project maintainers be granted rights and protections beyond those granted to end users (and other contributors)? Most often, this is a sign that the license the project's using isn't sufficient for the project's industry or the maintainer's legal posture, and moving to a more patent-aware license like Apache may resolve the need for a CLA entirely.

## Your project's legal framework should help it thrive

The Software Freedom Conservancy [gives the following advice](https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/): you (and your lawyers) need to distinguish between "nice assurances we'd like to have" and "what legal assurances our [open source] project actually needs to assure it thrives," and I tend to agree.

Does your project *need* a CLA? In most cases, probably not, and I'd argue that such a position should be the community default absent a strong and specific reason to the contrary. But if you're lucky enough to have a long-established project where contributions aren't a concern and your project's backer [places a legal target on your back](https://ben.balter.com/2017/11/28/everything-an-open-source-maintainer-might-need-to-know-about-open-source-licensing/#when-in-doubt-follow-the-money), it might make sense.

Each organization's sensitivity to legal risk is different. If your corporate counsel asks you to add a CLA, don't assume it's a necessary appendage of a mature open source project. I urge you to work with them to balance the likelihood of legal harm against the practical cost of minimizing it, and optimize for the contributors' experience, not the corporation's.

It's possible to have a successful and sustainable open source project without a CLA. It's not possible, however, to have a successful or sustainable open source project without a strong influx of new contributors.