User: Password:
Subscribe / Log in / New account

The most powerful contributor agreement

This article brought to you by LWN subscribers

Subscribers to made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.

By Jonathan Corbet
April 2, 2014
Collaboration Summit
James Bottomley is perhaps best known as the maintainer of the SCSI subsystem in the kernel. But, he said in his 2014 Linux Foundation Collaboration Summit talk, like most free software developers he tends to run across licensing issues frequently. Developers often respond by becoming armchair lawyers, and, by his own admission, James is no exception: armchair lawyering on the topic of contributor agreements was just what he was offering to his audience — though the presence of Linux Foundation attorney Karen Copenhaver, who is well versed in these topics, in the first row of the audience presumably served to keep him from going too far off track.

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 [James Bottomley] 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. ]

(Log in to post comments)

The most powerful contributor agreement

Posted Apr 2, 2014 20:40 UTC (Wed) by jhoblitt (subscriber, #77733) [Link]

Has the DCO ever come up / been tested in a legal action?

wrong question (maybe?)

Posted Apr 2, 2014 22:08 UTC (Wed) by louie (subscriber, #3285) [Link]

The assumption behind DCO (as explained by James in his talk, which I attended) is that the cases where a CLA protect you in a legal action are extremely rare. The more common case is not "the CLA protects you from legal liability" but rather "the CLA helps you figure out whose code to remove to clean up the mess afterwards".

So he'd say that the correct question is not "has it been tested in a legal action" but rather "if a legal action happened, would it reliably allow identification and removal of problematic code"?

As I said in the talk, I'm not 100% sure this is the right perspective/question to ask, but it is at least plausible and an interesting question to ask of CLA proponents.

wrong question (maybe?)

Posted Apr 3, 2014 1:41 UTC (Thu) by neilbrown (subscriber, #359) [Link]

I see an important part of the DCO as providing plausible deniability.

If a legal question is raised over some code, we can identify who submitted it, point at the s-o-b, and say "we had good reason to believe we had been given the right to use this code".

There is always the chance that the s-o-b was faked, but if we can show a history of practice of requesting s-o-b when it isn't given, that improves our plausible deniability.

ambiguous, but amusing

Posted Apr 3, 2014 1:45 UTC (Thu) by jake (editor, #205) [Link]

> point at the s-o-b

there's another definition for that, which makes this rather amusing :)

thanks for the chuckle, Neil ...


wrong question (maybe?)

Posted Apr 3, 2014 13:25 UTC (Thu) by fuhchee (guest, #40059) [Link]

"I see an important part of the DCO as providing plausible deniability."

That may be the only part. LKML doesn't have anything to legally identify the author, nor anything even as deep as a click-through to make it likely that the author even read/understood the DCO text (instead of cargo-culting the s-o-b line).

wrong question (maybe?)

Posted Apr 3, 2014 13:23 UTC (Thu) by dberlin (subscriber, #24694) [Link]

Linux relies on a lot of other things to protect patent rights (OIN, for example).

Most projects do not have this luxury. The argument that a CLA doesn't protect you in these cases, is, well, wrong-headed. I know personally of many cases where it has protected my company from lawsuits for open source projects due to the patent grant.

The truth is the number of projects that live in a world where all you get asked to do is "remove the offending code" is pretty small.

So i'm sure this works for Linux, but the idea that it would work outside of this bubble, and work well, without fully understanding the world in which we live, seems very dangerous to me.

When i've watched these presentations, it seems mostly based on naked assertions of risk or experiences in linux related situations, which, as I explained, are a very different world.

Sadly, i'm pretty sure it will take a real lawsuit, in public, against a DCO project, before some folks realize this.

wrong question (maybe?)

Posted Apr 3, 2014 15:49 UTC (Thu) by louie (subscriber, #3285) [Link]

"The argument that a CLA doesn't protect you in these cases, is, well, wrong-headed. I know personally of many cases where it has protected my company from lawsuits for open source projects due to the patent grant."

It obviously only works for patents if/when the inbound/outbound license contains a patent grant. (Insert argument here about whether MIT/BSD/GPLv2 qualify as such a license.) Assuming that to be the case, it isn't clear that DCO+$LICENSE_WITH_PATENT_CLAUSE is substantially weaker than a CLA for patent issues, though I might have worded plank #1 slightly differently to more clearly capture that.

wrong question (maybe?)

Posted Apr 3, 2014 15:51 UTC (Thu) by louie (subscriber, #3285) [Link]

I should also add that, during the talk, I commented that I thought the situation was very different for CCLAs and ICLAs. CCLAs are much more defensible even if you take DCO's premises for granted - not just for the patent reasons you mention, but also because they are not judgment-proof in the way individual contributors typically are.

wrong question (maybe?)

Posted Apr 3, 2014 18:33 UTC (Thu) by bkuhn (subscriber, #58642) [Link]

Danny, this isn't an argument for CLAs, rather, it's an argument for strong patent grants in the licenses. inbound=outbound should be all a Free Software projects needs. If it's not, then there's something wrong with the license of the code itself. Shoehorning additional legal agreements on top is a mistake. Fix the license of the project if it needs fixing, but shoehorning additional agreements on top is a mistake.

wrong question (maybe?)

Posted Apr 3, 2014 18:54 UTC (Thu) by dlang (subscriber, #313) [Link]

> The truth is the number of projects that live in a world where all you get asked to do is "remove the offending code" is pretty small.

that's not the argument.

The argument is that having an agreement doesn't prevent those other cases.

Even if you have a patent license, that doesn't make it so someone can't sue you over the patent, just that you have reason to believe that you can dismiss the lawsuit.

Remember the 3 requirements

1. Asserting the the contributor has the right to contribute the code

2. Asserting that the code is being contributed.

3. Consent that the code can be distributed under the project license.

While it is possible to claim that this doesn't give you the right to actually run the code, that seems like quite a stretch. I don't see how anyone signing this would have reasonable grounds to sue over patents or anything else.

What does it mean "to remove"?

Posted Apr 3, 2014 13:34 UTC (Thu) by gioele (subscriber, #61675) [Link]

> "the CLA helps you figure out whose code to remove to clean up the mess afterwards".

Tangentially related, I always wondered how many things must be "removed" in those "messy" cases.

If some "unlawful" code is found in a git(hub)-hosted repository, is it enough to just remove the code from the master branch?

Should also the git history be rewritten to contain no traces of that code? That can be quite hard.

And what if your code ended up duplicated in source packages in Debian or Fedora repositories? And if it has also been included in some ISO files then printed on CDs? Should those CDs be destroyed?

The most powerful contributor agreement

Posted Apr 3, 2014 4:04 UTC (Thu) by pabs (subscriber, #43278) [Link]

Hmm, the DCO blocks things like taking a random Android device/kernel and upstreaming the drivers and board support for that device, since random Android device kernel devs probably haven't done the DCO dance.

The most powerful contributor agreement

Posted Apr 3, 2014 4:20 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

No, clauses (b) and (c) cover that case.

The most powerful contributor agreement

Posted Apr 3, 2014 15:52 UTC (Thu) by louie (subscriber, #3285) [Link]

They permit that case, but not clear that they actually solve that case - you don't, in that situation, get the indentifiability/trackability of the source that is supposedly the primary benefit of the DCO.

The most powerful contributor agreement

Posted Apr 3, 2014 16:36 UTC (Thu) by iabervon (subscriber, #722) [Link]

The general kernel policy is not to take code whose author doesn't want it contributed to the kernel, despite the GPL giving the project the right to do so. (In general, this is wise, since it's possible that some code was written for a Windows (or chip reference) driver and leaked to a third party, and the third party combined it with the GPL kernel without any license to some of the code, such that the author of the first part never had to accept the GPL and the kernel wouldn't have a proper license to that part of the code.)

Even when the code is structured such that it is clear that it must be licensed by the copyright holder to any recipients under the GPL, it's just seen as impolite to take code into the project against the author's wishes.

The most powerful contributor agreement

Posted Apr 6, 2014 0:43 UTC (Sun) by pabs (subscriber, #43278) [Link]

What happens when the author/copyright holder hasn't expressed any opinion about mainlining the code but just hasn't bothered to do that? I expect that is the situation for almost all Android versions of the Linux kernel.

inbound=outbound: The clear value of the DCO and its derivatives

Posted Apr 3, 2014 18:49 UTC (Thu) by bkuhn (subscriber, #58642) [Link]

James Bottomley and I have many disagreements about Free Software licensing policy. When two policy makers like James and I are agreeing about an important issue, that's usually an indication that the idea is a very good one.

This is one such case. I strongly agree with the point that a thin DCO-style CLA that implements inbound=outbound is all the CLA'ing that a Free Software project needs. (I wrote about this at length in my critique of Project Harm ony and its “next generation”.)

Indeed, the organization I work for, Software Freedom Conservancy) is often asked by its member projects to implement some sort of CLA, and we usually steer them towards the DCO (or slightly modified versions thereof, as needed). I'm very glad the Linux community invented this idea and shared it freely with the world under a CC-By-SA license. This is a huge help to the community!

Finally, I have commented elsewhere in this thread to note another important point: I have yet to see a situation where there's a bona fide and useful legal certainty that is sought for a Free Software project wherein a CLA is required. In every example I've seen, the bug lies not in the lack of a CLA, but in an inadequate Free Software license. This is precisely why, for example, GPLv3 is a better choice than GPLv2 and the Apache License is a better choice than the ISC license: because in both those cases, the latter license covers important legal issues that the former license doesn't.

inbound=outbound: The clear value of the DCO and its derivatives

Posted Apr 3, 2014 19:05 UTC (Thu) by bkuhn (subscriber, #58642) [Link]

> This is precisely why, for example, GPLv3 is a better choice than GPLv2 and the Apache License is a better choice than the ISC license: because in both those cases, the latter license covers important legal issues that the former license doesn't.

Woops, former and latter are backwards in there. Sorry about that. :)

The most powerful contributor agreement

Posted Apr 7, 2014 1:26 UTC (Mon) by pj (subscriber, #4506) [Link]

Other issues aside, I like DCO over CLA because DCO signoff is per-commit, while CLA signoff is.. forever? It may make no practical difference, but I like not having code I've yet to write be covered by a CLA I already signed.

The most powerful contributor agreement

Posted Apr 9, 2014 18:32 UTC (Wed) by kpfleming (subscriber, #23250) [Link]

CLAs generally require explicit contribution by the contributor. The fact that code you write after signing the CLA is potentially contributable under the terms of that CLA does not mean the code is 'covered' by it, if by 'covered' you are implying that the receiving project somehow has rights to use the code even though you did not contribute it.

The most powerful contributor agreement

Posted Apr 26, 2014 3:47 UTC (Sat) by mikedep333 (subscriber, #91993) [Link]

Thank you. I just suggested to the open source project I contribute to (X2Go) that we adopt the DCO.

Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds