LWN: Comments on "The most powerful contributor agreement"

The most powerful contributor agreement

mikedep333 — Sat, 26 Apr 2014 03:47:15 +0000

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

The most powerful contributor agreement

kpfleming — Wed, 09 Apr 2014 18:32:19 +0000

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

pj — Mon, 07 Apr 2014 01:26:56 +0000

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

pabs — Sun, 06 Apr 2014 00:43:30 +0000

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

bkuhn — Thu, 03 Apr 2014 19:05:54 +0000

> 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. :)

wrong question (maybe?)

dlang — Thu, 03 Apr 2014 18:54:23 +0000

> 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.

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

bkuhn — Thu, 03 Apr 2014 18:49:07 +0000

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.

wrong question (maybe?)

bkuhn — Thu, 03 Apr 2014 18:33:30 +0000

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.

The most powerful contributor agreement

iabervon — Thu, 03 Apr 2014 16:36:47 +0000

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

louie — Thu, 03 Apr 2014 15:52:50 +0000

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.

wrong question (maybe?)

louie — Thu, 03 Apr 2014 15:51:09 +0000

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?)

louie — Thu, 03 Apr 2014 15:49:09 +0000

"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.

What does it mean "to remove"?

gioele — Thu, 03 Apr 2014 13:34:38 +0000

> "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?

wrong question (maybe?)

fuhchee — Thu, 03 Apr 2014 13:25:13 +0000

"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?)

dberlin — Thu, 03 Apr 2014 13:23:25 +0000

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.

The most powerful contributor agreement

mjg59 — Thu, 03 Apr 2014 04:20:59 +0000

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

The most powerful contributor agreement

pabs — Thu, 03 Apr 2014 04:04:00 +0000

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.

ambiguous, but amusing

jake — Thu, 03 Apr 2014 01:45:32 +0000

> point at the s-o-b

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

thanks for the chuckle, Neil ...

jake

wrong question (maybe?)

neilbrown — Thu, 03 Apr 2014 01:41:53 +0000

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.

wrong question (maybe?)

louie — Wed, 02 Apr 2014 22:08:33 +0000

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.

The most powerful contributor agreement

jhoblitt — Wed, 02 Apr 2014 20:40:30 +0000

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