The trouble with Harmony: Part 2

No readers like this yet.
A community building a barn

Opensource.com

This is the second part of a two-part article critiquing the output of Project Harmony.

Legitimizing the flaws of maximalism

In opting to follow the maximalist model of contributor agreements, Harmony inherits, and thereby legitimizes, all of that model’s problems. There is growing awareness that the maximalist approach can impair the effectiveness of the open source community development model, creating unnecessary barriers to contribution. Rather than attempting to address those problems, Harmony merely hides them in attractive packaging.

One such problem is the departure of the maximalist model from the traditional free software norm of licensor equality. I believe that greater equality among project participants benefits FLOSS by facilitating the growth of vibrant developer and user communities around projects. Harmony’s insistence that the contributor assign copyright or grant a maximally broad copyright license signals that contributors are second-class citizens, undeserving of the same legal power as the project entity. With Harmony’s maximalist predecessors, this problem is exacerbated in the worst instances of the so-called “dual-licensing” business model, where a commercial project entity uses the GPL as its “community” license, spreads unwarranted fear about the GPL, and retains the sole power to provide alternative proprietary licenses.

Another problem is that maximalist contributor agreements, particularly complex ones like the Harmony templates, seem to signal that there is something legally insufficient or doubtful about open source licensing. If open source licensing is good enough for outbound licensing, why is it not good enough for inbound licensing? Why, in other words, is it considered necessary to impose an additional foreign legal layer on top of open source licenses? By legitimizing maximalism, and rejecting the inbound=outbound tradition, Harmony’s drafters call open source licensing itself into question.

The perils of uniformity

One of the stated goals of Harmony is to reduce the supposed proliferation of contributor agreements through a new standard set that is thought to embody best practices. The hope, presumably, is that Harmony will come close to occupying the field, perhaps ultimately supplanting existing contributor agreements and alternative practices, including the inbound=outbound tradition and minimalist approaches.

In this one respect, Harmony reminds me of efforts by two prestigious U.S.-based institutions, the American Law Institute (ALI) and the Uniform Law Commission (ULC), to ‘restate’ and unify the law on various subjects. Most of that work has been of great value. But in the software industry we have twice seen the dangers of an ill-informed push for unification. The ULC’s Uniform Computer Information Transactions Act (UCITA) met with such strong opposition that it was adopted in only two U.S. states. The more recent case is the ALI’s Principles of the Law of Software Contracts, of which Harmony’s chief drafter, Mark Radcliffe, has been a notably outspoken critic.

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.

I therefore apply to Harmony the words its chief drafter himself used to warn the software industry about the ALI’s Principles. If widely adopted, this unified maximalist contributor agreement system may well “have a very negative effect on the open source software industry” and “could have a significant negative impact on open source licensors and contributors”.

The misappeal of Creative Commons

Canonical founder Mark Shuttleworth has likened Harmony to Creative Commons. Given the enthusiasm for Creative Commons among many open source developers, I have expected supporters of Harmony to use that tactic in urging its adoption. There may be some similarities between the Creative Commons license suite and Harmony, but I am not sure those similarities are good.

The Creative Commons suite includes licenses that implement various policies. Some, like CC BY and CC BY-SA, are normatively consistent with corresponding permissive and copyleft families of free software licenses. Others, however, particularly its “NC” (no commercial use) and “ND” (no derivative works) licenses, are in conflict with basic principles of free software and free culture. I am not alone in lamenting the application of the Creative Commons umbrella brand to cover licenses with such disparate qualities. One consequence has been a general confusing dilution of the meaning of “openness” in the context of cultural works. A more specific problem is the evidence of confusion on the part of content authors interested in applying Creative Commons licenses to their works, and resulting confusion by those interested in making use of such works. Too often a work is labeled as being licensed under “a Creative Commons license”, without specifying accurately, or specifying at all, which free or nonfree policy the author sought to apply.

What resemblance Harmony has to Creative Commons raises similar concerns. Giving Harmony the greatest benefit of the doubt, I fear that the application of “Harmony” as an appealing global label to a set of permutations with differing legal consequences will confuse projects and contributors alike. In the context of Creative Commons, those concerns are somewhat attenuated by the nature of the material to which such licenses are applied. From the perspective of open source, the very different legal culture established by Creative Commons is not only tolerated but welcomed as an enormously successful experiment that is safely cabined to non-software content. It might be different if Creative Commons recommended, as it explicitly does not, the use of its licenses for software. Were someone to propose that a seemingly simple Creative Commons-like suite, designed by some central committee, should replace all traditional FLOSS licenses as they exist organically today, it would be quite alarming. I hope that Harmony is not the first step towards such a goal.

Software freedom and responsibility

Readers who have come this far may well ask, “Who cares?” If projects sincerely interested in building communities perceive that Harmony is problematic, they are free not to use it. If contributors perceive that Harmony is problematic, they are free to shun projects that use it. Part of the answer lies in the surface appeal of Harmony, and in its likelihood of causing confusion.

The rest of the answer lies in the backing of Harmony by the prestige of Canonical and its founder, or so I have thought. I have expected Canonical, the company that is behind one of the most popular Linux distributions, and Mr. Shuttleworth, a man with many resources at his disposal, to use their influence to promote Harmony. In the week following Harmony’s 1.0 launch, however, I have seen no pertinent press release from Canonical, nor any supportive statement from Mr. Shuttleworth. This puzzles me, but for now I must suppose that Mr. Shuttleworth has not lost interest in this project. I will assume that we may yet see some effort by him and his company to encourage community and industrial adoption of Harmony.

Canonical and my own employer, Red Hat, are very different technology companies, yet we are united by common cultural origins. We are both authentic products of the free software movement, and in particular that part of it that produced GNU and Linux. Our respective and very different successes give us each a special place in the FLOSS universe. But that special place also implies a special responsibility to conserve and nurture the community development culture from which we both sprang, and to exercise great care not to do anything that might damage it. It is with that responsibility in mind that I say to Mr. Shuttleworth, with all respect, that I cannot join him in any support of the Harmony initiative.

Tags
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.

20 Comments

Richard: The Harmony <a href="http://harmonyagreements.org/about.html">web site</a> is pretty clear in its intentions:

<em>"Contribution agreements are one available tool out of many in an overall legal strategy for FOSS developers, the entities that distribute their work, and the users of their work. We hope that our work will enable more people to contribute code, by reducing the cognitive cost and legal time of reviewing contribution agreements. However, the fact that we're working to improve this one tool doesn't imply that we think it is a necessary part of all FOSS legal strategies. Many successful FOSS projects choose not to use contribution agreements, and we are hearty advocates of those projects, and of a broad variety of strong legal strategies built using a broad variety of tools."</em>

No maximalist approaches claimed. The Eclipse Foundation, ASF, Linux Foundation (and Outercurve Foundation for that matter) all take different approaches. None of them claim to have the one true approach.

There's a corollary to <a href="http://oreilly.com/pub/wlg/526">Tim O'Reilly's version of freedom 0</a>: It is up to any contributor to understand the terms under which they're contributing to a FOSS project.

The Harmony core team have tried to provide a set of agreements that are very simple in what they state and the language used to state it, as well as the supporting guidance and FAQ, so developers that encounter them will hopefully have a better chance of understanding what they're signing regardless of whether they choose to involve counsel or not.

Dave Neary's excellent blog post discussing his concerns about developing communities and CLA also puts them in context:

<em>"Among the most common superfluous barriers to entry that you find in free software projects are complicated build systems or uncommon tools, long delays in having questions answered and patches reviewed, and unnecessary bureaucracy around contributing. A JCA fits squarely into that third category.

In a word, the core principle is: To build a vibrant core developer community independent of your company, have as few barriers to contributing as possible."</em>

We live in a world where well run FOSS projects are transparent. Organizations that choose to abuse trust in the FOSS world generally get caught out and punished by a lack of participation. I still believe the Harmony documents are a better solution to the narrow problem they attempt to solve than the free-for-all we currently enjoy.

What problem is Harmony trying to solve?

I think the answer to that question is what disturbs a lot of folks.

The Harmony project is the second attempt by Canonical to get Debian developers to assign copyright to Canonical so it can sell Ubuntu.

Mark Shuttleworth understands the business value of Debian's software but Debian's strong Social Contract prevents him from scooping up all of Debian and reselling it - like Red Hat did with Red Hat Linux. Canonical wants to make Ubuntu profitable and to do that it needs to have some perceived value and as long as Ubuntu is Free Software, Canonical will have a hard time communicating that perceive value. One option is to create secret sauce from the free Debian bits. But to do that you need to move the software to a more permissive license, and to do that you need copyright, hence Harmony.

How does Debian's social contract prevent the resale of Debian? Isn't Canonical essentially reselling Debian today with Ubuntu LTS?

The Debian Free Software Guidelines don't seem to have a problem with it, but perhaps I'm misunderstanding?
<cite>
Free Redistribution

The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license may not require a royalty or other fee for such sale.
</cite>

I don't think that Debian's social contract prevents its resale. It is just that there isn't a lot of perceived value in Ubuntu if you can get it for free by downloading Debian.

I don't think there is any problem with your understanding - rather it might be me who is merely speculating. But why does Canonical want copyright assignment if is not going to change the license of the copyrighted software? And isn't the need to assign copyright a way to get around strong copyleft licenses of which there are a lot in Debian?

Yeh, I've personally found myself drawing a similar conclusion. When I ask myself, "What problem is Canonical trying to solve with Harmony?" the only answer I can guess at that makes sense to me is "Take advantage of copyleft licensed-code without having to respect copyleft."

This is pure speculation, though. It's not clear through any of the Harmony-related things I have read what the actual problem they are trying to solve is, so all I have is my guess.

<cite>When I ask myself, "What problem is Canonical trying to solve with Harmony?" the only answer I can guess at that makes sense to me is "Take advantage of copyleft licensed-code without having to respect copyleft."</cite>

They don't need Project Harmony for that -- they already have CLA's in place for all their major software projects.

There are 2 major use-cases I can see for a project like this. The first reflects the fact that there are already in place a whole bunch of commercial software companies who insist on a maximalist CLA for contributions to their FOSS projects. Whatever their reasons for that (dual-licensing, open core, other not-very-nice reasons...), it's convenient to have in place a standard agreement which everyone uses and whose terms are widely known and understood.

In the same way it would be convenient to have a spectrum of steadily more contributor-friendly agreements, so that contributors don't need to check the details of a project's CLA but can just check which of a set of standard agreements it is. (This is where I see the potential analogy to Creative Commons: whatever the frustrations of the noncommercial or no-derivatives licences, they do at least provide an easy frame of reference for a set of different licensing conditions.) It would also provide a nice frame of reference for the community to judge the true openness of a project.

The second application I see is in facilitating the open-sourcing of currently proprietary software projects. As we know from the case of Sun trying to open-source Java this can be a very drawn-out and complicated process. Issues include proprietary dependencies that can't easily be removed, ongoing commitments to provide proprietary-licensed versions to clients, and so on -- things that make it impossible to permit outsider contributions to the project without a maximalist CLA.

A spectrum of standardized CLA's ranging from maximalist to something like the Linux DCO would provide a good framework within which commercial projects could incubate the process of open-sourcing, from the initial getting-rid-of-proprietary-obligations stage to building equitable and meritocratic development communities.

I don't say that Project Harmony necessarily fulfils these goals, but these are definitely valid use-cases for the kind of work they are doing.

The Harmony project is the second attempt by Canonical to get Debian developers to assign copyright to Canonical so it can sell Ubuntu.

Mark Shuttleworth understands the business value of Debian's software but Debian's strong Social Contract prevents him from scooping up all of Debian and reselling it - like Red Hat did with Red Hat Linux. Canonical wants to make Ubuntu profitable and to do that it needs to have some perceived value and as long as Ubuntu is Free Software, Canonical will have a hard time communicating that perceive value. One option is to create secret sauce from the free Debian bits. But to do that you need to move the software to a more permissive license, and to do that you need copyright, hence Harmony.

Richard, thank you for writing Part 2! Part 1 is a good introduction to a range of theoretical problems related to Harmony, but Part 2 really makes the problems concrete for me. In particular these two sentences really caught my attention:

<cite>
With Harmony’s maximalist predecessors, this problem is exacerbated in the worst instances of the so-called “dual-licensing” business model, where a commercial project entity uses the GPL as its “community” license, spreads unwarranted fear about the GPL, and retains the sole power to provide alternative proprietary licenses.</cite>

<cite>Another problem is that maximalist contributor agreements, particularly complex ones like the Harmony templates, seem to signal that there is something legally insufficient or doubtful about open source licensing.</cite>

