Why you probably shouldn’t add a CLA to your open source project

TL;DR: Contributor license agreements (a “nice to have” for many corporate-backed open source projects) create a contribution-hostile developer experience, require significant administrative overhead, shift legal blame to the party least equipped to defend against it, and are unnecessary given modern development tools.
9 minute read

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 may provide some helpful background.

In short, 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. 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 developers 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 that projects that adopt a CLA often do so because they don’t consider (or underestimate) the impact that it will have on potential contributors (and thus the likelihood that they will contribute), or purposely choose to prioritize minimizing legal risk over maximizing the project’s potential community. There’s not a lot published in support of CLAs, but Julien Ponge, a CS professor writes:

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 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 form of CYA, to prevent maintainers (or the project or its corporate backer) from landing in hot water due to the community contributions it accepts. They are one way to manage a maintainer’s exposure to intellectual property liability, especially if that maintainer is a for-profit business. Specifically, it makes ownership of (and liability for) the project’s intellectual property explicit.

Maintainers should advocate for their community’s needs

The role of an attorney, especially a transactional attorney, is to minimize legal risk. For the vast majority of 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), but by role, they do not necessarily advocate for the needs of the project as a whole, nor do the seek to represent the needs of the project’s contributors (who are looking to maintainers to represent their interests in such 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 (e.g, 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. 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 to advancing one of their primary goals? CLAs require that the first interaction between an open source project and a potential contributor to involve a formal and complex legal agreement which signs away their legal rights — not exactly a warm welcome. 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 is optimizing for the developer experience in hopes of maximizing contributions, it would be antithetical then, to require a contributor to hire outside counsel to properly evaluate what they’re agreeing to, or in many cases, also get the sign off from their employer’s corporate counsel before they are allowed to contribute, a frustrating experience that can shift even the smallest contributions from minutes to weeks, assuming the developer ultimately gets approval, an outcome that’s not guaranteed in many corporate cultures.

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 “Woah, woah, woah! 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 v-line for chips and a soda and leave a stack of freshly stolen $100 dollar bills in the dish is extremely small, 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, because potential contributors silently opt-out, that means more bugs are fixed and features implemented by downstream consumers, without being contributed back to the community (or the project ever knowing such 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?

Like many things in the legal world, in the world of digital contract formation, there’s similarly 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, as mentioned earlier, 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 process 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 there’s an additional system, custom or third-party, that maintainers must stand up and maintain, third-party or otherwise.

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 corporate 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 hobbiest, 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 its 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 at 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, 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, 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 sufficient 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.

The Software Freedom Conservancy gives the following advice: you (and your lawyers) need to distinguish between what “nice assurances we’d like to have ” and “what legal assurances our [open source] project actually needs to assure its 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. That said, 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, it might make sense.

Each organization’s sensitivity to legal risk is different, and if as you talk to your corporate counsel, they ask you to add a CLA, rather than blindly assuming 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 implications of minimizing it, before deciding what’s best, and to do so in a way that optimizes for the contributors’ experience, not the corporation’s.

Ultimately, 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.

Originally published January 2, 2018 | View revision history

If you enjoyed this post, you might also enjoy:

benbalter

Ben Balter is the Director of Engineering Operations and Culture at GitHub, the world’s largest software development platform. Previously, as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit