In association with heise online

Harmony Harmful?

Bradley Kuhn of the Software Freedom Conservancy doesn't think the Harmony agreements are useful though, labeling the project "... Considered Harmful". After finding problems with the project's name (it's not descriptive and it clashes with a number of existing projects), he moves on to problems with the agreements. These include the lack of any promises to the developer assigning copyright (the FSF, for example, makes binding promises to the developers), problems with the choice of venue clause (it muddies the copyright claims in the assignment), complexity of enforcement, and other contractual problems.

Most of all, Kuhn takes exception to the lack of the simplest model of licensing, "inbound=outbound", a term devised by Red Hat lawyer Richard Fontana, which implies that if Project X is licensed under Licence Y, then contributions to X should be under licence Y too. It's a simple model, and it is well tested: this is how contributions to the Linux kernel work. All a developer needs to do is sign-off on a DCO (Developer's Certificate Of Origin) saying they have the right to contribute it and they are done.

Red Hat lawyer Richard Fontana goes further, and in a two part article, "The Trouble with Harmony" (part 1, part 2), takes the entire concept of copyright aggregation to task, arguing that by seeking the maximum amount of control in the agreement "Harmony inherits, and thereby legitimises, all of that model's problems."

For example, the worst case scenario would be where a company could take rights to an open source project through copyright assignment and create a closed fork from a permissively licensed release of the code. Now, what probably happens in this scenario is that people stop contributing to the code, or they create a fork of the code. LibreOffice is one of the most recent examples of that happening. Ironically, in that case the code was later released under a more permissive licence, but not before deep divisions had been established in the community. The worst case scenario is only possible under a couple of variations of the Harmony agreements, but that is enough to reduce the agreements' value as a "brand". Although easy to select by a company or a project, developers will still have to work out which variation of the Harmony agreements the project has selected.

Allison Randal, technical architect at Canonical, points out that "All forms of collaborative development are copyright accumulation." She suggests that there's little difference between the Linux DCO, Mozilla Committer's Agreement or Apache CLA, and the use of a Harmony agreement which would assign copyright. "In Harmony", says Randal, "the only form of copyright assignment offered is one where the contributor gets back such a broad license to their contribution that there's only a tiny sliver of a difference between that and ownership".

That may be, but that position does disguise the acquired power of the aggregator who will have collected the rights to the entire codebase, and the act of aggregation makes the relationship unbalanced; a patch or module for an application has little inherent worth without the application. As OSI Board member Simon Phipps says in his personal column Out Of Tune With Community: "In rare cases, accumulating the copyrights of a project is the lesser evil for historic reasons", but this should be regarded as the exception and not the rule. Phipps' own rule is: "In open source, avoid any institutional inequality and focused control", and he believes that this is part of the formula behind flourishing communities.

The nub of the problem for Harmony is that it appears to be addressing a problem, the formulation of contributor agreements, while not addressing the question of why and when such agreements are needed. Whole classes of agreements, such as Linux-style DCOs, appear not to have been considered because they were not in whatever was the original remit of the project. Discussions began under the "Chatham House Rule", meaning that participants can publicly disclose what was discussed, but not who discussed it. Phipps notes that the process stalled under this regime, and moving it into the open was more about trying to restart the process.

It was also unclear who decided when the agreements were done – Bradley Kuhn points out that he asked who cleared the final versions, but was told it was by "participant consensus(ish)". Even a supporter of the project, the Codeplex Foundation's CTO, Stephen Walli, describes the first version of the Harmony documents as "a stake in the ground to anchor debate", rather than a completed process.

The apparent informality and opaqueness of the Harmony process, a lack of clarity about its goals and its formation, and its initial operation by company representatives seem to underlie most people's problems with it. For example, only a few developers were involved with the project, yet they are notionally a major stakeholder in any agreement – this in turn leads to suspicion. Kuhn suggests the project "is not something that most developers requested; it was initiated by companies who would like to convince developers to passively adopt overreaching CLAs [Contributor Licence Agreements] and ©AAs [Copyright Assignment Agreements]".

What we have now, as Simon Phipps describes it, is a "curate's egg", with flawed copyright assignment agreements, mostly flawed copyright licensing agreements and one or two useful agreements. It's likely that we shall see some of those agreements implemented by Canonical, the company that backed Project Harmony at the beginning, but whether any other companies or projects will adopt them rather than formulate their own, is unclear.

If Harmony is to become useful to the wider community, it needs to move to become a repository of best practices for open source collaboration for both companies and developers, with a visible, accountable and representative structure. Without addressing the wider questions, anything the project produces will be regarded as flawed by many in the community. Whether that remodeling of the project is something that backers such as Canonical would be interested in is unclear.

The other question then is whether Harmony, given the baggage it has already accumulated, is the right venue for that project.

Print Version | Permalink: http://h-online.com/-1283369
  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit
 


  • July's Community Calendar





The H Open

The H Security

The H Developer

The H Internet Toolkit