Contributor License Agreements (CLA)

CLAs exist to give maintainers legal clarity about the rights they receive to contributions — enabling them to relicense, enforce patents, and offer commercial licenses.

Why projects need CLAs:
• Without a CLA: maintainer has an implied license to the contribution, but unclear scope
• With a CLA: maintainer has explicit, documented rights to the contribution

What a typical CLA grants:
• A broad license to use, reproduce, modify, and distribute the contribution
• A patent license for any patents the contributor holds that are embodied in the contribution
• Permission to sublicense (grant the same rights to others)
• Sometimes: the right to relicense the code under a different license

CLA vs. copyright assignment:
• CLA: contributor retains copyright, grants a broad license to the project
• Copyright assignment CLA: contributor transfers copyright ownership to the project
• Apache Foundation uses CLAs (retain copyright); some projects require full assignment

Developer Certificate of Origin (DCO) — a lighter alternative:
• Used by Linux kernel, Git, and many projects
• Contributor signs off each commit with Signed-off-by:
• Certifies they have the right to contribute, but grants a minimal license
• No separate agreement needed — just a commit trailer

Key vocabulary:
• CLA (Contributor License Agreement) — a legal agreement defining the rights a contributor grants to a project
• Copyright assignment — a CLA type where the contributor transfers copyright ownership
• DCO (Developer Certificate of Origin) — a lightweight alternative to CLAs, affirmed per commit
• Patent license — permission to use any patents the contributor holds that cover the contribution

The Apache ICLA is the standard CLA for individual contributors to ASF projects — it grants ASF broad rights without requiring copyright transfer.

Apache ICLA key terms:
• You grant ASF a perpetual, worldwide, non-exclusive, royalty-free license to reproduce, modify, prepare derivative works, distribute, and sublicense your contribution
• You grant ASF a patent license for any patents you hold that are infringed by your contribution
• You represent that you are legally able to grant these rights (you own the copyright)
• Your copyright remains with you — ASF is not the copyright holder

CCLA — Corporate CLA:
• Used when a contributor is employed and their employer owns the copyright to their work
• The employer (not the individual) signs the CCLA
• The employee's name is added to a "Schedule A" authorised list
• Required by: many employers who want a record that contributions are authorised

"Inbound = outbound" principle (an alternative):
• Some projects use the rule: "your contribution is licensed under the same license as the project"
• No separate CLA needed — submission of a PR implies consent
• Used by: Node.js, many GitHub projects

Key vocabulary:
• ICLA — Individual Contributor License Agreement; for individual developers
• CCLA — Corporate Contributor License Agreement; signed by employers when copyright belongs to the company
• Non-exclusive license — grants rights to the project without taking those rights away from the contributor
• Perpetual license — a license that does not expire
• Schedule A — the list of authorised employees attached to a CCLA

DCO is a "did you have the right to contribute" certification per commit; CLA is a comprehensive legal contract granting specific rights to the project.

DCO in practice:
• Developer adds Signed-off-by: Jane Smith <jane@example.com> to each commit
• Certifies: (a) I wrote this code, or (b) I have permission to contribute it under its license
• References: developercertificate.org — a simple 4-point statement
• No separate document, no legal signature required
• What it grants: an implicit license under the project's license (typically via "inbound=outbound")

What DCO does NOT provide (that CLA does):
• Explicit patent license from contributors
• Right to sublicense to third parties
• Right to relicense the contribution
• Warranty that the contributor's employer doesn't own the copyright

When to prefer CLA:
• Project offers commercial licenses (dual licensing)
• Project needs to relicense in the future
• Patent grants are legally important
• Enterprise contributors whose employers own their work

When DCO is sufficient:
• Pure open source project without commercial licensing
• Community-driven projects that prioritise low friction for contributors
• Projects using "inbound = outbound" (MIT, Apache 2.0)

Key vocabulary:
• Signed-off-by trailer — a Git commit trailer line certifying DCO compliance: Signed-off-by: Name <email>
• DCO (Developer Certificate of Origin) — a per-commit certification that the contributor has the right to submit the code
• Inbound = outbound — the principle that contributions are automatically licensed under the project's outbound license
• Implicit license — a license grant inferred from context rather than a signed agreement

