Harmony 1.0 Reflections

The month before the Harmony 1.0 release was quiet, and I was starting to wonder if anyone other than the drafting group was even paying attention any more. So, I was pleasantly surprised to see the posts start to appear last week after the Monday release. Some more positive, some more negative, but the most important thing right now is that people are engaging with Harmony, thinking through what the agreement templates mean, and how they fit in the general FLOSS ecosystem. So far I’ve read posts by: Bradley Kuhn, Dave Neary, Jon Corbet, Mark Webbink, Richard Fontana (part 1 & part 2), Simon Phipps, Stephen Walli and a Slashdot mention (glad for links in the comments if you come across others). I’ve observed a few common themes, so I thought it might be useful to take a step back and ponder through them.

Who’s the leader?

Various posts talk about Canonical leading the project, or Amanda Brock, or Mark Radcliffe, or me. For the first few months I was involved in Harmony, I thought it was lead by the SFLC. The surface question seems to generally be whether the “leader” influenced Harmony in a direction against the poster’s philosophy. But there’s a deeper question here: How is it possible to have so many different ideas of who is leading Harmony? Shouldn’t it be immediately obvious who the leader is? The answer is that Harmony has no leader, and since there is no leader, any member of the group looks as much like a leader as any other member of the group. Simon put it best, calling Harmony “the work of a loose grouping of people”. If that seems strange, think about this: In a group made up of so many radically different philosophies, including several who publicly state that they only got involved to keep the process from going off the rails, who would we choose as leader and how would we choose them? Is there anyone in the group who could adequately represent all the diverse perspectives? Anyone who could stand as neutral arbiter? I deeply respect the group of FLOSS lawyers and advocates who have participated in Harmony, and have only grown to respect them more over the past year, but there’s not one person I’d put in that position. Honestly, it’d be some form of cruel and unusual punishment to give anyone the responsibility of herding the rest of us cats. A second thing to think about is whether a group like Harmony really needs a leader. Of the FLOSS lawyers and advocates you know, are any of them shy about expressing their opinions? Do any of them seem likely to hesitate to negotiate for fair representation of their philosophy? The Harmony process works because it’s a table of equals speaking their minds. It could not have worked any other way.

I don’t have confidence in the Harmony documents because of some blessing from some authoritative leader. There is no blessing, no authoritative leader, and if you get right down to it, no one in the world I would want to be that leader or give that blessing. I have confidence in the Harmony documents precisely and only because they were born out of the chaos of collaboration.

What’s the agenda?

As some posters/commenters have pointed out, the Harmony agenda is stated plainly on the project’s website: “We hope that our work will enable more people to contribute code, by reducing the cognitive cost and legal time of reviewing contribution agreements.” It talks about how contributor agreements are “one available tool out of many” and not “a necessary part of all FOSS legal strategies”. So, the public agenda is clear and obvious. But, there’s been speculation about a hidden agenda, or an agenda behind the agenda. Why is that? Why is the simple and obvious answer not enough? I would guess it’s because the posters are students of human nature and know how complex and multi-layered human motivations usually are. The public statement is so straight-forward that they figure there must be more to it, and so speculate on the possibilities of what “more” might be there. I can pretty much guarantee that there are other agendas floating among the Harmony participants. Probably at least 200+ completely different agendas for the 100+ participants, many of them entirely incompatible. I don’t know all the deep and varied motivations of everyone involved (though I know enough to be confident that none of the speculations I’ve read so far are accurate).

The statements on the public website are the set of things that the Harmony drafting group agrees on. We spent a great deal of (probably too much) time hashing those out early in the Harmony process. The reason the public statement is so straight-forward is not because it’s hiding some big secret agenda, it’s because Harmony is so diverse that the simple stated goals are all that we could 100% agree on. For students of human nature, this won’t be too surprising either. Collaboration is rarely about gathering people who agree on absolutely everything, it’s mostly about gathering people who agree on a small set of things, to make progress on that small set.

Do the Harmony agreement templates meet the stated goals for Harmony? I believe they do, but I hope you’ll read them and decide for yourself.

What do they mean?

Some of the discussion has ranged around what various parts of the agreement templates mean, or what it means that various things aren’t in the templates. I’ll touch on a few key points.

