CLAs have benefits, but they can cause friction. At Man, we've found the drawbacks can be largely solved through standardised CLAs (or by not using one at all).
CLAs have benefits, but they can cause friction. At Man, we've found the drawbacks can be largely solved through standardised CLAs (or by not using one at all).
March 2022
TLDR
Contributor License Agreements (CLAs) are legal documents that define the relationship between open-source projects and their contributors. This is similar to licenses like the GPL, which define the relationship between open-source projects and their users. CLAs have some benefits, but they also increase friction for community contributions to an open-source project. At Man Group, we have found the drawbacks can be largely mitigated by employing standard CLA texts (or by choosing to not use one at all).
What is a CLA?
A CLA is a legal agreement between a project contributor and the project maintainers. It is similar to an open-source license, which is an agreement between the project and its users. While almost every open-source project uses an open-source license, only some projects have a CLA in place. Whilst there are a handful of popular open-source licenses (like GPL or BSD and MIT license), most CLAs are custom legal texts created for specific projects.
Why Man Group Cares About CLAs?
At Man Group, we have an “open-source first” policy (see a previous blog post on the subject here). As part of that, we make contributions to the upstream projects that we use in our tech stack. Over the last 10 years, Man Group technologists have made contributions to over one hundred open-source projects. We aim to make the process for contributing both bugfixes and new features to upstream projects as easy as possible. However, CLAs inevitably affect this process.
The Pros and Cons of CLAs
CLAs benefit open-source projects because they prevent potential headaches for maintainers: in most cases, contributors have to attest that they own the code that they are submitting and that they explicitly grant usage of their code to the project. Some CLAs also cover potential issues related to patents. The use of CLAs has been recommended by Karl Fogel in his seminal book “Producing open-source Software”, although future updates may re-evaluate their cost/benefit balance.
On the other hand, CLAs create a hurdle specifically for first-time contributors. One motivation behind open-source is involving a community and inviting others to contribute, but CLAs may counteract the intention of having an open-source project in the first place. This is discussed in-depth in this blog post by Ben Balter, which also highlights the additional administrative burden for project maintainers. The need for admin tools like EasyCLA by the Linux Foundation shows that the admin work is often non-trivial, requiring particular legal knowledge and specialisation.
The Practical Impact of CLAs
In practice, most individual contributors will either just agree to a CLA without further thought (similar to how most people click “Accept cookies” when visiting a website) or choose not to submit their contribution at all. When Man Group’s technologists contribute to an upstream project, the process for technical review and internal sign-off is designed to have a low hurdle. But when the upstream project employs a CLA, it is a legal text to be signed by an employee, and this requires approval by the legal team. The legal team then needs to work through the full license and clarify technical details with our technologists. This creates an additional, sometimes lengthy, step in the process that we would otherwise like to make as smooth as possible. The simplest case - obviously - is when a project does not employ a CLA at all. The alternative is to use a standard text, like Linux Foundation’s DCO, which is used for example by Kubernetes and other Cloud Native Computing Foundation projects. A standard CLA text can be handled like a standard open-source license (for example GPL), i.e., it is reviewed once by the legal team and when we contribute to the next project that uses this text, we can just go ahead with our contribution. It is important, however, to have clarity at first sight that an unmodified standard text is being used, in particular when the CLA is generated from templates like Canonical’s project harmony.
Use Standard CLAs Please. If at All.
If you have to employ a CLA in your open-source project, we believe it should be a standard text. In particular, it will make it easier for your project to receive community contributions from corporate contributors. CLAs can protect project maintainers from legal headaches, but it is important to ensure that the open-source process is as efficient as possible. We recommend to consider if they are necessary, and if they are, please use the DCO or a similar standard text, to keep the entry barrier low for first-time contributors.
You are now exiting our website
Please be aware that you are now exiting the Man Group website. Links to our social media pages are provided only as a reference and courtesy to our users. Man Group has no control over such pages, does not recommend or endorse any opinions or non-Man Group related information or content of such sites and makes no warranties as to their content. Man Group assumes no liability for non Man Group related information contained in social media pages. Please note that the social media sites may have different terms of use, privacy and/or security policy from Man Group.