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.

[This post represents my own memories of my own experiences. All stories have multiple sides, multiple perspectives, multiple angles, so if you’re interested in the story you should talk to other people involved in this first year of Harmony.]

I first heard about Project Harmony around the end of May last year when Amanda Brock sent a message to the FLOSS Foundations mailing list, inviting people to join some face-to-face and phone meetings around FOSS contributor agreements. Not a whole lot of detail, but the general gist was “Wouldn’t it be nice if we could do something a little more like Creative Commons, so projects don’t have to spend so much time creating contributor agreements, developers don’t have to spend so much time to understand them, and lawyers don’t have to spend so much time figuring out if they can approve employee’s requests to get them signed so they can contribute?” This got my attention. I’ve been a long-standing advocate of easy-to-understand legal language, a position I’ve held firmly through the drafting of the Artistic 2.0 license and the Perl contributor agreement, and through my participation on one of the GPLv3 review committees.

At the beginning of Harmony, I wasn’t involved with Canonical, though I’ve been an Ubuntu user and packager almost from the beginning of the Ubuntu project, and a number of my friends work at Canonical. I didn’t know Amanda, didn’t even remember hearing her name before. But, Harmony looked like it had interesting potential, and that was enough for me.

The first few meetings struck me as a little odd. They felt like political grandstanding, a lot of flash with little substance. It reminded me of the GPLv3 review committee phone calls. I kicked in ideas–I can debate like a lawyer even though I’m not one–but I didn’t have the sense that it was going anywhere. Looking back, that was an important first stage. It was how we all got to know each other, where we all stood, what was important to each of us, what we were there to support and to protect. It was a process of embracing chaos.

The group decided to adopt Chatham House Rule for our discussions. I’d heard of it before, but never actually used it. At first glance it seems quite sensible: encourage open participation by being careful about what you share publicly. But, after almost a year of working under it, I have to say I’m not a big fan. It’s really quite awkward sometimes figuring out what you can and can’t say publicly. I’m trying to follow it in this post, but I’ve probably missed in spots. The simple rule is tricky to apply.

At the second face-to-face meeting in early July, the massive block of email CCs that we’d been using to communicate was replaced by a mailing list. Someone brought a discussion piece to the meeting (no name, because of Chatham, but it’s already public knowledge that they were affiliated with SFLC, to my knowledge participating in Harmony as an interested volunteer). It was explicitly not intended as a first draft, but it did read very much like a contributor agreement, though rather too dense. The idea of drafting in options started to take hold. The sense was that we, the Harmony community, were not any kind of authority to say what was “right” or “wrong” in FOSS legal strategies. We were, instead, a rich collection of experiences in FOSS law and could help by explaining what choices FOSS projects could make, and the reasons they might pick one alternative or another. The agreements would then reflect the best practices around the various alternatives, basically “if you make this choice, here’s what experience has shown is the best way to do it”.

Through the rest of July, I was completely absorbed by OSCON planning. This blackout-month before the conference has been pretty common for me every year since I took on OSCON, and talking to other conference organizers I hear it’s common for all of us. In August I took a new job at Canonical and dove straight into “drinking from the firehose” to increase breadth and depth on my knowledge of the distro architecture. I also moved from the UK back to the US, suddenly and unexpectedly, as a visa requirement for taking the job. All that is to say, I was quite busy for a few months, and as a side-effect I didn’t really track what was happening in Harmony. I made it to a phone call or two, a face-to-face meeting in Boston, and half-way followed the mailing list, but I was mostly out of it. And, if I’m being completely honest with myself, I have to say I pretty much lost interest in Harmony during those months. I haven’t made any secret of the fact that I had a bad experience in the GPLv3 process. As a committee, we worked hard thinking through the issues and making suggestions, and as far as I can tell none of those suggestions for clarification, simplification, corrections, or perspectives on the needs of the free software community made it into the final draft. The final text released as the GPLv3 is, to me anyway, entirely disappointing. I saw Harmony going the same way. Those first drafts, intended as a seed for discussion, became the real drafts. They were bloated and dense legalese, and even though we had healthy discussions in meetings or on the mailing lists, somehow they didn’t seem to have any visible impact on the documents.  In my mind, and it was probably entirely unfair, I figured that since I had a bad experience with the GPLv3 process, and was having a similar bad experience in Harmony, that the similarity probably wasn’t a complete coincidence, and might just be rooted in the drafter. <shrug> I can’t really say for sure, but I do know that my suspicion killed my motivation to participate. I’ll call this the start of the “Dark Ages”.

At Linux Plumbers Conference in November, Michael Meeks gave an excellent keynote about LibreOffice, that I attended with interest because we’d already started talking about shipping LibreOffice instead of OpenOffice.org in the 11.04 release of Ubuntu. In the talk, he mentioned Project Harmony in an unfavorable light. I don’t remember the details, but it was something about companies pushing an agenda of copyright assignment. The comments really baffled me, they didn’t seem to fit at all with my experience of the process or the goals of any of the participants. Even after chatting with him over a group dinner (a fun evening, I found out his wife and I used to work for the same non-software non-profit organization), I still couldn’t reconcile the gap between what I saw and what he saw in Harmony. I was going to set it aside as “somebody else’s problem” when a friend who I deeply respect and admire took me aside at Plumbers, and expressed concern about Harmony. I promised that I’d look into it.

