The most powerful contributor agreement [LWN.net]

The most powerful contributor agreement

Posted Apr 2, 2014 20:40 UTC (Wed) by jhoblitt (subscriber, #77733)
Parent article: The most powerful contributor agreement

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

to post comments

wrong question (maybe?)

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

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] (2 responses)

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

jake

wrong question (maybe?)

Posted Apr 3, 2014 13:25 UTC (Thu) by fuhchee (subscriber, #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] (4 responses)

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 (guest, #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 (guest, #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 (guest, #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?