[Harmony-Review] CLA vs. software license terms

[Allison Randal]

On 04/17/2011 12:46 PM, Dan Scott wrote:
>
> The "perpetual" and "irrevocable" parts would suggest that the terms of
> the software license wouldn't apply. The clause "provided that this
> license is conditioned upon compliance with Section 2.1(d)" modifies the
> first clause: I'm not familiar with the use of the verb "conditioned" in
> a legal context, but it seems to suggest that the terms of the software
> license(s) itself then trump the perpetual / irrevocable parts of the
> first clause in 2.1(b). So, disaster averted, I hope? Perhaps legal
> experts could suggest whether this is typical verbiage for conditional
> clauses and works in the way that we expect it to.

Yes, we had extensive discussion on this during drafting and I was 
assured by a number of highly experienced FLOSS lawyers that "provided 
that"..."conditioned" is effective (actually essential) for ensuring 
that the license/assignment to the project is revoked if the condition 
is broken.

> Given that the software license itself for the contribution itself
> defines licensing terms, what is the advantage to adding another layer
> of licensing in this document? There seems to be plenty of potential for
> conflict between the terms of the CLA and the software licenses that
> could be avoided if licensing details were handled by the software
> licenses.
>
> The main advantage that I see in a contributor agreement is the explicit
> assertion that the contributor has the right to make the contributions
> they're making (3.b, 3.c, 3.d) - legal hygiene - but on that front the
> Linux DCO probably does a better job. I was hoping that the Harmony CA
> would effectively provide a standing DCO (sign once, so that
> contributors to the project understand that contributed code must be
> their own or theirs to contribute) and then let the software license
> under which the code is contributed dictate the terms of that code's
> use. This is factor #2 in the Harmony Overview FAQ
> (http://www.harmonyagreements.org/overview.html) but given the relative
> length of section 3 in the CLA where we deal with rights to make
> contributions, it looks like the primary goal of the Harmony CAs are to
> deal with factor #3 in the Harmony Overview FAQ: enabling a project
> to license and relicense contributed code with maximum flexibility.
> (Perhaps I've answered my own question in the previous paragraph.)

There are many approaches to contribution policy. Linux Kernel's 
"Documented Certificate of Ownership" is one approach, and combined with 
the kernel practice of "signing off" on all commits it's a strong legal 
strategy. We talked about whether Harmony itself should offer a DCO 
variation, and decided that as a group of volunteers with limited time, 
we'd do a better job focusing on a family of closely-related agreements. 
This isn't in any way a rejection of DCO as a strategy (or 
inbound=outbound either), it's just choosing an approachable "scope" for 
the Harmony project. We talked about adding to the FAQs with a pointer 
to Linux DCO as a good example to follow if your project wants a similar 
contributor policy (I haven't had time yet, but it's still on my Harmony 
todo list).

Harmony itself addresses factors #1-8 in that FAQ Overview (some with 
selectable options), while factor #8 is a reason not to use contributor 
agreements. Factor #1 is also sometimes a reason not to use contributor 
agreements (the project culture could go either way). And yes, the 
desire to address all of those factors in some form is the key motivator 
for Harmony, and for the form it's taken. Again, Harmony isn't trying to 
say "every FLOSS project must use these options and no others", it's 
just pulling together best practices from a related family of 
contribution policies and making them easier for projects to use, and 
for contributors (both individuals and organizations) to 
review/understand/accept.

Allison