The most powerful contributor agreement

LWN.net needs you!

Without subscribers, LWN would simply not exist. Please consider signing up for a subscription and helping to keep LWN publishing.

There are, he said, three important components to any contributor agreement: an assertion that the contributor has the right to contribute the code, a statement of actual contribution, and consent that the code may be distributed under the project's licenses. Not all contributor agreements have all three parts, James said, but they really should.

All projects should have some sort of contributor agreement. Outsiders looking at the free software world often see something that looks like a free-for-all, with code flying in all directions and little attention to legal details. But the potential for trouble is always there, and projects need to protect themselves. Every project, he said, should be able to prove that every line of code it distributes was intentionally contributed. A project can't just pick up patches off the street and hope that all will be well; if the code was not overtly contributed, the author could always try to revoke the project's right to the code, leading to trouble.

So, James said, every project needs a contributor agreement, but does that agreement need to take the form of a contributor license agreement? The agreements developed by Project Harmony did take this form, but if the project distributes code under the same license that covers incoming code, there is no need for a separate license agreement. Indeed, having contributor agreements be licenses can add a significant amount of complexity. A license must be signed, and it has to be carefully reviewed to be sure it does not conflict with the project's license. But, most importantly, any contributor agreement must preserve equity between all project participants, and complex agreements may not do that.

Equity is one of the fundamental principles of the free software community, he said; it is important that everybody meets on an equal basis. But, when company lawyers sit down to write a contributor agreement, they will naturally write that agreement to favor their employers; that is just part of what lawyers do. The result is inequity, and that destroys communities. This has been seen so often that many developers will now refuse to sign inequitable contributor agreements on principle. According to James, that is now happening with the Openstack project; many developers who have been told to work on Openstack by their employers have refused to sign the associated agreement. As a result, they are unable to contribute patches and are restricted to doing associated community work within the project.

Some companies will argue that a complex contributor agreement is necessary to give the project legal protection. But it is worthwhile to think about what a contributor agreement needs to protect a project from. One potential problem is revocation, where the owner of some code attempts to back out of a contribution or claim that the code was never contributed. Another threat is a bad actor trying to push problematic code into a project; a patent troll trying to get a project to distribute encumbered code that it could sue over later would be an example. There are also occasional problems when a good actor accidentally contributes bad code. The important thing to bear in mind, James said, is that a complex contributor agreement cannot protect a project from any of these threats. It might give the right to sue a bad actor, but, by then, the damage to the project has already been done.

The only real protection a project can have from these threats, he said, is not a license agreement with contributors. It is, instead, the ability to track code contributions and to remove bad code from the project once its nature is known.

There are other problems with license agreements. You have to keep them somewhere; the Free Software Foundation, for example, has a room full of file cabinets holding signed agreements. There has to be a mechanism for enforcing the contributor agreement rule; before accepting a patch, maintainers must be able to verify that an agreement has been signed. The need for a signed agreement makes contribution especially hard for "drive-by coders," who, James said, are the source of many interesting contributions to many projects. He cited some work he contributed to Android; he had one specific itch to scratch, contributed three patches, then moved on. That contribution would have been painful if he had needed to sign a real contributor license agreement; in many cases, developers just don't bother.

Finally, more complex agreements are more likely to run into a veto from corporate legal departments. And, James pointed out, for most of us who are employed, our employers own the code we write and must sign the agreement before we can contribute that code.

If a project needs a contributor agreement, but a complex contributor license agreement is not suitable, what should a project use? The key point of James's talk is that the kernel project found the correct answer to this question nearly ten years ago in the form of the developer's certificate of origin (DCO). It is a simple certification — the entire text fits (legibly) onto a single slide. The DCO, when combined with a strong source code management system and proper procedures, is all that is needed.

The DCO contains the three elements described by James at the beginning of the talk: the assertion of the right to contribute the code, the contribution itself, and the agreement to the project's license. Developers indicate their acceptance of the DCO with the Signed-off-by tag attached to every patch merged into the kernel. Every developer who handles a patch up to the point that it gets into the git system will attach a Signed-off-by tag, providing a clear trace of the path by which the patch got into the kernel. Should some code turn out to be problematic, it is trivial to find out which patch added it, determine who contributed it, and remove it from the kernel.

Agreement to the DCO is thus transmitted with each patch. There is no need for filing cabinets or complicated verification mechanisms. Patches can be left in bug trackers or transmitted by whatever means works, and the agreement travels with it. The DCO also, by design, does not specify a license; instead, patches are contributed under the license that applies to the file(s) being modified.

In short, James concluded, the DCO offers everything that a project needs for a contributor agreement. He has not yet seen any other agreement that comes close to the power of the DCO. A number of other projects have started using it, but James would clearly like to see that list grow. The more projects that use this agreement, the easier it will be for developers to contribute code to projects on an equal basis without the need for undue paperwork.

[ Your editor would like to thank the Linux Foundation for sponsoring his travel to the Collaboration Summit. ]