The trouble with Harmony: Part 1

No readers like this yet.
A community raising a barn

Harmony, the Canonical-led effort to provide a comprehensive suite of contributor agreements for open source projects, has quietly released its version 1.0, a year after Canonical general counsel Amanda Brock announced the initiative on During most of that year, Harmony's construction took place out of the public view, in deliberations that were cloaked by the Chatham House Rule.

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.

Contribution policies and free software tradition

For a quarter-century, most free software projects have been characterized by twin norms of transactional informality and licensor equality. Most projects have never used formal contributor agreements. Instead, they have customarily operated under a rule I call “inbound=outbound”: in essence, contributions are understood to be licensed in under the applicable outbound project license (or an explicit inbound license is passed through by the project downstream). This makes it easy for meritorious contributors to participate in projects without intimidation and red tape, and puts all project contributors, be they patch submitters or committers, on an equal legal footing. It is a form of legal governance that is so pervasive that I must conclude that the great success of the open source development model owes much to it.

The copyright assignment policies mandated by the Free Software Foundation for the early GNU projects were for many years the main exception to this general social rule. The use of formal contributor agreements has grown in recent times, but it remains a minority approach. Where such agreements are used, there are basically two approaches, which I will call maximalist and minimalist. Maximalist approaches are represented by copyright assignment agreements and by contributor license agreements (CLAs) that require maximally broad inbound copyright license grants. Minimalist approaches may be less well known; they generally involve a simple explicit commitment to use a particular well-known free software license for one’s contribution. This is typically either the applicable outbound license of the project (a formalization of the inbound=outbound custom), or some standard permissive license.

Maximalist contributor agreements have been highly controversial in FLOSS development communities, especially in the case of copyright assignment policies required by projects controlled by singular corporate interests. The best examination of this subject remains Michael Meeks’ essay “Some thoughts on Copyright Assignment”. It may be noted that Canonical announced the Harmony project some months after experiencing widespread community criticism leveled at its own copyright assignment agreement.

The illusion of constraint

Harmony has opted to follow, and thus legitimize, the maximalist approach, but in a new way that I fear may cause confusion. A project using Harmony must first decide whether to require copyright assignment or a maximally-broad inbound copyright license from the contributor; no other choice is given. The project is then expected to choose from a set of five mutually exclusive conditions on how the assigned or licensed-in contribution can be licensed out downstream by the project.

Each of the five options lets the project use the outbound project license as of the contribution submission date, but this is what a project would normally do anyway. (This is not the same as inbound=outbound, because the licensor under Harmony is the inbound project entity, not the contributor.) Four of the five options give the project some alternative to the use of the existing project license. In one of these four cases, the alternative is unrestricted, explicitly allowing the project entity to select any license, free or proprietary. (The project makes a token commitment to “additionally” license out the contribution under the existing project license.) The alternatives under the remaining three options consist of a list of licenses designated by the project, any OSI-approved license, and any FSF-recommended copyleft license.

What is notable about these outbound licensing options is that they are not meaningful, except in the case where the option commits the project entity solely to use of a copyleft license on the outbound side. This will only occur where the existing outbound license is a copyleft license and, if the project gets to pick an alternative license, the alternatives are either a list consisting solely of copyleft licenses, or the "FSF-recommended copyleft" category. In all other cases, the outbound conditions are essentially nominal. That is because, even if the “unrestricted” option is not selected, the project can always license the contribution under a noncopyleft FLOSS license, which by definition will place no outbound licensing constraints on use of the code, including use by the project entity itself.

I am not questioning the legitimacy of permissive licensing; indeed I have encouraged the use of standard noncopyleft licenses by Red Hat developers. What troubles me is that Harmony takes pains to give the appearance of constraining outbound licensing, when in reality this will be so only in one special (and likely rare) case. 

To give a simple example, suppose a company launches a new GPL-licensed project and asks contributors to sign a Harmony copyright assignment agreement with the “only OSI-approved licenses” outbound option selected. The company is then entirely free to license out all contributions under, say, the (OSI-approved) 3-clause BSD license, which in turn does nothing to restrict the company from privately licensing the project code, including contributions, under a proprietary, closed-source license. This is not some novel scenario, but what Harmony adds is the illusion of constraint, which I am concerned may mislead contributors who are relatively unfamiliar with open source licensing.

