Join the 85,000 open source advocates who receive our giveaway alerts and article roundups.
The trouble with Harmony: Part 1 | Opensource.com
The trouble with Harmony: Part 1
Get the newsletter
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 opensource.com. 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.