These are serious issues! Thank you for uncovering them.

Michael: I deeply respect your viewpoints. I also know that you are well read. Please go read what <a href="http://harmonyagreements.org/about.html">Harmony has to say for itself</a>. It makes no such maximalist claims. And then read the agreements. They can be used as license templates as well as assignment templates.

The best example of the notorious "dual" licensing business model was MySQL and I never saw anyone from MySQL AB scaremonger the GPL. The FSF was more than willing to ensure everyone understood the unchallengeable hard-line ethos of software freedom.

Lastly, your Roosevelt quote is perfect. Not just one man, nor one party, nor one nation, but the cooperative effort of the whole world. I participated on the edge of Harmony since last September. There were a lot of companies and individuals represented in the room, not just Canonical. I didn't see a lot of participation from Red Hat. I appreciate Red Hat and Canonical compete in the marketplace, but they have both contributed enormously to our industry in their products and through the actions of their employees in the FOSS world. Indeed, it takes all kinds of viewpoints.

<p>Stephen, MySQL AB users <strong>still</strong> come up to me at conferences (as recently as LinuxFestNorthwest 2011) and tell me that they've been told by MySQL AB (now, the stories are Oracle) that they need a non-GPL license even for having ANSI SQL statements embedded in their code, even if the code works fine against both Postgres and MySQL.</p>

<p>As Simon Phipps <a href="http://identi.ca/conversation/76144180#notice-78692974">notes over on identi.ca</a>, MySQL AB was careful to do this privately with &ldquo;customers&rdquo; (read: shake-down recipients).</p>

<p>This situation is what convinced me that it's dangerous for any for-profit company to do GPL enforcement. Of course, non-profits can be corrupt, but GPL enforcement as a for-profit business model encourages as maximal reading of what is and is not a derivative work as your &ldquo;sales&rdquo; people believe they can get away with.</p>

I've always considered this the hidden "gotcha" of the copyleft strategy. By maintaining tight control over the source code, even though the intended purpose is to use that control to enforce software freedom, it also grants the power to abuse that control. Permissive licensing strategy, on the other hand, levels the playing field by giving equal access to all, but at the same time gives away all power to enforce the behavior of redistributors.

I'm not arguing in favor of either copyleft or permissive here, BTW, just recognizing the inherent paradox of both strategies.

<p>Allison, It really doesn't make sense to say you're not arguing against copyleft when you say it has &ldquo;gotcha&rdquo;s. The fact you bring up, meanwhile, is not part of the nature of copyleft, it's part of a single place of copyright or CLA control that cannot be trusted.</p>

<p>Linux, for example, will never have this problem due to many copyright holders. FSF, in my belief, will never have this problem due to the promise-backs in its &copy;AA, its non-profit mission, and leadership. Yet, I still see why people don't trust FSF even though I do. Centralized control can make copyleft dangerous if the control is abused.</p>

<p>Abuse happens when problematic CLAs and &copy;AAs (such as most of Harmony's options) are used with copyleft projects. It's not part of copyleft's nature by itself. For you to say the latter is to argue against copyleft. It's your right to do so, but please don't try to pretend you aren't arguing against copyleft.</p>

Hi Bradley: Sorry to hear MySQL AB treated it's customers so poorly. And Oracle sales execs suggesting including an ANSI standard language statement that talks to an RDB in the app (even MySQL) triggers the GPL is sad commentary indeed. You are likely in a better position to hear from such folks as I. I've no problem with for-profits defending their software licensing terms if they use the GPL, but I would obviously want them to do it "properly" and not lie to customers.

<p>Stephen, it is certainly true that Canonical was not the only participant, but from what I observed on the sidelines the group of active participants was fairly small at the beginning and got progressively smaller as time went on. Also, notably, for-profit corporations were overrepresented and the class of noncorporate contributors to open source projects was severely underrepresented (at best). We only have three months of publicly archived mailing lists for Harmony, but consider the minutes of what seems to be <a href="http://lists.harmonyagreements.org/pipermail/harmony-drafting/2011-June/000052.html">the most recent Harmony drafters' meeting</a>. Four attendees: 2 Canonical lawyers, a Canonical employee who is participating based on her personal interest, and you.</p><p>I have explained that my limited participation in Harmony was largely observational (despite the much-appreciated efforts of Canonical's Amanda Brock to encourage my involvement), but I suppose I haven't quite explained why. It is really because from the start Harmony was oriented towards a maximalist legal model and I was moving in entirely the opposite direction, based on my experiences as Red Hat's open source licensing counsel, in contexts where Red Hat was contributor as well as contributee, and based on what I had learned from the writings of people like Michael Meeks and Simon Phipps. So really from the outset my view was, admittedly, rather negative:&nbsp; "how much harm could this unwise initiative actually do to open source and free software?".</p>