So, I started asking tough questions, and what I found was both better and worse than I expected. I found that no one at Canonical had a bizarre agenda to force copyright assignment on the world. I also found that Canonical had an interest in replacing their current contributor agreement with a Harmony one, and that “success” for them was measured in community-driven, community-approved, and community-adopted agreements. All good. I also found that Harmony was pretty much stalled, all meetings on hold, waiting on a draft with some changes requested by the Harmony group (substantial changes, but shouldn’t have taken terribly long). Not good.

In a message to the Harmony list just before the mid-December face-to-face meeting, someone (again, no name for Chatham) said that SFLC would no longer be drafting the Harmony agreements. The general gist was that someone (again no name) had a bigger idea for how to improve the current system of FOSS contributions and copyrights, and that Harmony wasn’t enough of a solution. No animosity, wishing us the best of luck, with some possibility that Harmony versions 2.0 or 3.0 might play a part in a longer-term vision. I genuinely believe there was no ill-will in their parting as drafters. I still don’t know the reason for the drafting delay. Maybe they just got swamped with other projects, they do offer pro-bono legal services to the free software community at large, and tend to be quite busy. It is what it is.

I have the feeling that Harmony could have fallen apart at that point. Stalled for something like two months, the drafters bailed, rumbles of public criticism, and nothing to show for 6 months of work. You might think the tone of that face-to-face meeting would be a little dark. Instead, the universal reaction of the group was more like a head-scratching “Huh. That was odd. What next?” We had the seeds of something really good in Harmony, I had a deep sense this was true, and saw it reflected in the faces around me. We decided to reboot, set a schedule for release, go public, and pick a new drafter. A few participants said they’d find out if their companies could help fund the drafting work so we could actually hit the planned April 7th Alpha release date. I’ll call this the “Renaissance”.

In January, we launched a public website, the first incarnation of harmonyagreements.org. It was a single page containing the text from the current “What Is?” page, ugly as mud, and hosted on my own web servers.

Also in January, we started up weekly drafting calls. We took the earlier drafts as an inspiration, but started with a rewrite that I handed our drafter in January with the note that it might not be entirely legally accurate, but it was at least comprehensible to ordinary humans. And then we proceeded to pick that rewrite apart, line by line, word by word. The tone of these meetings was entirely different than the previous year. Partly, we all knew each other pretty well by then, knew each other’s values and priorities and could just settle down to work. Partly, the driving beat of the upcoming Alpha release helped us lock our attention on what to ship “now”. I worked hard to attend every meeting, even from exotic time-zones, on weirdly laggy voice connections. (I’m amazed at the patience other participants showed for including me in a conversation hampered by 2 second delays.) The discussions ranged over whether the drafts accurately reflected our intentions, had the intended legal effect, were understandable without a legal education, and would fit into the customs and cultures of existing FOSS projects. Every week our drafter brought a new version of the document (we worked on it as one big file with variations embedded), with substantial changes based on the group discussion. And every week we combed through those changes to make sure they were what we, as a group, wanted. People ask who drafted the agreements, and the answer is that we all did, together.

As we approached the April release date, we had a professional designer, Ben Pollock, prepare a proper design for the website (I highly recommend him, and hope he gets lots of business out of it, because he charged us beans). Oregon State University’s Open Source Lab agreed to host the site and our mailing list (they charged us nothing, please donate). I had a frantic last few days getting everything set up for the launch. To give geek credit where it’s due, the site is static generated HTML (anything else seemed like overkill for the handful of pages, we’ll expand later) with templates processed using Template::Toolkit (the libtemplate-perl package in Ubuntu), and both templates and generated pages stored in Git, so my “site launch” is a simple ‘git pull’. The comment processor for the mailing list that generates the comment review page is a Python script, basically a small finite-state machine using line-by-line pattern matching. (I’ll have to see if I can use Ruby or PHP for the agreement picker forms on our 1.0 website, for even greater compulinguistic diversity.)

On launch day, I woke up early to set the new website live just before Amanda’s panel at the European Legal Network Conference in Amsterdam. I don’t see the names of everyone who spoke at that panel posted publicly, so I won’t list them here. But, as far as I know the ELN conference is completely open to the public, so someone will eventually post it. After resolving a last-minute technical crisis with the review mailing list, and answering some press questions on the launch, I headed over to the Linux Collaboration Summit for the day. Bradley Kuhn slipped me in as a surprise special guest at the end of his Legal track, where I walked through some very last-minute slides, and a round of questions. The questions were good and thoughtful, captured well by Jon Corbet in his LWN.net post on the session. My immediate action items from the feedback in that session are around transparency: to replace the old “temporary” mailing list for drafting work with a second publicly archived list hosted by OSU OSL, and to put up a Sponsors page on the Harmony website as soon as we get approval from the various donors (names again withheld for Chatham). To anyone who is concerned about unfair influence by our drafter (even after I described how our drafting process actually works), let me say that sponsorship for the drafting work was only promised to the Alpha release, and is unlikely to be continued, since the workload of integrating revisions from the public review process is light enough to be handled by the volunteer participants.

I’m proud of the community group we’ve built around Harmony. I don’t think there has ever been such large-scale harmonious collaboration around FOSS legal strategies before. I take it as a positive sign for the future, that the FOSS legal community can embrace diversity, work together, and change the world for the better. I’m pleased with the template documents we’ve produced. They aren’t perfect, certainly, but they are a good reflection of current best practices, and I hope that through the public review process they’ll be even better by the time we make the 1.0 release.