Harmony and GPL enforceability

I have suggested that Harmony’s appearance of constraining outbound licensing is real only where the project agrees to license out the contribution solely under a copyleft license like the GPL. But even in this case the maximalist model is in place, as it is in all other Harmony permutations. By assigning copyright to the project entity, or granting it the broadest possible copyright license, the Harmony agreement contributor is giving up all rights to police use of the contribution downstream from the project. This is the sharpest break from the time-honored inbound=outbound tradition: the contributor is cut off entirely from any real legal relationship with downstream users of the project’s code. Instead, the contributor is left only with some claim against the project entity, should it violate the grant condition.

Is this good enough? Perhaps for some contributors, in some cases. But a contributor who cares about downstream compliance with the GPL will have no remedy if the project entity makes no effort to enforce such compliance. The expectations of the contributor will lie unmet, yet the contributor will be powerless to do anything about it. Harmony did not create this problem; it is inherent in all existing uses of the maximalist model by GPL projects. But GPL-oriented contributors should not assume that a Harmony agreement with a GPL-outbound constraint will satisfy their policy objectives.

I continue my critique of Harmony in Part 2 of this article.

Richard Fontana
Richard is Senior Commercial Counsel on the Products and Technologies team in Red Hat's legal department. Most of his work focuses on open source-related legal issues.


<p>Fontana, I agree quite completely with your assessments. Your clarity of expression in formally conceptualizing &ldquo;inbound=outbound&rdquo; last year really clarified my views on why most CLAs are quite dangerous, and that concept <a href="">heavily influenced my own essay on Project Harmony's agreements</a>.</p>

<p>I do, however, hope that Red Hat will switch to a pure inbound=outbound approach for the <a href="">Fedora Project Contributor Agreement (FPCA)</a>. FPCA surely gets much closer to inbound=outbound than any Project Harmony permutation, but the degradation back to MIT permissive license as the &ldquo;Current Default License&rdquo; means copyleft might not be upheld due to mere forgetfulness on the part of a contributor.</p>

Bradley, while pure "inbound=outbound" can certainly work for a distro project, there are also good arguments in favor of use of the new minimalist approach of the FPCA with its default licensing feature. I suggest discussing this with Tom Callaway who has thought more about those issues in the special context of Fedora than anyone else. The design of the FPCA originated with Tom, and the Fedora Board has gotten behind it. Cf. minutes of recent Fedora Board meeting:

I don't see why a distro needs any form of contributor agreement at all. A distro aggregates a collection of software packages, all under different licenses. The FPCA strikes me as extraordinarily heavy-weight for this context. Patches to software packages should be submitted upstream, under whatever terms the upstream project considers appropriate.

Ubuntu has only the <a href="">Code of Conduct</a> which has everything to do with being a responsible community member, and nothing to do with software licenses.

Fedora does more than just aggregate software packages - the FPCA may cover documentation, wiki edits, artwork, as well as RPM spec files. However, I agree that a distro project doesn't need a contributor agreement, and I'm glad you have made that point. Perhaps the main reason why Fedora has the FPCA at all is historical: it used to have another one (the old Fedora CLA, based closely on the Apache Software Foundation's ICLA), and the FPCA originated as an effort to correct the flaws of the old agreement. I have heard a number of past critics of the old Fedora CLA express approval of the FPCA.

Although I was the principal drafter of the FPCA, today it strikes me as a bit heavyweight (I wouldn't say "extraordinarily" as it is still a remarkably minimalist contributor agreement :). I was at an earlier stage of my thinking on this subject during the main period of my work on the FPCA with Tom Callaway.

You and <a href="">Dave Neary</a> have saved me the bother of documenting my own concerns with Harmony (where I participated as an act of mitigation rather than endorsement). All the same, when clients ignore all of my arguments on the subject I will probably suggest they use the Harmony agreement (License version, with the community-selected license explicitly identified as the outbound license) rather than write their own.

Something you've not mentioned in detail is the community reasons not to have these kinds of agreement. I've written on the subject from both <a href="">a community</a> and <a href="">a corporate</a> perspective.

I address some of that in the forthcoming Part 2, though you are better at explaining those things than I am. :-)

Will you also be covering the cases where organisations (Apache and Plone come to mind) appear to have put contributor agreements to good use?

I'm focusing on Harmony in this article. I note in this Part 1 that there are what I call "minimalist" contributor agreements. These do not raise the problems that maximalist varieties (like Harmony) do.

I confess I'm not familiar with Plone's approach but I'll look into it. I think Apache is a unique case. Its CLA is formally maximalist, but as used by the ASF it is effectively harmless since it is essentially duplicative of the outbound license used by ASF projects. See my article on the new Fedora contributor agreement which I wrote last year: (Fedora's old CLA was based on the Apache CLA).

