When you propose a change to an open source project, sooner or later you are asked to agree to something: sign an online form, add a line to your commits, confirm a statement. It is not bureaucracy for its own sake. Every contribution is a work protected by copyright, and the project needs to know for certain that it can distribute it under its license. The two most common tools are the CLA and the DCO, and they have very different consequences.
The problem they solve
If the project accepts your code without any statement, its position rests on an implicit assumption: that you submitted the contribution under the project's own license (the principle often summed up as «inbound = outbound») and that you had the right to do so. In most cases this works. But doubts arise in concrete situations:
- the contributor was an employee and the code actually belongs to their employer;
- the code was copied from another project under an incompatible license;
- the project later wants to change license or offer a commercial one.
CLAs and the DCO address these risks in different ways.
The Developer Certificate of Origin
The DCO is a short statement, born in the Linux kernel community, in which the contributor certifies, among other things, that they wrote the code or have the right to submit it under the stated license, and that they understand the contribution and the sign-off will remain public.
In practice it is expressed as a line at the end of the commit message:
Fix working-day calculation across year boundaries
Signed-off-by: Mario Rossi <mario.rossi@example.org>
Git adds it automatically with the -s option:
git commit -s -m "Fix working-day calculation"
Features of the DCO:
- no transfer of rights: you keep the copyright and the contribution comes in under the project's license;
- no form to sign: the line in the commit is enough and can be checked automatically;
- symmetry: the project and its contributors are on equal footing, and nobody can relicense the code without the consent of all authors.
The Contributor License Agreement
A CLA is an actual contract between the contributor and an entity, usually the company or foundation running the project. There are two main variants:
- broad license: you keep the copyright but grant the entity a very wide license, often including patents, irrevocable and with the right to sublicense;
- copyright assignment: you transfer ownership of the code to the entity, which becomes its owner.
There are often two forms: an individual one and a corporate one, to be signed when you contribute as an employee on behalf of your company.
What it allows the owner to do:
- defend the code in court with clear ownership;
- change the license in the future without tracking down every contributor;
- offer the same code under commercial licenses, the so-called dual licensing.
It is this last point that breeds distrust: a CLA allowing unlimited sublicensing gives the owner the ability to make everyone's work proprietary.
Direct comparison
| Aspect | DCO | CLA with license | CLA with assignment |
|---|---|---|---|
| Who owns the code | The contributor | The contributor | The owner |
| Form to sign | No | Yes | Yes |
| Owner can relicense alone | No | Often yes | Yes |
| Friction for contributors | Low | Medium | High |
| Legal review for companies | Rarely | Often | Almost always |
What to check before signing a CLA
Reading a CLA takes a few minutes and is worth it. Useful questions:
- Are you granting a license or assigning rights? The difference is substantial.
- Does the owner commit to always distributing the code under an open source license? Some CLAs state this explicitly, which limits the risk.
- Are patents included? If you work for a company, you might be granting rights that are not yours.
- Are you allowed to sign? Many employment contracts assign to the employer code written even outside working hours. In that case you need the corporate CLA or permission.
Which to choose if you run a project
If the project is community-driven and you do not plan commercial licensing models, the DCO is almost always enough: it guards against contributions of dubious origin without discouraging anyone. An automatic check in the pipeline can reject pull requests without Signed-off-by.
A CLA makes sense when there is a concrete reason: a dual-licensing strategy, the need for single ownership to protect the project, or a foundation's requirements. In that case it is better to choose a well-known, publicly discussed text rather than writing one from scratch, and to state clearly in CONTRIBUTING.md why it is required.
In short
- Every contribution is a protected work: the project must know it can distribute it.
- The DCO is a statement in the commit, with no transfer of rights.
- A CLA is a contract that grants broad licenses or assigns copyright to the owner.
- A CLA may let the owner change the license: read it before signing.
- For most community projects the DCO is the simplest and fairest choice.
