A contributor license agreement, or CLA, is a contract between a person who contributes code to a software project and the project’s maintainer that spells out what the maintainer is allowed to do with that code. Without written permission from every contributor, a project has no clear legal right to distribute or modify the code it receives. Signing one usually means granting a broad, royalty-free license to your contribution; in some cases it means handing over ownership entirely. Before you click “I agree,” it’s worth knowing which one you’re signing and what else comes with it.
What Rights You Grant When You Sign
Source code is a copyrightable work under federal law, treated as a literary work because it’s expressed in symbolic notation.1Office of the Law Revision Counsel. 17 USC 101 – Definitions The moment you write original code, you hold exclusive rights to reproduce it, create derivative works from it, and distribute it.2Office of the Law Revision Counsel. 17 USC 106 – Exclusive Rights in Copyrighted Works A CLA moves those rights, or a license to use them, to the project.
The copyright license granted is typically perpetual, worldwide, non-exclusive, royalty-free, and irrevocable.3Open Web Foundation. OWF Contributor License Agreement 1.0 – Copyright and Patent The project can copy, modify, and redistribute your code without paying you or asking again.
Most CLAs also include a patent license. Making, using, selling, or importing a patented invention without authorization is infringement under federal patent law.4Office of the Law Revision Counsel. 35 USC 271 – Infringement of Patent If your contribution implements a technique covered by a patent you hold, the patent grant prevents you from later suing the project or its users. The Apache Individual CLA limits this grant to patent claims “necessarily infringed” by the contribution itself and includes a defensive termination clause: if anyone sues alleging that a contribution constitutes patent infringement, the patent license to that party terminates immediately.5The Apache Software Foundation. Individual Contributor License Agreement V2.2
Sublicensing
Watch for language giving the project the right to sublicense your contribution. Sublicensing is what lets a project distribute the whole codebase under its open-source license and pass rights down to every user. The Apache ICLA explicitly includes the right to sublicense and distribute contributions and derivative works.5The Apache Software Foundation. Individual Contributor License Agreement V2.2 Without it, the project would need to come back to you every time it changed licenses or opened a new distribution channel.
What a CLA Does Not Grant
A CLA almost never grants trademark rights. The W3C’s Community CLA states this explicitly: no trademark, patent, copyright, or other property rights beyond those specifically described in the agreement are granted, whether by implication or otherwise.6World Wide Web Consortium. W3C Community Contributor License Agreement Signing does not let you use the project’s name or logo, and it does not let the project use your name for endorsement. A CLA that does include trademark grants is unusual and worth a careful read before signing.
License Grant Versus Copyright Assignment
This is the distinction contributors overlook most often, and it has real consequences for your ownership. Two models are common, and they are not the same.
A license-grant CLA lets the project use your code while you keep ownership. The Apache ICLA states this plainly: “You reserve all right, title, and interest in and to Your Contributions” except for the license granted.5The Apache Software Foundation. Individual Contributor License Agreement V2.2 Because the grant is non-exclusive, you can still use, license, or sell the same code elsewhere. Most major foundations use this model.
A copyright-assignment CLA transfers ownership of your code to the project. The Free Software Foundation uses this approach, requiring each author to assign copyright in their contributions to the FSF.7GNU Project. Why the FSF Gets Copyright Assignments From Contributors The rationale is enforcement: only the copyright holder can effectively sue someone who violates the license, and coordinating enforcement across thousands of individual owners is impractical. After assignment, you no longer own the code and cannot independently license it to anyone else.
The Harmony Agreements project publishes standardized templates for both models.8Harmony Agreements. Overview Before signing, read whether the document says “grant” or “assign.” Assignment language means you’re giving up ownership, not just permission to use.
Are You the Right Person to Sign?
Who signs depends on who actually owns the code. That’s less obvious than it sounds, particularly if you write code for a living.
If You Wrote the Code at Work
Under the work-for-hire doctrine, when an employee creates a copyrightable work within the scope of employment, the employer is treated as the author and owns all rights unless the parties have agreed otherwise in writing.9Office of the Law Revision Counsel. 17 USC 201 – Ownership of Copyright If you write code at work and your employer hasn’t given you explicit permission to contribute it, your individual signature on a CLA is legally meaningless: you don’t own what you’re trying to license, and the project ends up with a grant from someone who had no authority to make it.
Code you write on your own time can still fall under employer ownership if your employment agreement includes a broad intellectual property assignment clause. Many tech employment contracts claim anything created using company resources or related to the company’s business. Figuring out whether your employer owns a particular contribution is on you, not the project.
Corporate CLAs
When contributions are owned by an employer, the company itself must execute a Corporate CLA (CCLA). Apache’s CCLA covers intellectual property assigned to the corporation as part of employment, but it also requires every developer to sign an individual CLA, because some contributions may fall outside what the corporation owns.10The Apache Software Foundation. ASF Contributor Agreements
A CCLA binds the company, so the person signing has to have authority to enter contracts on the company’s behalf. That usually means the CEO, a vice president, general counsel, or a director of engineering or technology. A software engineer or product manager acting on their own almost certainly lacks that authority, and a CCLA signed by the wrong person may not hold up. Google’s CLA policy warns companies to be wary of individual developers and engineers attempting to sign corporate agreements without organizational authorization.11Google Open Source. Alphabet CLA Policy and Rationale If your employer has an open-source program office or legal team that reviews contributions, route the paperwork through them before signing anything yourself.
What You Are Promising About the Code
A CLA doesn’t only grant rights. It contains representations: statements you’re making about where the code came from and your authority to license it. These create the audit trail the project relies on to show it received code legitimately.
The Apache ICLA, for example, requires you to represent that each submission is your original work and that you have the legal authority to make the grant. If it later turns out you contributed code you copied from a proprietary codebase or from another open-source project under an incompatible license, the project faces a potential infringement claim, and your representation becomes the basis for your personal liability. Vague descriptions of what you’re contributing, or casual inclusion of third-party code, can undermine the entire agreement.
On the other side, nearly every CLA provides the code on an “as is” basis, with no promises about whether it works, is free of bugs, or is fit for any particular purpose. If your contribution causes a production outage after it’s merged, that disclaimer means you haven’t promised it wouldn’t.
Can You Take It Back?
In practical terms, no. CLAs are typically described as irrevocable, and they function that way. Once you sign and your code is merged, you cannot demand it be removed. The project’s right to use, modify, and distribute your contribution continues even if you later fall out with the maintainers.
There is one obscure wrinkle in federal copyright law. Under 17 U.S.C. ยง 203, an author can terminate a grant of copyright during a five-year window that opens 35 years after the grant was made, and the statute says this right takes effect “notwithstanding any agreement to the contrary.”12Office of the Law Revision Counsel. 17 USC 203 – Termination of Transfers and Licenses Granted by the Author Contractual irrevocability language cannot override it. In theory, a contributor or their heirs could terminate the copyright license decades later, with unclear effects on derivative works. No one has tested this against a CLA in court, and the open-source community has operated as if irrevocability holds. Projects from the late 1990s are now approaching the 35-year window.
When a Project Uses a DCO Instead
Not every project uses a CLA. A common alternative is the Developer Certificate of Origin (DCO), a lightweight mechanism asking contributors to certify, with each commit, that they have the right to submit the code and are licensing it under the project’s existing open-source license.13Developer Certificate of Origin. Developer Certificate of Origin Instead of signing a separate legal document, you add a “Signed-off-by” line to your commit message.
The tradeoff is formality versus friction. A CLA is a binding contract with explicit license grants, patent provisions, and representations; it creates a clear legal record but requires signing before your first pull request is accepted, separate corporate agreements, and someone to verify signatures. A DCO is easier to implement and less intimidating for new contributors, but if it turns out a developer didn’t actually have the right to contribute, the project faces a harder cleanup because there’s no contractual license grant to fall back on. The Linux kernel uses a DCO. Apache, Google, and many other foundations use CLAs. Projects handling code from corporate employees tend to favor CLAs because the formal chain of title matters more when employers could later claim ownership.
How Signing Actually Works
The mechanics have gotten much simpler. Most contributors never print, sign, or mail anything.
Automated tools integrate directly with version control platforms. CLA Assistant monitors pull requests on GitHub, comments on any pull request from a contributor who hasn’t signed, and lets you agree to the CLA from the pull request page using your GitHub account.14GitHub. CLA Assistant EasyCLA works similarly with GitHub, GitLab, and Gerrit, checking each pull request or merge request against a list of authorized contributors.15Linux Foundation Documentation. EasyCLA Development Components If your name isn’t on the list, your code doesn’t merge until you sign.
When a project uses a manual signing process instead, electronic signatures are legally valid. Federal law prohibits denying a contract legal effect solely because it was signed electronically.16Office of the Law Revision Counsel. 15 USC 7001 – General Rule of Validity Signing through DocuSign, Adobe Sign, or a platform that captures your typed name and IP address can produce a binding agreement, as long as you intended to sign.
Whatever the method, use your full legal name and the email tied to your development account. When a form asks about the scope of your contribution, reference specific pull requests or commits rather than writing vague descriptions. Gaps here can surface years later when no one remembers the details, and the project may not be able to prove it has the rights it thought it did.