Before a line of code lands in a serious open source project, someone may ask you to sign something. The contributor agreement is the least glamorous document in the binder and one of the most consequential: it is the clause that decides, at the moment of contribution, who owns what you just wrote and what the project may do with it later.

Two families of instruments live here. The Contributor License Agreement keeps copyright with the contributor but grants the project a broad license to the work. The copyright assignment goes further and hands ownership over. Between and beneath them sits the Developer Certificate of Origin, a lighter mechanism that asks only for an attestation.

What a CLA actually asks

A CLA asks the contributor to confirm two things: that they have the right to contribute the code, and that they grant the project a license to use it. Most CLAs are written to be generous to the project: the grant is perpetual, irrevocable, and often broad enough to let the project relicense the contribution later. The contributor keeps their copyright but gives the project the freedom it needs to defend, distribute, and sometimes commercialize the work.

The Apache Software Foundation uses a CLA for exactly this reason: it gives the foundation a clean legal position without taking ownership away from the people who wrote the code. Google's projects ask for a similar grant, and the CLA has become the standard instrument wherever a company or a foundation wants a tidy chain of title without holding every copyright itself.

The assignment that goes further

The Free Software Foundation asks for more. Contributors to GNU projects sign a copyright assignment that transfers ownership of the contribution to the foundation itself. The reasoning is enforcement: a single owner can sue to defend the GPL, and can relicense the work as the license evolves. The trade-off is real. The contributor gives up the ability to decide what happens to their code, trusting the institution to steward it.

The assignment model is the strongest form of the instrument, and it concentrates both the power and the responsibility in the holder. The FSF's version is unusual in that the holder is a nonprofit chartered to defend the commons, which is what makes the concentration defensible.

The DCO and the signature that stays light

The Developer Certificate of Origin, adopted by the Linux kernel in 2004, is the minimalist answer. Instead of a contract, the contributor adds a signed-off-by line to each commit, attesting that they wrote the code or have the right to submit it under the project's license. No ownership moves, no broad grant is signed. The DCO exists because the kernel grew too fast for paperwork, and it works because it preserves exactly the information a court would later need.

The three instruments sit on a spectrum of how much the contributor hands over: an attestation, a broad license, a full assignment. The project chooses where on that spectrum it needs to stand, and the choice says something about how the project expects to be used and defended.

Why projects insist at all

The paperwork exists to answer one question cleanly: is the project's legal chain of title intact? A project that accepts patches from strangers without any attestation cannot prove, years later, that the code it distributes is properly licensed. The signature, whether a CLA, an assignment, or a sign-off line, is the project's evidence that every line arrived with permission.

The controversy that never fully settles

The signature is also where the reader's and the writer's interests diverge for the first time. A reader wants the project's license to be open and stable; a contributor wants their work to stay inside the project under terms they recognize. The agreement is where those two wants meet, and the project that handles it honestly is the one that tells the contributor plainly what they are signing.

Contributor agreements carry a standing objection: they are asymmetric. The contributor signs under open terms, but the project, especially a corporate one, may reserve the right to use the contribution in ways the contributor did not expect, including relicensing it commercially. The dual licensing model depends on exactly this asymmetry. Projects that keep a CLA and use it honestly publish their reasoning; the ones that lose trust are the ones that discover the asymmetry only when it is exercised.

Reading the signature line

For the binder, the contributor agreement is where the licensing argument becomes personal. The license governs the reader of the code; the agreement governs the writer of it. The two instruments together decide who truly controls a commons. A reader of an open project should know which one the project asks for before they sign, because the signature is the moment the bargain is struck.

The agreement is the binder's reminder that the commons has a door, and that the door has a terms sheet. Read it before you sign, the way you would read the license before you ship, because the two instruments are the same bargain seen from opposite sides.

What the text grants

A license or assignment of the contribution to the project, or a simple attestation that the contributor had the right to send it.

What a reader should check

Whether the instrument is a CLA, an assignment, or a DCO, and what rights it reserves to the project over the work.

The limit of this reading

The binder maps what the signature does; whether a given agreement is fair is a judgment the signer must make.