CLA vs DCO: Who Owns the Code Strangers Contribute to My Project?
I open-sourced my SDK. Within a month, strangers were sending pull requests, and some of them were good. I merged them.
I never asked who actually owns that code, or what I am allowed to do with it. That question has been sitting there, unanswered, for every line a stranger wrote.
What Is a CLA?
A Contributor License Agreement (CLA) is an agreement between a project and anyone contributing code, granting the project the rights it needs to use that work. Without one, each contributor retains copyright in what they wrote and the project has only whatever license the contributor gave, which may be less than you need.
CLAs come in two shapes. An assignment CLA transfers copyright to the project. A license CLA, far more common, leaves the contributor as owner but grants a broad, irrevocable, sublicensable license to use, modify, and distribute the contribution, usually with a patent license alongside it.
What Is a DCO, and How Is It Different?
A Developer Certificate of Origin (DCO) is lighter. The contributor certifies, normally by adding a sign-off line to each commit, that they have the right to submit the code under the project’s license.
A DCO is easier to adopt and creates almost no friction. It also does less. It certifies origin rather than granting a broad license, which matters when you later want rights the inbound license did not give you.
When Does the Difference Actually Bite?
It bites on relicensing. If you want to change your project’s license, offer a commercial edition on different terms, or fold contributed code into a proprietary product, you need rights broad enough to do it. A permissive inbound license alone may not be enough.
There is a second question a CLA asks that a DCO handles differently: whether the contributor had authority to contribute at all. Most employment agreements assign work-related inventions to the employer. A contribution from an engineer at a large technology company may belong to that employer, and you will not be able to establish which without asking.
Adopting either is trivial at the start of a project and hard retroactively, because retroactive adoption means finding every past contributor. Response rates fall well short of 100%.
Common Mistakes Founders Make
- Adding a license file and assuming the legal work is done. Your outbound license tells the world what they may do with your code. It says nothing about what you may do with theirs. Inbound and outbound are separate questions.
- Waiting for a business reason to appear. Adopt before the first outside pull request, not before the first license change.
- Not asking whether the contributor has authority. A CLA asks the contributor to represent they have the right to make the grant, which puts the question to the person best placed to answer it.
A Quick Founder Check
- Do we have a public repository accepting outside contributions?
- Is a CLA or DCO enforced automatically as part of the pull request process?
- If we wanted to relicense next quarter, do we have the rights to do it?
- How many outside contributors do our projects have, and could we contact them?
- Does our CLA include a patent license or only a copyright license?
- Has contributed code made its way into anything we sell commercially?
- Do we have a written policy for what our own employees may contribute elsewhere?
The Bottom Line
A DCO is usually enough for a project that will stay open on its current terms. A CLA is what you need if a commercial edition, a relicense, or an acquisition is anywhere in the plan. The cost of choosing early is close to zero. The cost of choosing late is measured in engineering rewrites.
Schedule a free 30-minute call with our team to discuss your needs and concerns.
Book here: https://calendly.com/primumlaw/30min