• inbound=outbound: I won’t argue against the “inbound=outbound” strategy, because I think it’s a good one, and works well for many projects. But, I will argue that it’s not the only valid legal strategy within the realms software freedom. There are reasons to choose inbound=outbound, and reasons not to choose it. If an inbound=outbound strategy is right for your project, you should use it. And if you do, I encourage you to take a look at the Linux Kernel Developer Certificate of Origin (DCO) as an example. In the short-term, part of my 1.0 todo list is to create a page about inbound=outbound for the Harmony website, and I’d welcome contributions to it. In the slightly-longer-term, even though drafting a DCO-style template was more than we could manage for 1.0, there was definite interest in the Harmony drafting group. I’d personally be interested in collaborating on something like this. If you would find a general DCO-style template useful, or would like to work on drafting one, please say so.

• Copyright accumulation: There are various ways of talking about it, but one of the fundamental facts of FLOSS contribution is the process of assembling a collection of small bits of code from various sources into one big body of code. Some pieces are relatively independent of the whole, and could usefully stand alone. But for the most part, especially with maintenance work and refactoring over time, the contributions of any one person aren’t particularly useful separated from the whole. This is a beautiful thing about FLOSS, the whole is greater than a simple sum of parts. By copyright law, the default rule in place for all copyrightable work is “only the author has the right to distribute”, which means the project only has permission to distribute the contributors’ work because the contributors have granted that permission. Also by copyright law, the whole collection is itself a copyrightable work, owned by whoever assembled it (a “compilation”). These basic facts apply no matter what contribution policy a project chooses, no matter whether they’ve defined any policy at all. The contribution policy layers on top to more clearly define what kind of permission the contributors are granting the project and what they get in return. When you work on a project with no defined contribution policy, don’t make any assumptions about what the “implied” policy really is. Sometimes it’s inbound=outbound, but sometimes it’s a much older common FLOSS strategy of an original founder or foundation owning the compilation copyright. Fontana talks about how common inbound=outbound is, but in actual fact what’s common is not providing any clarity at all about the contribution policy, not even a simple web page stating “we assume you’ve given us permission to use your contributions”. That complete lack of information is a great disservice to contributors. The Linux Kernel DCO or the Mozilla Committer’s Agreement are good examples of how to be clear with contributors about an inbound=outbound contribution policy. Beyond inbound=outbound is every other possible way of granting permission for the project to distribute the code. Simon speaks against copyright assignment, and there are good reasons not to choose it. In Harmony, 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. If your project is going to adopt copyright assignment, and there are good reasons to choose it too, this is the best way to do it. Fontana talks instead about “maximalist” contributor agreements, where a project collects inbound permissions from contributors that are broader than the outbound permissions granted to users. There are good reasons for this too, in addition to the unhealthy reasons he mentions. Both talk about the inequality of rights held by the project versus the rights held by the contributors. But, that inequality lies in the fact that the project holds a collection of code, while the contributor holds a few pieces of that collection. All forms of collaborative development are copyright accumulation, there’s no way around it. The act of entering a group project is one of establishing a set of relationships with all the other contributors, which may include some form of legal entity. It’s all about building bonds, and trust, and confidence in this group you’ve adopted, and there’s no way around that either. I’m skeptical that the ultimately very thin differences between DCO/CLA/CAA contribution policies actually have much impact on the overall hurdles for joining a collaborative group or on the overall equality of the situation. Those fine differences will be important to some people, and I encourage people to adopt policies they’re comfortable with, and contribute to projects they’re comfortable with. But, I also ask you all to be charitable to others who have made different choices.