If your employment contract assigns ownership of work-related software to your employer, your employer must authorise your OSS contributions via CCLA — submitting under a personal email doesn't change the copyright.

The employment copyright issue:
• In many jurisdictions, software written by an employee using employer resources (company laptop, work hours) is a "work for hire" — the employer owns the copyright
• This applies even if you use a personal email or contribute outside work hours if the work relates to your job
• Submitting without authorisation could expose both you and the project to legal risk

The correct process:
1. Check your employment contract — look for "IP assignment" or "inventions assignment" clauses
2. Talk to your employer's legal team: "I want to contribute to Project X — can we add my name to their CCLA?"
3. Employer adds your name to Schedule A of the existing CCLA
4. Or: employer signs the CCLA for the first time and adds you
5. Now you're authorised to contribute

What many companies have:
• Blanket CCLA with major foundations (Apache, CNCF, Linux Foundation)
• Internal policy listing approved projects for employee contributions
• IP exception clauses: "contributions unrelated to your employment are exempt"

Key vocabulary:
• CCLA (Corporate CLA) — a CLA signed by an employer, authorising their employees to contribute
• Schedule A — the list of authorised employees attached to a CCLA
• Work for hire — a legal doctrine where the employer owns copyright in work created by an employee within the scope of employment
• IP assignment clause — an employment contract provision assigning ownership of employee inventions to the employer

The phrase "all right, title, and interest" is the legal language for a full transfer of ownership — this is copyright assignment, not a license grant.

License grant vs. copyright assignment — the key difference:
• License grant CLA: "You grant us permission to use your code" — you keep copyright ownership
• Copyright assignment: "You transfer ownership to us" — they own your contribution outright

Implications of copyright assignment:
• You can no longer independently license your contribution to others
• You cannot enforce copyright in your contribution (e.g., sue for infringement)
• The assignee can use the code in any way, including proprietary products, relicensing, selling
• Without a "license back" clause, you may not even be able to use your own contribution in other projects

When it's used:
• Projects that want to offer commercial licenses need clear ownership
• FSF (Free Software Foundation) requires copyright assignment for GNU projects
• Some companies (Sun/Oracle for MySQL) required assignment to enable their dual-licensing model

What to look for in a CLA before signing:
• Does it say "license" or "assign/transfer"? Assignment is permanent and complete
• Is there a "license back"? Do they grant back rights to you to use your own contribution?
• Is the patent license exclusive or non-exclusive? Non-exclusive is safer for contributors

Key vocabulary:
• Copyright assignment — permanent transfer of copyright ownership to another party
• "All right, title, and interest" — legal phrase indicating complete transfer of ownership
• License back — a provision in an assignment CLA granting the contributor rights to use their own contribution
• License grant CLA — a CLA where the contributor retains copyright but grants specific usage rights

Liam's message focuses on the CLA because `AwesomeLib` likely has a license that requires contributions to be covered by a CLA. This protects both the project and the contributor, ensuring proper attribution and rights management. The other options relate to unrelated issues – documentation, debugging, or library choice.

Sarah is asking David to comply with the CCLA requirement. This involves obtaining formal approval from his employer, which is crucial for verifying that the contributor has the legal authority to contribute under the project's license terms. Ignoring the message or deleting the PR would not resolve the underlying issue.

Ben is referring to the formal process of obtaining approval from his employer regarding his contribution. This ensures that his company recognizes and authorizes his participation in the open-source project, which is necessary under most CLA agreements. The other options represent different levels of management or compensation.

The key phrase 'maintain compliance with their licensing terms' highlights the purpose of the CCLA – to protect the project's license. A CLA establishes accountability and ensures that contributions are properly tracked and managed, mitigating potential legal risks. Options A and D reflect a misunderstanding of the CCLA's role.

The core purpose of a CLA is to manage IP rights. By requiring contributors to sign one, the project can ensure that they have the legal right to contribute code and that any intellectual property generated by that contribution belongs to the project maintainers – this is what's being directly addressed here.