[Harmony-Drafting] Harmony DCO

[James Bottomley]

On Sat, 2011-08-06 at 17:52 +0200, Allison Randal wrote:
> On 08/06/2011 04:34 PM, James Bottomley wrote:
> > On Sat, 2011-08-06 at 10:14 -0400, Richard Fontana wrote:
> >>
> >> While that's true, if you look at the DCO -- the 'certification'
> >> itself, that is -- it is not specific to the Linux kernel at all. It
> >> could be used by any open source project. In fact, I have recommended
> >> to a couple of projects that they use, or consider using, the DCO,
> >> without modification. So it's already reusable, and in fact it may
> >> have been the first (non-FLOSS-license) contribution policy document
> >> not worded for any specific project (though I doubt that was a
> >> conscious design of its drafters).
> >
> > Actually, it was.  I thought we still had the history on the Linux
> > Foundation web site, since it was created by the OSDL general counsel
> > (Diane Peters) in collaboration with others, but it appears to have been
> > lost.  The original thought was that SCO type allegations could happen
> > to any open source project, so the DCO was designed to be
> > non-specific ... although the implementation (signoffs in the bitkeeper
> > logs) was crafted to the kernel.
> 
> The phrase "including my sign-off" is the main point of variation I saw on a
> quick read. For the Linux Kernel, this is a technical aspect of git, that
> each contribution can be (and for the kernel is required to be) signed off
> by the contributor, which forever associates their information, and the
> information of whoever approves their contribution with their patch, and
> attests their agreement to the DCO. This is an incredibly powerful legal
> tool, made quite simple through a technical process.

Well, not entirely:  The DCO is about provenance; provenance requires
attestation; sign-off is attestation.  It nowhere implies using
signed-off-by: tags in bitkeeper (or later git).  Sign-off could be a
physical piece of paper collected by the project.  This is the
difference between the DCO and the kernel implementation.  The DCO is
simply the four points I quoted earlier.  The entire kernel process
around it is here:  

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=569f3532e1383cb3e67dcba7b77990b5f18a1411;hb=HEAD

Now the legal advice to the kernel process is that email sign-off
signified by the Signed-off-by: tag is sufficient for this purpose, but
that doesn't preclude a whole range of other mechanisms for collecting
sign-offs.

> Is this technical solution essential for adopting a DCO as project policy?
> If so, are there other technologies than git that work equally well? If not,
> what are the alternatives for signoff that projects might adopt? Would the
> Linux Kernel DCO be usable by projects that want to take one (signed or
> digitally signed) affirmation from a contributor as they become a committer,
> and no signoff process on commits?

Any process which collects sign-offs and can verifiably trace them back
to contributions should be sufficient.

However, the whole point about a DCO like process is that it should be
as streamlined as possible, so for a project that collects patches by
email it's hard to see anything else that approaches the streamlined
nature of the kernel implementation.

> I also wondered about the Mozilla Committer's Agreement, which is
> philosophically inbound=outbound. The phrasing is more complex, and I
> haven't sat down to do a comparison to see if it could be boiled down to the
> beautifully simple phrasing of the Linux Kernel DCO, or whether it includes
> some significant legal variations. (And, I have no opinion yet whether it's
> worth accommodating legal variations it might have, if it has them.)

The MCO is similar to the Kernel SubmittingPatches file in that it
contains a combination of contributor agreement and implementation.  The
MCO is also slightly looser about the sign-off chain (you can commit
someone else's code if you have made "reasonable" effort to make sure it
conforms to the MCO), whereas the DCO contains a recursive clause
dealing with it exactly (so you can trace all the hands through which
the code passed).

> Are there other inbound=outbound agreements currently used by free software
> projects that we should review? Or, projects with an inbound=outbound
> philosophy, but no explicit declaration of it, where it's worth reviewing
> their contribution policy or conventions?

In general, they're disjoint sets:  inbound=outbound shows that the
licence sets the governance for the project and its contributions.  The
DCO is how you track the provenance of the contributions.

> On the whole, I hope the final result will be pretty similar to (nearly
> identical to?) the Linux DCO, with additional help and guidance on how to
> adopt it. But, I'm interested to think it through.

I think it should be identical, unless there's an extremely good reason
why not.  The whole point of Harmony is supposed to be preventing
proliferation ... rewriting the DCO "just because" is inviting it.

James