• Outbound copyleft license: Harmony offers 5 options for outbound licensing. Fontana points out that only two of these options are a restriction to “only copyleft”. True enough, but this doesn’t mean copyleft licenses are underrepresented. One of those two options (a specific list of licenses) is flexible enough to handle any possible combination of copyleft licenses that a particular project considers compatible with their philosophy. A few months ago, I was hoping for a rigorous legal definition of “copyleft”, that would capture just exactly the set of “true copyleft” licenses, and exclude all others. I even tried drafting some language, but any way of wording it failed to accommodate the fact that different projects have different definitions of what they consider “true copyleft”. Some are only GPL (or even only a specific version of GPL), some include AGPL, some LGPL, etc… The option for a specific list of licenses is a simple (I’d even say elegant) way to capture this diversity, giving each project a fine-grained knob to tweak on their “level” of copyleft. The other option (“FSF recommended copyleft licenses”) provides an updating list of copyleft licenses, which some projects may prefer for “future proofing”. Note from Mark Webbink’s post that a Harmony CAA with a strong copyleft outbound license option is actually a stronger guarantee to contributors than the FSF’s CAA, which only promises some copyleft or permissive license.

• Outbound permissive license: Of the 5 options, two are permissive. One is an updating set of OSI approved licenses (again, for “future proofing”) and the other is more generally permissive. Fontana talks about “the appearance of constraining outbound licensing”, as if the permissive options will sneak by unwary developers. This is something the drafting group took great pains to avoid, being very explicit about the types of licenses each option allows (e.g. “copyleft and permissive” for the OSI option). It’s also worth noting that the generally permissive option is also a bit copyleft, obligating the project to release a contribution under “the current license”. In the calls where we discussed it, this was considered by many drafters to be an important expression of developer’s rights, and a step ahead of existing permissive strategies. (I’m glad it made it in.)

• Outbound current license: The fifth option for outbound license is “the current license or licenses”. I suspect this may be a less popular option, because one of the big advantages of a CLA/CAA is flexibility for future changes. If your project plans to release always and only under one license, or is willing and able to invest the effort to get a separate signoff from contributors for a license change, you may find that inbound=outbound is actually closer to your needs.

• Incorporated feedback: Brad commented that the “1.0 documents differ little from the drafts that were released in April 2011” in support of the idea that they’re “primarily documents drafted in secrecy”. I asked about this and it turns out he ran a diff from Beta to 1.0, and so missed all the changes from Alpha to Beta, which is when we got the most feedback. Here’s a diff from Alpha to 1.0, showing that the changes in response to the public review periods were quite extensive, with only 21 lines of text (less than 10% of the total) remaining unchanged from Alpha to 1.0.

What happens now?

I expect that over the next year a handful of projects will adopt Harmony agreements. That may not sound like much, but I consider my time on Harmony well-spent when I count the collective human-years that will be saved from drafting and redrafting contributor agreements. That time can be much better spent on community building, documentation, coding and everything else that makes FLOSS projects great. Some posters expressed concern that the mere existence of Harmony might divert some projects from one philosophy or legal strategy to another. I just don’t see that happening. The community of FLOSS developers are some of the most legally aware and opinionated non-lawyers on the planet. Harmony will be useful to those projects who would have adopted a CLA/CAA anyway, or for projects who already have one and are looking for an update. Dave Neary commented in closing “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.” I completely agree. I’m pleased to see the various efforts for copyright reform, as I think one of the fundamental problems within FLOSS is that we’re trying to build a system of open distribution on top of copyright law, a system that was inherently designed to be closed. I’m in favor of copyright reform, but realize that the law changes slowly and only with enormous effort. On the whole, that slow pace is probably a good thing for the stability of society, but it means there are a few areas where society has changed quickly and radically, leaving the law trundling along to catch up. I also recognize that there’s economic/political pressure to make copyright more closed rather than more open, and it’s not clear who will win. There’s another idea floating around that I know has been an inspiration for some people involved in Harmony. Right now, FLOSS contribution is all about taking your piece of code and granting permission to one project to distribute it. What if, instead of making individual agreements with individual projects, developers could contribute their code into a kind of “FLOSS commons”, together with annotations on how the code may be distributed. Instead of figuring out each new project’s contribution policy, a developer can just check whether the tags requested by the project are compatible with the tags they’ve chosen. And instead of endless discussions on whether license A is compatible with license B, so library X or algorithm Y can be included in code Z, projects could just check if the code was tagged for their intended use. I don’t know if the idea will ever fly, but if it does, something like Harmony (or future versions of Harmony) could be one of the ways that code flows into a system like that, where Harmony’s “options” turn into tags a developer puts on their own code to identify the forms of distribution they want to allow. Interesting potential there.