Hi Richard: Thanks for the clarifications. That last meeting to which you refer was certainly poorly attended and short because of it. I've no idea what happened.

Simon has raised excellent concerns along the way. A developer better understand what they're signing away. But that's been no different for the past 25 years since the FSF first put their assignment process in place.

Your presentation last September was well received. I think being able to work with the Linux DCO process as a minimal process approach would be great if we could all keep the nasty players from our doors. Unfortunately we don't always get to play that way.

While I agree that developers should "understand what they're signing away", a point you've made elsewhere, I think this itself points to a problem. Maximalist contributor agreements typically contain provisions that are not customary in outbound FLOSS licenses. I believe that ethical concerns are potentially raised when an individual developer, likely without access to counsel, is expected to sign an agreement containing unfamiliar legalese carrying significant legal consequences that run to the benefit of some more powerful and sophisticated entity. In this concern I do not think I am in disagreement with Canonical's lawyers, actually. I do not agree that Harmony provides a solution, let alone a good solution, to this problem.

Regarding the issue of "nasty players", I simply don't see this as a significant problem in open source, certainly not enough to justify a fundamental alteration in prevailing models of legal governance. If the issue is really a matter of (mis)perception by corporations initiating open source projects, perhaps those corporations are not ready to get involved in open source in that capacity (and should focus on being contributors to upstream projects first).

Michael, I hope that you and others will take the time to read the agreement templates before reaching any final position on them.

Collecting code from a group of contributors is a very different act than distributing code to a group of users. It involves different legal considerations, responsibilities, and consequences. That doesn't mean that open source licenses are inadequate. They are designed for a particular purpose, distributing code to users in an open way. They aren't intended to cover the details of collecting code from contributors. It would certainly be possible to bake the details of contribution into the distribution license, but the resulting monolithic document would be unnecessarily complex.

The inbound=outbound strategy works for some projects with some contribution policies. But there are also other open projects with other open contribution policies, where a simple inbound=outbound is inadequate. Harmony is simply a tool to help projects who want a little more clarity in the relationship between the contributor and the project to navigate some of the possibilities that fit with an open contribution policy.

I'm reminded here of the unjustified criticism that OSI received in the early days as being "<a href="http://www.gnu.org/philosophy/free-software-for-freedom.html">against freedom</a>". Harmony is not a political agenda, it is certainly not fear-mongering against the GPL, and it is not an attempt to dominate the world with proprietary licensing. Like the OSI, Harmony supports both copyleft and permissive strategies, the full diversity that is the open source community.

<p>Allison, I spent the entire July 4th holiday weekend of 2011 studying the Harmony agreements, and <a href="http://ebb.org/bkuhn/blog/2011/07/07/harmony-harmful.html">I wrote extensively about my analysis</a> after I diffed the 1.0 drafts against the Beta drafts in the following week after that. I'm certainly not among the others you reference that haven't studied them. I know that Fontana is not either, as he studied them as well. I can't speak whether Michael is or not.</p>
<p>Nevertheless, I've told you many times that many of us, including me, believe that CLAs and &copy;AAs are moral documents. The implement a moral policy for a FLOSS project.</p>

<p>Therefore, any set of documents that try to implement moral policies for FLOSS projects are going to have a political agenda, even if that political agenda is an amoral one.</p>

Brad, indeed, I know from talking on identi.ca over the past few months that you and Fontana both have spent a great deal of time thinking about Harmony. I doubt others will invest as much time, but I hope they will read the documents and judge them on their own merits.

As you know from our conversations, I'm very uncomfortable elevating legal documents to the level of "morality". I think it puts far too much power in the hands of the law. I much prefer to have the "morality" vested in the project policy and governance, and keep the legal documents in a lower status position as mere tools for enacting small parts of that governance.

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