Out Of Tune With Community

Controversial in certain circles, the work of a loose grouping of people to create a set of standardised contributor agreements for open source projects at "Project Harmony" has reached its 1.0 milestone. At the website you'll find a release...


Controversial in certain circles, the work of a loose grouping of people to create a set of standardised contributor agreements for open source projects at " Project Harmony" has reached its 1.0 milestone. At the website you'll find a release version of the agreements.

Contributor agreements are used to accumulate copyrights into the hands of a single organisation. They are especially associated with open source projects like MySQL which use a "dual license" or an "open core" business model, but are also used by projects like Apache to provide flexibility and by the FSF to allow them to prosecute companies who fail to abide by the license.

Started under a shroud of "Chatham House rules" secrecy by a Canonical executive, and then brought into the open when the process later stalled, Project Harmony sought to create standardised agreements so corporate lawyers have a smaller workload reviewing them when they are encountered. All well and good, but how should open source community members regard them?

First let's look at some links from other commentators:
  • Bradley Kuhn of the Software Conservancy is clearly opposed both to Project Harmony’s work products and sponsors.

    "In short, Project Harmony is a design-flawed solution looking for a problem."

  • On the other hand, Stephen Walli of the Microsoft-backed Outercurve Foundation seems happy with the results.

    "The Harmony Project is an attempt to provide some clarity to the discussion by creating a set of usable documents (with their guide, Creative Commons-style agreement generator, and FAQ) and the first version of the documents will be a stake in the ground to anchor debate for some time. I’ve great confidence that the agreements will continue to evolve with discussion and debate, and the core Harmony team should be applauded for their efforts to date."

  • Harmony Agreements Reach 1.0
    Occupying a position between these extremes, open source consultant Dave Neary has a view that I find it easy to share.
    "Do you really need a CLA to achieve your objectives? Is it, in fact, harmful to some of what you want to achieve? At the end of the day, my position remains the same: the goal should not be to write a better CLA, it should be to figure out whether we can avoid one altogether, and figure out how to create and thrive in a vibrant developer community."
  • The first part of a comprehensive and hard-hitting article by lawyer Richard Fontana of Red Hat. This article is well worth reading in both parts as it makes a number of very valid and subtle points about the problems with copyright aggregation.

    "Despite my admiration, respect and affection for those who have been driving Harmony, I cannot endorse the product of their work. I believe Harmony is unnecessary, confusing, and potentially hazardous to open source and free software development."

  • The second part of the article by Richard Fontana of Red Hat. Richard declares the whole Harmony project misguided.

    "Formal contributor agreements, whether maximalist or minimalist, remain an uncommon phenomenon in open source. We are only beginning to learn what works, what fails, and what causes harm to open source community development. It is premature for us to unify, or harmonize, the ‘law’ of open source contribution policies. We are particularly not ready to declare victory for the perennially controversial maximalist approach, let alone Harmony’s new take on it."

Evaluating Harmony

So to join the dots. First I should say that I have been involved in the Project from an early stage, making small contributions from time to time in order to ensure that the resulting documents are understandable by and respect the interests of open source developers. My participation has never implied endorsement; indeed, since about 2008 I have had a growing sense that copyright accumulation is actually a threat rather than a benefit to open source.

The project is something of a "curate's egg", involving a few variants that are relatively OK and others which present communities with the problems of inequity that I've previously documented.  I consider all forms the Harmony copyright assignment agreement to be a poor choice for open source communities as they disconnect the creators of code from their creation. If a license to the copyright is good enough to create the open source movement in the first place, it is surely enough also to support the communities of code that the movement comprises.

Of the variants of the Harmony copyright licensing agreement, only the first two - the ones with fixed and limited outbound licenses - are agreements I would consider to be usable (carefully) without harm assuming you have decided that some form of copyright accumulation is unavoidable. These variants are closest to Richard Fontana's "inbound-outbound" rule and I  find them written clearly enough for most developers to easily understand them.

Making An Exception The Norm

As Dave Neary points out and Fontana explains more expansively, the biggest issue with Project Harmony is the risk that it will validate the idea of copyright aggregation.  It may sometimes be advisable to have a participant agreement for a community, to ensure that everyone has the same understanding of and commitment to the project if they are sharing its evolution.

For a community to flourish, it should avoid aggregated copyrights, or vest them in a non-profit entity representative of and open to the community. In rare cases, accumulating the copyrights of a project is the lesser evil for historic reasons (in OpenJDK, for example). The problem with Project Harmony is that it can too easily lead to the conclusion that an exception should be the rule. I might not go as far as Richard Fontana or Bradley Kuhn, but I regard the Project as serving only the interests of corporate participants and not open source communities.

In open source, avoid any institutional inequality and focused control. Attempting to control a project through copyright accumulation leads to mistrust, contention and a rules-based focus. To repeat again what I’ve frequently said: trade control for influence, because in a meshed society control gets marginalised while influence delivers success.

Follow Simon as @webmink on Twitter and Identi.Ca