[Harmony-Drafting] Harmony DCO

[James Bottomley]

On Sat, 2011-08-06 at 15:11 +0200, Allison Randal wrote:
> On 08/06/2011 12:12 AM, Michael Meeks wrote:
> >
> >     Is there a need to mingle the Harmony brand with the Linux's DCO
> > process ? is there something missing in the latter that is deficient,
> > and/or could be improved on?
> >
> >     Can we not just point at the Linux DCO process and say "use that if
> you
> > want it" :-) I'm personally nervous about applying the Harmony brand to
> > very different things 'Java'-style ;-)
> 
> It's not about branding. It's three things:
> 
> - We can just point people at the Linux Kernel DCO, but it was drafted for
> the contribution policy of the Linux Kernel. Each adopter from a different
> project will have to think through what is or isn't specific to the Linux
> Kernel, and what their options are for alternations or variations.

Well, so this isn't correct ... and is a good illustration of why the
DCO needs some explanation.

The DCO is in no way kernel specific.  It was designed for any open
source project under any licence that accepts unassigned contributions.
This is the DCO version 1.1:

        By making a contribution to this project, I certify that:

        (a) The contribution was created in whole or in part by me and I
            have the right to submit it under the open source license
            indicated in the file; or

        (b) The contribution is based upon previous work that, to the best
            of my knowledge, is covered under an appropriate open source
            license and I have the right under that license to submit that
            work with modifications, whether created in whole or in part
            by me, under the same open source license (unless I am
            permitted to submit under a different license), as indicated
            in the file; or

        (c) The contribution was provided directly to me by some other
            person who certified (a), (b) or (c) and I have not modified
            it.

        (d) I understand and agree that this project and the contribution
            are public and that a record of the contribution (including all
            personal information I submit with it, including my sign-off) is
            maintained indefinitely and may be redistributed consistent with
            this project or the open source license(s) involved.


Such certification is signified in the linux kernel by Signed-off-by:
and the signoffs go into the text of the patch in source control ...
it's important to note that a mechanism for collecting DCO
certifications is required, but the kernel mechanism works for any
project that keeps all contributions in source control.

All that's really required of harmony is an explanative preamble:  Why
the DCO in the first place (because provenance is important from a legal
perspective).  How to maintain attributions (i.e. the importance of a
good source control system).

James


> - There is enormous benefit in the process of publicly talking through the
> core values of inbound=outbound: what is the "norm", what are the reasonable
> variations, and what is really unacceptable for FLOSS cultural values.
> 
> - The biggest effort of Harmony was not drafting the CLA/CAA templates. That
> part mainly happened in the last 4 months. The biggest effort was in
> building a community of FLOSS lawyers and advocates, and establishing a
> community culture of collaboration, cooperation, and fair representation for
> diverse perspectives. With that established community, we can dive right
> into the details of inbound=outbound, rather than starting over from scratch
> building a new community.
> 
> Allison
> 
> [Apologies for breaking the reply-to thread, I'm having trouble with SMTP at
> the Desktop Summit, so resorting to Gmail.]