July 15, 2011, 11:34 AM — It hasn't been widely publicized, but Project Harmony released version 1.0 of its contributor license agreements on July 4, complete with an online agreement selector that enables users to order up their flavor of CLA like a Big Mac and fries at McDonald's.
For those of you not entirely clear what a CLA is, here's the quick lesson.
When a software developer creates a particular piece of code and wants to contribute it to a larger project, there needs to be some sort of agreement (formal or informal) as to what kind of license the contributed bit of code (the "incoming" license) will have in relation to the license of the larger project (the "outgoing" license). Ideally, you want the incoming license and the outgoing license to match up, because you wouldn't want, say, the incoming license be GPL and the outgoing license be a BSD license.
In the free and open source software community, this sort of thing is usually handled on an informal basis.
"I got code. Want it?"
"Sure. We use license X. Got a problem with that?"
"Not a one... put the code under that license."
Or something like that. This is, by the way, pretty much the method of license assignment that the Linux kernel developers have been using all along. In 2004, the kernel developers formalized the arrangement with the the Developer's Certificate of Origin, which formally states that contributor made the code themselves or based it on code that was actually open sourced. So, if someone were try to slip in plagiarized code into the kernel, the DCO affords some legal protection to the rest of the kernel developers.
But not everyone is so casual about the legal complexities that can surround the world of software development. This is particularly true of commercial entities, who want to make really sure their investment in the software is protected. This is the main impetus for CLAs: formal legal agreements that require contributors to not only certify the code they're turning in is clean, but also grant the project full rights to control the license of the contributed code within the project indefinitely.
CLAs are not all that common in the FLOSS community; they really haven't needed to be. A lot of developers and project managers really don't have a big urgency for using them, not to mention that if you do use them, the amount of paperwork associated with a project rises dramatically.
Despite the relative rarity of CLAs in FLOSS development, Project Harmony was launched in 2010, an effort spearheaded by Canonical general counsel Amanda Brock:
"Project Harmony is intended to assist organisations which use contribution agreements by providing standardised variable templates with clear and concise explanations; to come to a common understanding on these; and to recognise the relative maturity of FOSS by dealing with its internationalisation. Our goal is to make the process of contributing to FOSS projects easier for developers regardless of who their employers are. We believe that standardised contribution agreements should serve this goal."
The standardization of CLAs seems, at first, a laudable goal. After all, if something's messy, then it should be cleaned up. But remember: CLAs are--as of now--not very prolific in FLOSS development. There are differences between CLAs to be sure, but individual developers probably aren't going to be exposed to that many CLAs, so they're not going to be confused. So who's bothered by the so-called disarray?
Very likely, it's the commercial interests who are trying to get involved with FLOSS development and want to have that iron-clad protection. But, without some sort of template to use, companies and their lawyers were very nervous about drawing up a CLA and then finding out there was some sort of loophole they missed that would cause some sort of release of control of part of their software.
Because control is really what Project Harmony is all about.
The CLAs offered from Project Harmony give licensors an interesting range of control over the licensing of incoming projects. Contributors could find their code re-licensed within a specific group of copyleft licenses or all the way out to any license the licensor chooses--free, open, or proprietary. Richard Fontana, the Open Source Licensing and Patent Counsel, sums up the selection of Project Harmony CLAs quite nicely:
"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."
You would figure that with four of the five Harmony CLAs requiring any future license change sticking with OSI-approved licenses, contributors wouldn't have a lot to worry about. Except even that could pose a problem for contributors who would prefer their contributions remaining open at all times. Fontana draws up a very realistic example of how even these innocuous CLAs could go awry.
"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"
There's been a lot of ruckus about Project Harmony, and it's easy to see why. These CLA may afford some marginal protections to contributors, but the balance of power in the transactions seem very much on the side of the licensor. It's a sharp inequity, and the fact that it's coming from Canonical, which has been fussed at in the past about its own CLAs, is all the more interesting. Some argue that Canonical wants to ultimately shift as much of its software to commercially friendly permissive licenses or at least copyleft licenses that make corporate entities less anxious. I think that's a bit extreme, but clearly Canonical likes to maintain a lot more control over contributions than other FLOSS projects.
This is not to paint all CLAs as inherently evil. There are cases when they can and should be implemented.
But this particular group of CLAs seems a less-than-subtle attempt to try to attract potential commercial participants to FLOSS development by giving those companies and their lawyers templates that will settle their nerves. That's all well and good, but where is the good for developers here? Harmony CLAs, thus far, seem to benefit project managers far more than contributors.
Something with which I am sure many developers will disagree.
Follow Brian on Google+
