Bottomley: A modest proposal on the DCO
The lever that will help to make this move is a simple pledge, which can be published on a corporate website, that allows corporations expecting to make legitimate contributions to patent binding licences under the DCO to do so properly without needing any additional Contributor Licence Agreements. Essentially it would be an explicit statement that when their developers submit code to a project under the DCO using a corporate signoff, they’re acting as agents for the necessary patent and copyright grants, meaning you can always trust a DCO signoff from that corporation."
Posted Jan 3, 2016 19:08 UTC (Sun)
by paulj (subscriber, #341)
[Link] (40 responses)
E.g., the origin of the DCO was not a legal imperative, but Linus trying to head off various calls for all kinds of bureaucracy in the wake of the SCO allegations (before it was known they were total bull). The DCO was introduced to solve a social problem for Linus (put a stop to an annoying debate and head off worse), not a legal one, per se - IIRC.
Also, I have in other projects besides the kernel seen "cargo-culting" of the DCO. People add it simply because they are told to add a "signed-off-by" line to get a patch committed, and there's no evidence at all the contributor has any idea the project intends this to mean they have agreed to anything. I'd be worried that such a way of indicating agreement would be hard to make stick, if it ever ended up mattering.
Is the DCO meaningful, or is it something Linus invented to get others off his back that is now being cargo-culted around free software communities?
Posted Jan 3, 2016 22:35 UTC (Sun)
by ledow (guest, #11753)
[Link] (2 responses)
And, no, that doesn't mean unenforceable or we'd all be giving out free copies of Microsoft Office or AutoCAD with no comeback. Think about AT&T vs BSD and the debacle they caused, but when it comes to a court of law, the wording and intention is quite clear and copyright assignments are still in place and valid.
It means precisely what it says, and if a court decides that it's not unreasonable (it isn't, is it? To have an agreement by which you contribute to a codebase? In pretty much every coder's work contract, no?) then it's enforced.
Whether the attribution is knowingly performed may be one issue, but it's hard to argue if its written into the licences that you knew you were contributing to. All it takes is an #include in LICENSE file and you're done.
Posted Jan 4, 2016 6:16 UTC (Mon)
by xtifr (guest, #143)
[Link] (1 responses)
Aside from that quibble, though, I agree with you. Courts take intent into account when examining agreements between parties, so the DCO means whatever it says, basically. :)
Posted Jan 4, 2016 15:29 UTC (Mon)
by drag (guest, #31333)
[Link]
I believe that EULA would fall under contract law, which does not have the same sort of restrictions and limitations that copyright licenses like the GPL have to face. That is with contracts you can agree to pretty much anything.
With most commercial software you have both EULA and copyright restrictions.
That's one of the things that makes these things so confusing. Contract law, Patent law, copyright law, etc.... all these are separate and disparate bodies of law. They have much relation to one another as they do with laws against jay walking. But people like to lump all them together as if 'IP' is a actual thing and unfortunately all of them end up being applied to software.
Posted Jan 4, 2016 1:37 UTC (Mon)
by rfontana (subscriber, #52677)
[Link] (5 responses)
Posted Jan 4, 2016 11:27 UTC (Mon)
by paulj (subscriber, #341)
[Link]
This story has me thinking.. If I wanted to get contributors to agree to something but without having to sign and mail agreements, I'd go with the actual agreement document kept in the SCM/git and require that a contributor send a patch to update it with their name before anything was accepted from then.
That seems like it'd be a bit more meaningful to me than a DCO?
Posted Jan 4, 2016 13:07 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (3 responses)
IME pretty much all legal documents are 90% cut-n-paste from previous documents (more if possible) with the minimum change necessary to suit the circumstances.
What is that if not cargo-culting? "It worked in court last time, we've got precedent, we'll use it again".
Cheers,
Posted Jan 4, 2016 15:27 UTC (Mon)
by anton (subscriber, #25547)
[Link]
Posted Jan 5, 2016 12:26 UTC (Tue)
by jezuch (subscriber, #52988)
[Link]
Boilerplate proliferation? You know, like these pesky configuration files that all look alike but with minor differences; would *you* write a new one from scratch, or just copy some existing one and change what needs to be changed? (I know I do that routinely with Maven's POM files. It kind of follows naturally from having configuration in XML ;) )
Posted Jan 5, 2016 14:24 UTC (Tue)
by rfontana (subscriber, #52677)
[Link]
Posted Jan 4, 2016 4:05 UTC (Mon)
by david.a.wheeler (subscriber, #72896)
[Link] (29 responses)
In the US, there are only a few situations where actually signing something "in writing" is actually required, e.g., actually *transferring* a copyright from one party to another does require something to be signed. But except for those rare cases, you do not HAVE to sign anything; verbal agreements are still legally enforceable. The problem with verbal-only agreements is that it can be hard to show in a court that there was actually an agreement.
Many lawyers focus only on minimizing legal risk, and ignore the practical problems of the "minimum risk" approach. Sometimes minimizing risk is exactly the right thing to do... but in other cases it's not reasonable. A good lawyer should be able to identify the pros and cons of different approaches.
For example, for decades lawyers were worried that if person X released software but under copyright law wasn't authorized to do so, and person Y used the software, then person Y (not just X) could get sued. Sadly, that unjust possibility is allowed in the US's legal system. The good news is that this kind of action practically never happens, and the only efforts I'm aware of eventually got quashed. Thus, lawyers worried long and hard over a risk that in practice practically never materializes. This issue has probably has happened somewhere, but that misses the point. You can't eliminate all risks; at some point you have to accept the residual risk.
Having something *simple* that reduces risks seems like a good idea. The DCO has been a fantastic mechanism - it reduces legal risks (positive benefit), and is so easy to use that it has practically no cost. If there are ways to provide more legal protection with practically no cost, that's great. I don't know if Bottomley's approach is good or workable, but hashing out the options seems like a good first step.
Posted Jan 4, 2016 11:36 UTC (Mon)
by paulj (subscriber, #341)
[Link] (27 responses)
The issue I have with DCO is that there adding a "-s" argument to git commit doesn't really mean you have even heard of the DCO (the git commit man page makes no mention of the DCO anywhere), never mind actually seen it. So how can the presence of "signed-off-by" in any way imply the sender is agreeing to and committing to the DCO? Combined with fact I've seen replies on lists to patches without SOBs that say nothing more than "Resend this with signed-off-by so I can commit it".
It's not clear at all that the presence of "signed-off-by" is in any way indicative of the contributor having seen the DCO or knowing that signed-off-by means they are agreeing to that DCO, is it?
Why not have the agreement document in the SCM, and just require people send a patch to update it to show their assent? That'd be a much more affirmative and clearer way, no?
Posted Jan 4, 2016 13:33 UTC (Mon)
by andresfreund (subscriber, #69562)
[Link] (9 responses)
That'd lead to constant conflicts, unless you use some more complex mechanism to avoid those.
Posted Jan 4, 2016 14:41 UTC (Mon)
by paulj (subscriber, #341)
[Link] (8 responses)
Posted Jan 4, 2016 14:57 UTC (Mon)
by andresfreund (subscriber, #69562)
[Link] (7 responses)
At that rate the conflicts would be more than a bit annoying, even if individual trivial to resolve.
Posted Jan 4, 2016 16:50 UTC (Mon)
by ms (subscriber, #41272)
[Link] (1 responses)
Posted Jan 5, 2016 20:47 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Posted Jan 4, 2016 21:07 UTC (Mon)
by neilbrown (subscriber, #359)
[Link] (2 responses)
Creating a simple merge tool that resolves these trivial conflicts would be easy. git is quite capable of using different merge strategies for different files.
I'm not arguing in favour of that file, just saying that conflicts is not an argument against it.
Posted Jan 4, 2016 21:10 UTC (Mon)
by andresfreund (subscriber, #69562)
[Link] (1 responses)
Unfortunately those can't, to my knowledge, be distributed & configured together with the repository. I.e. they have to be configured in each cloned repository...
Posted Jan 4, 2016 21:20 UTC (Mon)
by neilbrown (subscriber, #359)
[Link]
Posted Jan 4, 2016 21:54 UTC (Mon)
by cov (guest, #84351)
[Link]
Posted Jan 4, 2016 22:48 UTC (Mon)
by paulj (subscriber, #341)
[Link]
Or just an append-both git merge strategy run by the core project commiters repos, as Neil notes.
Posted Jan 4, 2016 21:16 UTC (Mon)
by neilbrown (subscriber, #359)
[Link] (14 responses)
Is the signature at the bottom of a piece of paper indicative that the signer read the page? Is a click on a click-through license indicative of .... anything.
I certainly agree that when we talk about S-O-B, we should also talk about DCO and what it means. But the fact that we don't always do that doesn't mean the S-O-B is useless. Like signatures and click-throughs they have value, but not absolute value. Sometimes we need signatures to be witnessed, sometimes by a JP / Public Notary.
If a corporation made a public statement about s-o-b like James proposes, I suspect they would educate their employees accordingly, and then it would be reasonable to expect thos s-o-bs to mean something more.
Posted Jan 4, 2016 22:41 UTC (Mon)
by paulj (subscriber, #341)
[Link] (13 responses)
At the moment, there's no connection between adding "signed-off-by" to a commit and being even aware of the DCO. Hell, the git commit documentation (i.e. man page) on "signed-off-by" doesn't mention it at all. Committers on projects may not even tell the unaware contributors of that connection, even when asking for a signed-off-by (the "Add a signed-off-by" reply to unaware contributors - with no context).
Anyway, FWIW, if *I* _needed_ contributors to a project of mine to make some commitment, then I'd want something a bit more "affirmative", with a much closer, clearer connection between the affirming action and the commitment, than DCO and SOB provide. As, based on how I've seen others (contributors _and_ project committers) treat SOB as a piece of text to be blindly copied to tick whatever box, I just don't trust SOB to be worth much if/when demonstrating that commitment was made was actually important.
Posted Jan 5, 2016 19:00 UTC (Tue)
by david.a.wheeler (subscriber, #72896)
[Link]
I agree it'd be nicer if git mentioned the meaning of 'signed-off-by'. I've created a proposed commit to git that does this, and plan to submit it soon. Basically, it modifies the git text to explain that signed-off-by can mean whatever the project says it means, but it typically means you're allowed to contribute the change - including agreement to some DCO.
In the Linux Foundation's Core Infrastructure Initiative (CII) Best Practices Badge, here is what we are currently doing:
If we make it too hard to contribute, people won't contribute. I think these two steps are easy and yet have real legal benefit. If future git documentation makes this clearer, that will quietly strengthen our case even further.
Posted Jan 5, 2016 19:45 UTC (Tue)
by david.a.wheeler (subscriber, #72896)
[Link] (11 responses)
Posted Jan 6, 2016 12:39 UTC (Wed)
by paulj (subscriber, #341)
[Link] (10 responses)
Still very sceptical of DCO though. People might literally just be writing SOBs in their git commit messages, not even knowing about -s.
Indeed, just writing the tag is my standard practice, as most tags ('reviewed-by', 'acked-by', etc..) don't have command-line options, so there's no point taking the mental hit of using an exceptional path for one tag (that I never use on the project I contribute to regularly anyway).
Posted Jan 7, 2016 19:08 UTC (Thu)
by david.a.wheeler (subscriber, #72896)
[Link] (9 responses)
As I noted earlier, I submitted a patch to git’s documentation to specifically mention the DCO:
Junio C Hamano (git’s maintainer) liked it, and has queued it for addition:
So... you noted a weakness, and it's getting fixed. Things could be worse...!
Posted Jan 7, 2016 21:24 UTC (Thu)
by mlinksva (guest, #38268)
[Link] (3 responses)
I'm curious what are the deltas for risk reduction, cost increase, and bad actor deterrence going from 1) project under a free/open source license to 2) project under a free/open source license with documentation stating that contributions are made under this license to 3) project under a free/open source license with legal-sounding documentation such as the DCO text stating that contributions are made under this license to 4) project under a free/open source license with legal-sounding documentation such as the DCO text stating that contributions are made under this license and signed-off-by lines added to commits to 5) project under a free/open source license that requires contributor to go through some process documenting their agreement that contributions are made under that license (or in the case of many CLAs, that they grant more than the project license does)? Have these deltas been rigorously described in theory? Is there any evidence that they exist and are significant?
Posted Jan 10, 2016 1:44 UTC (Sun)
by rfontana (subscriber, #52677)
[Link] (2 responses)
No and no. Of course not. It is all essentially superstition.
Posted Jan 10, 2016 4:47 UTC (Sun)
by mlinksva (guest, #38268)
[Link] (1 responses)
Posted Jan 10, 2016 17:58 UTC (Sun)
by rfontana (subscriber, #52677)
[Link]
Posted Jan 8, 2016 14:22 UTC (Fri)
by paulj (subscriber, #341)
[Link] (4 responses)
If it ever really mattered, what will matter is binding the /person/ to the DCO. The GPG step doesn't do that *unless* the key has also been verified to some degree (e.g. signed by someone trust-worthy who has validated ID, etc.). Without that verification, all you have is that someone who can send stuff from that email (if that has even been verified) knows how to use GPG.
In which case, you may as well just drop the overhead of the GPG step and just have them send a normal email (assuming most people's email is TLS protected these days, and MTAs and providers are unlikely to falsify emails).
Mere use of cryptographic protocols is not, of itself, authentication.
Posted Jan 8, 2016 18:39 UTC (Fri)
by nybble41 (subscriber, #55106)
[Link] (3 responses)
Posted Jan 9, 2016 21:11 UTC (Sat)
by paulj (subscriber, #341)
[Link] (2 responses)
Unless you authenticate the public key and establish who controls it, it's just "Ooh, look, cryptography, shiny!" and likely only just adding overhead.
Posted Jan 9, 2016 21:19 UTC (Sat)
by nybble41 (subscriber, #55106)
[Link] (1 responses)
Which is why I said "If they also sign their commits *with the same key*". Even if you don't know their name or anything else about them, the fact that the DCO and the commit were signed with the same key shows that whoever signed the commit also agreed to the DCO.
Posted Jan 9, 2016 22:02 UTC (Sat)
by paulj (subscriber, #341)
[Link]
Posted Jan 5, 2016 16:18 UTC (Tue)
by david.a.wheeler (subscriber, #72896)
[Link]
That said, I think *hinting* what signed-off-by means in the git documentation seems reasonable. I'll propose it.
Posted Jan 7, 2016 18:10 UTC (Thu)
by mlinksva (guest, #38268)
[Link]
This does seem heavyweight, but the project requires signed commits so GPG is already in the mix.
I enjoy the documentation being in the repository (compare with many CLAs, where those who have signed in in some database only accessible by licensee or some intermediary, and whatever good, if any, contributor agreements are for provenance, most of that good is lost if not kept with the code) and the signing coupled with the contributor agreement (or similar, DCO here) rather than decoupled as in most projects using DCO IIUC.
Posted Jan 4, 2016 12:03 UTC (Mon)
by ovitters (guest, #27950)
[Link]
Posted Jan 7, 2016 21:35 UTC (Thu)
by mlinksva (guest, #38268)
[Link]
Linus' original proposal (IIUC) is pretty interesting
It emphasizes documenting the full path a patch goes through. Presumably this would be valuable to some projects, presumably huge ones with many lines of development in many entities like Linux, even if there were no licensing or copyright. Perhaps whether there is this sort of value for a project or not should play a much bigger role in a project's evaluation of adopting singed-off-by and related fields than talismanic copyright risk reduction.
Posted Jan 7, 2016 18:34 UTC (Thu)
by mlinksva (guest, #38268)
[Link]
> When one of our developers posts a patch to a project under an OSI approved licence with a DCO Signed-off-by: from our corporate email domain, we authorise that developer to be our agent in the minimum set of patent and copyright grants that are required to satisfy the terms of the OSI approved licence for the contribution.
Clarification in a comment asking why the proposal doesn't state who patent rights are granted to:
> The DCO is silent on the terms of the licence because its designed to be a contribution process, not a licence in itself. So the DCO only works in combination with an Open Source licence, and the terms of that licence govern what (if any) patent rights go with the project. The pledge is merely designed to clarify that a corporate contribution to a licence which entails patent rights can be made under the DCO.
First limitation on the proposal:
> This pledge only applies to projects which use an OSI accepted Open Source licence and which also use a developer certificate of origin (DCO).
Seems a pretty big limitation. Why not any project using an OSI accepted license? Email address (which proposal deems super important) already part of commit.
Bottomley: A modest proposal on the DCO
Bottomley: A modest proposal on the DCO
Bottomley: A modest proposal on the DCO
Bottomley: A modest proposal on the DCO
Bottomley: A modest proposal on the DCO
Bottomley: A modest proposal on the DCO
Bottomley: A modest proposal on the DCO
Wol
It would be cargo-culting if this kind of transfer happened between vastly different legal systems. Such things happen, too (I remember the story of an Austrian craftsman working in Austria for a US corporation, and having an accident due to his own fault, and the lawyers in the headquarters of the corporation going ballistic and sending in ground troops, while the actual legal situation was clearcut and no problem for the corporation). But when a real airbase looks similar to ones used by US troops in WWII, and might be based on the layout of those, that is not cargo-culting, but copying; and likewise for legal documents.
Bottomley: A modest proposal on the DCO
Bottomley: A modest proposal on the DCO
> What is that if not cargo-culting?
Bottomley: A modest proposal on the DCO
Not everything must be signed
Not everything must be signed
Not everything must be signed
Not everything must be signed
Not everything must be signed
"Of those 1,548 contributors, 246 made their first kernel contribution in this development cycle — the lowest number since 3.13."
Not everything must be signed
Not everything must be signed
Not everything must be signed
Not everything must be signed
Not everything must be signed
But it only needs to be configured at repositories where such conflicts happen, which means Linus, and several of his lieutenants, and linux-next and a few others.
And "./scripts/add-hooks" could make that configuration very easy.
Not everything must be signed
Not everything must be signed
Not everything must be signed
Not everything must be signed
Not everything must be signed
Modification to git documentation proposed
You can see it at:
http://permalink.gmane.org/gmane.comp.version-control.git...
Modification to git documentation proposed
Modification to git documentation proposed
Clearly, however, they're more effective if it's really obvious what they mean.
http://marc.info/?l=git&m=145202283716583&w=2
http://marc.info/?l=git&m=145203493820513&w=2
Modification to git documentation proposed
...
> I think DCOs have some value; they provide some deterrence against bad actors.
Modification to git documentation proposed
Superstition-enhanced just noticeable differences
Superstition-enhanced just noticeable differences
Modification to git documentation proposed
Modification to git documentation proposed
Modification to git documentation proposed
Modification to git documentation proposed
Modification to git documentation proposed
Not everything must be signed
Signing the Developer Certificate of Origin
Not everything must be signed
Bottomley: A modest proposal on the DCO
https://marc.info/?l=linux-kernel&m=108529494402563&...
30 comments and none on Bottomley's proposal