If this is the Plone contributor agreement of which you speak (pdf) - I see it is based to some degree on the FSF copyright assignment. The Plone Foundation explicitly retains the right to license outbound under non-FLOSS licenses but does commit also to outbound FLOSS licensing (but not just GPL). One possibly significant difference from Harmony is that the FLOSS outbound license commitment seems potentially to apply to all of Plone and not just artificially to the contribution in isolation.

Overall, I'd conclude the Plone agreement is about as bad as Harmony, but probably no worse.

Richard, Having participated in a number of calls and meetings, I find your characterization "cloaked by the Chatham House Rule" a tad sensational. As RedHat surely knows, there were no barriers to join the discussion lists and participate in the meetings, and participants were forthcoming about who they were affiliated with.

That said, healthy debate is just that, for another perspective, your readers can follow Stephen Walli's summation and keep the discussion vibrant:

<p>Paula, I disagree. Early in the process, Harmony meetings were only announced on private email lists, such as <a href="">ftf-legal</a>, that are <strong>quite</strong> difficult to join. Even with 12 years of FLOSS license policy experience, my requests to join ftf-legal have been routinely denied for years.</p>

<p>Therefore, I learned about Harmony only through the rumor mill, and all the information I received about Harmony was only through those rumors until Allison made it a public process in April. Thus, I don't think Fontana has been sensational at all.</p>

<p>Meanwhile, it's still the case that for the pre-April meetings, no one can even tell me which people from what companies were involved in the drafting. I know multiple people who were invited to the meetings (through the lists I mentioned above and some of whom were my source of rumors), yet they <strong>remain</strong> forbidden from telling me anything due to the Chatham House Rules (a ruleset wholly inappropriate for a process intending to make policy for individual Free Software developers).</p>

<p>This has not been a transparent process in the least. Indeed, as recently as this week, it took <a href="">multiple</a> <a href="">requests</a> before the 1.0 documents <a href="">were released</a> in a transparent format.</p>

One thing I didn't address in my article (earlier drafts went into detail but I was trying to conserve space, and even so I've split it up into 2 parts) was my own limited involvement in Harmony, but I'll explain that in this comment.

