Contribution Agreements: Certification, License Grants, and Assignment

A project’s outbound license is only as strong as the grants it holds from the people who wrote the code. Copyright in a repository is normally distributed across many holders, each of whom owns the portions they authored, and each of whom must separately permit the distribution the project performs. A contribution pasted into an issue tracker or attached to a mailing-list message arrives with no express grant at all, and the project’s basis for redistributing it rests on nothing more than the inference that the sender intended it to be used. Inference is a poor foundation for a distribution obligation that runs for years.

The remedy is an inbound mechanism: a standing statement from contributors about the rights they are giving the project. Three mechanisms have settled into wide use, and they differ less in what they permit day to day than in what they allow the project to do later.

The certification mechanism and the sign-off trailer

The Developer Certificate of Origin is a short text a contributor asserts per contribution rather than signing once. It certifies that the contribution was created by the contributor, or is based on previous work covered by the project’s license and is being submitted with the contributor’s own modifications under that same license; that the contributor has the right to submit it; that the record of the contribution and its authorship may be redistributed; and that the contributor understands the submission is public and the certification is recorded. Nothing is transferred. The contributor keeps copyright and grants, implicitly, the same license the project already carries, which is the convention known as inbound matching outbound.

The mechanical implementation is a trailer in the commit message. git commit -s appends a line of the form Signed-off-by: Name <email>, and git am preserves it when a patch travels by mail, so the certification is attached to the exact change it covers and the chain of authorship is legible from the log.

git commit -s -m "ring: fix off-by-one in wrap check"    # appends Signed-off-by
git log -1 --format='%b' | grep '^Signed-off-by:'         # the recorded assertion
git shortlog -sne                                        # who would have to be asked

That last command is worth remembering, because the set of people it prints is exactly the set whose permission a license change would require. Certification is cheap, requires no legal review, and leaves that set as large as it has always been.

The license grant, and what it adds

A contributor license agreement keeps copyright with the contributor and takes a standing grant from them instead: a perpetual, irrevocable license to reproduce, modify and distribute the contribution, a patent license covering the contributor’s claims that the contribution infringes, and representations that the contributor is entitled to grant those rights. Because the grant is broad and standing, it usually covers all of a contributor’s present and future contributions rather than one patch, and the common form is signed once.

The added value over certification is twofold. A project that holds a broad grant can defend the project’s license against a redistributor without tracking down every author of the affected code, and a steward that holds a grant wide enough to permit relicensing can change the project’s license without a fresh round of consent from hundreds of people. Both capabilities are exactly what a certification-only project lacks, since there it is the contributors, individually, who hold the rights the enforcement claim depends on.

The mechanism has an acknowledged cost. A broad standing grant of the right to distribute under any terms is the same instrument that would allow a project to be moved to a proprietary license, and the clause that makes a project administratively flexible is indistinguishable in its wording from the clause that makes contributors nervous.

The employer is the hidden variable in both mechanisms. Work produced within the scope of employment generally belongs to the employer rather than the employee, so an individual signature can be insufficient: the employer holds the rights that matter. Corporate agreements cover contributions made by a company’s staff, and the corporate form usually requires the company to name the employees authorized to submit and to confirm that the corporate grant supersedes the individual one. The same issue appears with university employees, contractors whose contracts assign their work product, and contributors whose employment changed while they were contributing.

Assignment, and why a steward would ask for it

Assignment transfers copyright outright. The contributor ends up owning nothing, and in return the receiving organisation normally grants the contributor a license back to use the assigned work as they wish. The Free Software Foundation’s practice for GNU packages is the historical case, and its published rationale is that a single holder of title, rather than a few thousand scattered holders, is what makes a license enforceable and what makes it possible to move the project to a later version of its license when the license itself changes.

The trade-off is the mirror image of certification. Assignment gives a project everything certification withholds, at the cost of the heaviest possible process: paperwork per contributor, resistance from contributors who prefer to retain title, and a concentration of control that makes the receiving organisation a single point of failure for the whole codebase. The intermediate design, used by standards bodies for their documents and code, is a license grant rather than assignment; the IETF’s contribution terms, defined in RFC 5378, take a grant to a trust rather than a transfer, so that documents can be republished and reused while authors retain their rights.

Mechanism	Contributor keeps copyright	Can the steward relicense alone	Enforcement by a single party
Certification (DCO)	yes	no	no, contributors must act
License grant (CLA)	yes	only if the grant is wide enough	yes
Assignment	no	yes	yes

What the record can prove later

The two mechanisms leave different trails, and the trail is what a project uses years afterwards. A certification lives in the commit history, attached to the change it covers, so a query for the trailer over the whole log produces the list of people who asserted the right to submit their contributions, together with the changes each assertion covers. Nothing else is needed to reconstruct the state, which is why the convention spread with the tooling that preserves it: a patch transported by mail carries its trailer, and a merge that squashes commits has to be careful not to discard it.

A signed agreement leaves a list instead, held by the organisation that administers it, covering contributors and their employers. The list is smaller and easier to query by identity, but it is a record of documents rather than of code, so it answers the question of who granted what without answering the question of which file each grant covers. Both approaches therefore converge on the same second-order problem: a project that needs to know the rights attached to a specific file must combine the authorship record with the agreement record, which is the reconciliation step that makes an audit tedious rather than difficult.

The trail also determines how quickly an ambiguity can be resolved when it appears. A contribution whose trailer names a commit address that no longer routes anywhere is at least attributable; a contribution accepted from a discussion thread with no trailer at all is attributable only by inference, and the inference is not something a distributor can rely on for an obligation that runs for the length of copyright.

Failure modes that show up years later

The first is the uncertified contribution. A patch that arrives through a bug tracker, a paste in a chat channel, or a suggestion adopted verbatim has no trailer and no signature, and adding it to the tree creates a component whose grant is inferred rather than stated. The second is the contributor who could not grant the rights: a contributor submitting their employer’s code under a personal email, or a patch that is itself derived from code under an incompatible license, discussed in license compatibility.

The third is revision of the inbound terms. A project that adopts a stricter agreement, or that improves its certification language, cannot apply the new terms retroactively to contributions already made under the old ones, because the old grant is perpetual and the older certification stands as written. The practical consequence is that the terms governing any given file are a function of when it landed, which is why provenance systems keep records per file and per commit rather than one project-wide statement, as covered under license expressions.

The final failure is discovering the gap at the worst moment, when a license change or an enforcement action needs consent from every rightsholder. Consent outreach means finding contributors whose email addresses have expired, whose employers have dissolved, or whose contributions were made under a handle with no real name attached to it. The cost of that search is the most persuasive argument made for both assignment and broad grants, and the reason the choice between the three mechanisms is decided by a project’s expected need to relicense, which is the subject of relicensing a mature project, rather than by any difference in how code is contributed.