When an outside developer submits a patch to a project, the project needs a clear legal basis to use that code. Without one, every contribution is a small uncertainty: does the contributor actually have the right to give it, and on what terms may the project distribute it? Contributor agreements exist to answer those questions in writing, so that a project can build on community work without later disputes over who owns what.
The heavier instrument is the explicit Contributor License Agreement, or CLA. The Apache Software Foundation’s Individual CLA is a widely copied template. Under it, a contributor grants the Foundation a license to reproduce, modify, and distribute their contributions, and also grants a patent license covering any of the contributor’s patents that the contribution would otherwise infringe. Crucially, the Apache ICLA is a license grant rather than a copyright assignment: the contributor keeps ownership of their work but gives the project broad, irrevocable permission to use it. This lets the Foundation relicense and redistribute the combined project with confidence while leaving authors their copyrights.
The lighter-weight alternative is the Developer Certificate of Origin, or DCO, created for the Linux kernel after a lawsuit raised questions about the provenance of contributed code. The DCO, published at developercertificate.org as “Developer Certificate of Origin Version 1.1” and marked “Copyright (C) 2004, 2006 The Linux Foundation and its contributors,” is not a license grant at all. It is a statement a contributor affirms: that the contribution was created by them and they have the right to submit it under the project’s open source license, or that it derives from work they may lawfully pass on. The contributor signals agreement by adding a “Signed-off-by” line to each commit.
The two approaches embody a real tradeoff. A CLA gives a project, and especially a single corporate steward, the strongest position, including the ability to dual license or relicense the code, because it gathers broad rights into the project’s hands. That same strength is why some contributors distrust CLAs: signing one can hand a company the power to ship a proprietary edition of code the community wrote. The DCO asks far less, requiring only a per-commit attestation rather than a signed legal agreement, which lowers the barrier to contribution but gives the project fewer extra rights beyond the project’s own outbound license.
Which mechanism a project chooses signals a great deal about its governance. Foundation-stewarded projects and those that practice dual licensing tend toward explicit CLAs, while community kernels and many distributed projects favor the DCO’s low-friction sign-off. Either way, the contributor agreement is the quiet legal plumbing that turns a stream of patches from strangers into a redistributable whole.