I attended some meetings as a representative of Red Hat, mostly in the earlier phase of Harmony, and posted a few messages to the private mailing list. My participation was basically observational, especially as time went on, though early on I was graciously invited by Amanda Brock to reprise my LinuxCon 2010 talk which was a skeptical treatment of the subject of contributor agreements (see my slides at I should also note that Amanda Brock encouraged and welcomed my participation in Harmony. (This disclosure does not violate the Chatham House Rule as I read it.)

It is true, despite the Chatham House Rule, Harmony was advertised as being open to all participants (though I have heard of some reports of significant delay in getting interested participants subscribed to the private mailing list). Nevertheless, I believe "cloaked" is an accurate description. In retrospect, I think the Chatham-induced secrecy of Harmony diminished its chances of success. One of the reasons why the Chatham House Rule is problematic, I have found, is that it tends to be self-interpreted in a stricter way than the actual formulation of the rule might suggest.

I'm not sure why it's difficult to join a mailing list when the only requirement is "ask to join". But, based on feedback after the Alpha release, we switched to entirely public mailing lists with entirely public subscription webforms.

I agree Chatham House Rules were an unfortunate choice. They sound nice and open, encouraging collaboration, but in actual practice they're pretty difficult to work with.

The format of the documents wasn't about transparency, it was actually about my technology blindness. Creative Commons only offers the license picker tool, it didn't occur to me that people might want plain, old-fashioned, static PDFs of the Harmony templates. (I still can't imagine what people are going to use them for. Harmony is a template, you have to modify it before using it, so what good is a static PDF?)

I agree about the continued, dark and spooky "Chatham House Rule" references. After hearing about all this darkness and secrecy on, I signed up on the mailing list in Jan 2011 and have lurked there ever since.

Don't know if the idea is that everything had already been set in stone by then, but it certainly didn't seem that way.

I've seen much talk of how Harmony is going to trick developers, but the phrase Copyright Assignment Agreement tells all. If you sign a copyright assignment agreement, you are agreeing to assign your copyright.

Sure, legalese can be tricky, but the anti-Harmony folks ought to give developers some credit...

Sorry to hear about your experience Bradley, I joined the mailing lists without fan fair in June 2010 and have received well over 450 emails as part of the discussion list. I had no knowledge of the ftf-legal list you referenced.

<p>I assume by <q>mailing lists</q> here you refer specifically to the (now deprecated) private Harmony mailing lists, and <strong>not</strong> the other private mailing lists (like ftf-legal) that I referred to (i.e., the original places where invitations to the private Harmony lists were sent).</p>
<p>I am not surprised at all that as a leader of a Microsoft-backed trade association, you were explicitly invited to Harmony. From my perspective, by the time invitations found their way into public (sometime in late 2010), key decisions were already faits accomplis, and my joining would have been moot by then. Separately, I also object on principle to personally agreeing to Chatham House rules to engage in Free Software public policy-making.</p>
<p>I find it completely ludicrous that the software freedom community might considering adopting policy documents that were primarily developed under these sorts of secrecy rules. I'm sure this sort of process is common for trade associations like Paula's, but such secrecy has historically caused serious problems and confusion in the software freedom community. Paula, you probably remember well <a href="">the problems created by secret decision-making at United Linux when you were involved with it</a>. As you and I both learned then, secret decision-making by consortia done without consulting larger software freedom community only causes problems. Harmony is repeating the mistakes of the past.</p>

Thanks for your comments Bradley, to clarify, I asked to join, I was not invited. Re: UnitedLinux LLC, happy to have a cup of coffee with you anytime for a walk down memory lane. It would be a fascinating case study on why LLC's are not the best structure for a non profit organization.

<p>I am pretty sure your backers (e.g., Microsoft) will already be buying some of the coffee breaks at OSCON this year. If you're there, we should meet up during one of the breaks!</p>
<p>I'm glad to see you don't believe LLC's are a good structure for organizations that want to operate in the software freedom community. I assume that means that you, like me, don't find the Open Innovation Network (OIN) well-structured?</p>

Brandley, stop by the Outercurve booth #918, personally I prefer to buy my own coffee, don't like the mass brewed free stuff.

<p>For my part, I try to avoid the mass-brewed nature of the tradeshow floor as much as possible, so hopefully we'll catch up at some talks. I'm speaking on Friday; I hope you'll come. The coffee at Oregon Convention Center is not too bad and the only coffee for purchase is big-corporate Starbucks, which isn't that great anyway. I guess 501(c)(6) types don't mind BigCorp coffee so much though.</p>

The input=output convention is the easiest for small contributors like me to understand (and newbies). Corporations needs written authorization to avoid legal trouble. Hence, the "minimalist" approach seems to serve both needs optimally. The "maximalist" agreements I would call "scary", and I've avoided them after my first encounter. Kudos to Mr. Fontana for the clear and appropriate terminology for these approaches.

Just a follow-up on the Chatham House Rule discussion, one of the reasons good open collaborative development and free software projects work so well is that decisions made in the past can be reviewed via public archiving. When a decision process of who said what is cloaked with anonymity, it is impossible to later recreate and understand why decisions were made. This undermines the ability for a community to learn, self-heal, and improve. Reasoning of past decisions is left to the memory of those who were present, and we know how inaccurate memory can be.

In most communities, it is a <a href="">good idea to have private spaces</a> for some discussions, but relevant material needs to <a href="">go back to the public space</a> for all to understand and, if not agree with, at least not be surprised by secret reasoning.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.