Project Harmony decloaks

Harmony was represented by none other than Allison Randal, perhaps best known for her work on Parrot and her current role as the technical architect of the Ubuntu distribution. Allison has put her hands into the legal realm before; among other things, she played a major role in the creation of version 2 of the Artistic License. She joined Harmony as a community representative prior to taking the job at Canonical, and, she said, she still is not representing her employer in this endeavor.

The idea behind Harmony is that contributor agreement proliferation is no better than license proliferation. A lot of the agreements out there are poorly thought out and poorly written; they are also causing developers to sign away a lot of their rights without always knowing what they are agreeing to. Corporate lawyers are also getting tired of having to review a new and different agreement every time an employee wants to participate in a new project. A smaller set of well-understood agreements, it is hoped, would make life easier for everybody involved.

Allison started off by stating that the project recognizes "none of the above" (no contributor agreement at all) as an entirely valid option. The Linux kernel was cited as an example of a successful project without an agreement in place, even though the kernel does, in fact, use the Developer's Certificate of Origin as its contributor agreement. The real point, perhaps, is that the Harmony project does not believe that its agreements are suited to every project out there, and that there will always be reasons for some to use something else.

Assuming that one of the project's agreements are used, contributors (and the projects they contribute to) will agree to a number of conditions, many of which can be thought of as standard. Both sides disclaim any warranty, for example, and the contributor has to certify that he or she actually has the right to contribute the code. There is a "generic" patent grant which applies only to the contributed code itself. After that, though, there are a few options which must be selected for each specific project, starting with how the code is to be contributed. There are two choices here:

• The contributor grants a broad license to the project, but retains ownership of the contribution. The project is able to use the contribution as it sees fit (but see below).

• The contributor transfers ownership of the contribution to the project and gets, in return, a broad license for further use of it. While the contributor no longer owns the work, the back-license allows almost anything to be done with it. There is a fallback clause under this option saying that if an actual transfer of copyright is not possible (not all countries allow that), an open-ended license is granted instead, and the contributor agrees not to sue over anything which cannot be conveyed in the license grant. It is worth noting that giving the license back to the contributor, while broad, does not include the agreement not to sue.

Missing from this list of options is one which says "the project may use this code under the terms of its open source license, and needs neither ownership nor a broader license to do so." Those are the terms under which many projects actually accept contributions. A similar effect can be had with a proper selection among the other set of options, but it's not quite the same.

The second choice controls what the project is allowed to do with the contributions it gets under the agreement. All of the options require the project to release the contribution under the project's license if the contribution is used at all; the sort of "we will ordinarily release your work under a free license" language found in Canonical's contributor agreement is not present here. Beyond that, though, the project can choose between the promises it will make to contributors:

• The project can restrict itself to releasing the work under the original license, with the common "any future version" language being the only exception. This option yields results similar to simply accepting the contribution under that license to begin with; it does not allow any sort of proprietary relicensing.

• The project can specify an explicit list of additional licenses that it may apply to the work.

• There are options which allow relicensing to any license approved by the Open Software Initiative, or any license recommended by the Free Software Foundation. These options would not directly allow proprietary relicensing, but the OSI option, at least, would allow relicensing to a permissive license, which would have very similar effects.

• The final option is the full "we can use it under any license we choose" language, which explicitly allows proprietary licensing.

The agreement also allows the specification of an additional license to apply to the "media" portion of any contribution. The intent here is to allow documentation, artwork, videos, and so on to be licensed under a Creative Commons license or under the GNU Free Documentation License.

After describing the agreements that the project has produced, Allison acknowledged that Harmony "failed" at marketing its work. In an attempt to do better, the project has set up a web site describing the agreements and allowing the public to comment on them. Comments will be accepted through May 6; there will be a meeting held on May 18 at the Open Source Business Conference to discuss the next steps.

The discussion in the room made it clear that there is some marketing work yet to be done. It's still not clear who was participating in the project, and it seems unlikely that the mailing list archives will be made available. There was a strange and tense interlude during which some members of the audience tried to bring out who actually drafted the agreements. It turns out that the Software Freedom Law Center had participated in the discussion, but had explicitly withdrawn (for unstated reasons) from the writing of the legalese.

It eventually came out that the author of the agreements was Mark Radcliffe, who is a bit of a controversial figure in this area; his previous works include Sun's CDDL license, the SugarCRM badgeware license, and The CPAL badgeware license. Bradley Kuhn also said that Mark has defended GPL violators in the past - a history which makes Bradley rather nervous. The unsolved mystery of who actually paid for Mark's time doesn't help either. Ted Ts'o suggested, though, that, now that the agreements are public, they should be read and judged on their own merits rather than by making attacks on the author.

Bradley had another complaint: the current agreements, with all their options, look a lot like the Creative Commons agreements. Some of them are more moral than others, but there is no moral guidance built in, and no way to guide projects away from the least moral alternatives. It will be, he say, confusing for developers. Just like "under a Creative Commons license" says little about what can be done with a work, "a Harmony agreement" does not really, on its own, describe the terms under which contributions are made. It took ten years, he said, to make some sense of the Creative Commons "quagmire"; the Harmony agreements will create the same sort of mess.

Allison responded that we already have that kind of mess, only worse. Ted said that, with the Harmony agreements, at least we'll have a set of reasonably well understood contracts which don't suck. We may disagree about some of the choices, he said, but they will at least be built on a decent base. He expressed hopes that Harmony would help end the problem of developers blindly signing away their rights.

What happens now depends, at least partly, on how the discussion goes; now that comments are in the open, the project will need to either respond to them or risk discrediting the entire process. Anybody who has an interest in this area should probably read the agreements and submit their comments; the alternative is to live with whatever they come up with in the absence of your input.