CLA vs. DCO: What's the difference?

Both show that a contributor is allowed to make a contribution and that the project has the right to distribute it. But which one is better?
310 readers like this.
A diagram of a branching process

In your open source adventures, you may have heard the acronyms CLA and DCO, and you may have said "LOL WTF BBQ?!?" These letters stand for Contributor License Agreement and Developer Certificate of Origin, respectively. Both have a similar intent: To say that the contributor is allowed to make the contribution and that the project has the right to distribute it under its license. With some significant projects moving from CLAs to DCOs (like Chef in late 2016 and GitLab in late 2017), the matter has received more attention lately.

So what are they? The Contributor License Agreement is the older of the two mechanisms and is often used by projects with large institutional backing (either corporate or nonprofit). Unlike software licenses, CLAs are not standardized. CLAs can vary from project to project. In some cases, they simply assert that you're submitting work that you're authorized to submit, and you permit the project to use it. Other CLAs (for example the Apache Software Foundation's) may grant copyright and/or patent licenses.

The Developer Certificate of Origin was introduced by the Linux Foundation in 2004. Instead of a legal contract that must be submitted to the project, it's a lightweight mechanism to say, "Yes, I have the right to submit this, and I understand that you will use it." Using it merely requires the contributor to sign the git commit. Advocates for this approach cite the lower barrier to entry as the main feature of the DCO. It does not require a contributor to read and understand a lengthier legal document.

Advocates for CLAs say that the presence of a CLA shows that the project is being governed with long-term stability in mind. If nothing else, it implies that it is well-resourced enough to have a lawyer draft the CLA and to have someone responsible for making sure that CLAs are on file for all contributors. CLAs may also give the project the right to relicense the work later. This can be a benefit if the current license is found to be inadequate and you can't contact the hundreds of people who have contributed over the years. Of course, it's also a risk that, at some point in the future, a project would take a direction that the contributors find unacceptable.

So which should you use? As with many questions (licenses, text editors, etc.), the answer is "it depends." If you're a juicy target for litigation and you want some cover, a CLA might be the right approach. If you want to minimize the barriers for contribution while still requiring your contributors to pinky swear that they're submitting their own work, then look at using a DCO. The important thing is to consider the needs of your project and your community, then decide accordingly.

User profile image.
Ben Cotton is a meteorologist by training, but weather makes a great hobby. Ben works as the Fedora Program Manager at Red Hat. He is the author of Program Management for Open Source Projects. Find him on Twitter (@FunnelFiasco) or at

Comments are closed.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.