A collaborative activity dubbed Project Harmony is now under way between corporate and corporate-sponsored participants in the free and open source software communities (not to be confused with the Apache Java project of the same name). The project seeks to harmonise the various participant and contributor agreements – collectively termed “contributor agreements” by some – used by many open source projects.
The goal of the project’s initiators is to reduce the legal costs of analysing paperwork faced by companies contributing to open source projects. Initiated and sponsored by Canonical, meetings have already been held several times under the Chatham House Rule, including one recently during LinuxCon in Boston. The participants also number several people who are skeptical of the value of copyright aggregation, myself included. At the meeting I was asked to write about my skepticism; this article is the result. I’m by no means the first to tread this ground; you’ll also want to read the earlier article by Dave Neary, and the comprehensive article by Michael Meeks ends with a useful list of other articles.
What are “contributor agreements”, why do they exist, and are they a good thing? The need often arises from the interaction with open source of certain approaches to business. They serve a need of those approaches, but they can come at a significant cost to the health of the project. If you’re starting a new project, it’s worth understanding the bigger picture before diving in with a practical guide on the assumption “everyone uses contributor agreements” because not everyone does. For good reasons.
Dual Licencing
One of the dimensions of the business of open source has been the dual-licensing business model. The name is a little confusing since there is (usually) only one open source licence used – the second arrangement is usually a proprietary license or contract exempting the customer from some of the terms of the open source licence. It can be better to describe this as “selling exceptions to the open source licence”, and it is commonly done in conjunction with the GNU General Public License (GPL) which has clauses some businesses regard as hard to accept.
Under this model, open source software is genuinely present, guaranteeing the freedoms of its users, but the business owning the copyright makes money by selling benefits such as the right to make derivatives under a different licence, commercial terms that offer additional guarantees and (most famously) anything-but-the-GPL as the licence under which the software is used. This last option means dual-licensing has often been associated with shady sales tactics along the lines of “it would be a shame if your business got infected with that evil GPL viral licence…”
Copyright Aggregation
In order to use this model, the business owning the copyright has to own the entire copyright to the software they are distributing. As a consequence, when any community member wants to add a modification or enhancement to the source code for the software, the owner demands that to do so they must also hand over their rights to the addition. To achieve this, the copyright owner makes signing of a legal document mandatory for any involvement in the community that involves co-development.
Usually called a “contributor agreement” (to the detriment of older arrangements that use that term for community participation agreements that don’t actually aggregate copyright), the document gives rights amounting to ownership of the copyright in the new work to the copyright aggregator. It may also include other clauses, such as a statement or originality (“this is my work and I didn’t plagiarise it”), a grant of patent rights and even an indemnity (“if you get sued you can blame me”). In most cases the author retains rights to their individual work in some form or receives a license back, but it’s only the aggregator who has ownership of the copyright to the whole system.
So What’s The Problem?
Open source can be defined as the co-development of software by a community of people who choose to align a fragment of their self-interest in order to do so. The commons in which they work contains software under an OSI-approved licence free from usage restrictions with guaranteed freedoms to use, study, modify and distribute it – “free software”. The community members each work at their own expense in order to achieve a shared outcome that benefits all, including themselves. When they create an enhancement, fix a defect, participate in a design, they are not “working for free” or “donating their work” so much as they are “participating in co-development”.
That favoured word “contributor” gives a clue to the problem copyright aggregation agreements cause. An open source community is an open, meritocratic oligarchy – ruled by an elite who gained leadership based on the merit of their participation and skills, open equally to anyone who does the same in the future. The presence of a “contributor agreement” that involves copyright aggregation may be a warning sign that the community using it has one member who is more equal than all the others.
Communities whose members are termed “contributors” rather than “members” or “participants” may well be unequal places where your interests are subsidiary to those of the copyright owner. They are often dominated by users and fans of the software rather than by co-developers, since the inequality makes it hard-to-impossible for a genuine co-developer to align any fragment of their interests on equal terms. Indeed, this inequality is seen by some dual-license proponents as one of the attractions of the model as they seek a community of enthusiasts and (hopefully) customers that they can exploit without competition.
Exceptions
There can be justifications for having copyright aggregation by and for a community. When the beneficiary of the aggregated copyright is the community itself (in the case of a community hosted by a non-profit Foundation), there are benefits available that may outweigh the disadvantages. These include giving the Foundation the legal right to enforce the copyright in certain jurisdictions, and the freedom to update the open source licence later. They may also include the granting of additional rights such as patent licences in the case where the open source licence does not adequately deal with patents, or to help in countries where copyright law is sufficiently different from US law that the US-centric concepts behind open source fail. Richard Fontana covered these well in his LinuxCon presentation.
Even with these benefits available, there are many communities that choose not to aggregate their copyrights – notably the Linux kernel, GNOME, Apache and Mozilla communities. The recent policy and guidelines on copyright assignment by the GNOME Foundations are especially worth reading. Having diverse copyright ownership leads to a deeper mutual trust and an assurance that the playing-field remains level. Insisting on copyright aggregation is one of the more certain ways a company can ensure the open source community it is seeding remains small and lacking co-developers. With the rise of “value add” business models such as Apache-based open core or service subscriptions, it is less necessary for the businesses involved to aggregate copyright.
Some Foundations that avoid aggregation (such as Mozilla) do have a document termed a contributor agreement but the purpose it serves might be better termed a “participant agreement” since it mainly addresses community norms and specifically avoids copyright aggregation. Indeed, there are some who suspect a motivation for using the term “contributor agreement” vaguely to describe agreements also aggregating copyright is a tactic to screen the toxicity of copyright assignments from general view.
How To Flourish
It may well be advisable to have a participant agreement for your community, to ensure that everyone has the same understanding of and commitment to the project if they are sharing its evolution. But if you want your community to flourish, eschew aggregated copyrights, or vest them in a non-profit entity representative of and open to the community. In fact, avoid any institutional inequality and focused control. Communities should be open-by-rule.
In my experience, attempting to retain control of a project you’re starting or hosting leads to mistrust, contention and a rules-based focus that diminishes your reputation. Relaxing control will lead to the community innovating and growing in ways you’ve not anticipated, as well as enhancing your reputation. As I’ve frequently said (although less frequently been heeded): trade control for influence, because in a meshed society control gets marginalised while influence delivers success.
[First published in ComputerWorldUK]
Filed under: Copyright, Governance, Open Source | Tagged: Business, Copyright, GPL, License, Multi-licensing, Open Source |
Wild Webmink 
Nice piece.
One thing that might be worth mentioning re: dual licencing is how frequently this model is used for what is in effect library software that would more appropriately be licenced with the LGPL, rather than GPL.
In these cases the LGPL would generally be acceptable to both the community and the business users.
Thanks – when this piece moves to the “essay” tab I’ll try to fold that in.
[…] ★ On Copyright Aggregation Communities whose members are termed “contributors” rather than “members” or “participants” may well be unequal places where your interests are subsidiary to those of the copyright owner. They are often dominated by users and fans of the software rather than by co-developers, since the inequality makes it hard-to-impossible for a genuine co-developer to align any fragment of their interests on equal terms. Indeed, this inequality is seen by some dual-license proponents as one of the attractions of the model as they seek a community of enthusiasts and (hopefully) customers that they can exploit without competition. […]
I’m not sure you’ve shoved these pieces around into any arrangement that’s natural to them.
On the one hand, contributor agreements and copyright aggregation are not the exclusive property, or even the invention, of commercial exploiters of OSS. For my own part, the first such agreement I ever signed was with Richard Stallman, relating to GNU Emacs. I doubt it’s possible to name any person, product, or purpose that’s farther from the “sale of GPL exceptions” end of the spectrum! What copyright aggregation *is* about, in all cases, is _control_; whether you use that control for profit or or liberation is orthogonal to the tools, but probably crucial, both to the controller/aggregator and to anyone considering participation at any level.
On the other hand, to suppose that copyright handling is the magic key to community flourishing seems not quite justified by the data–unless, indeed, we define “flourish” so narrowly as to make the question tautologic. There are some great open-source product communities built without copyright aggregation (I’d add Subversion to your list); there are also some monumental flops, not to mention endless failures to launch. There are also impressively successful projects built by communities with aggregation (I really think we can count MySQL in this group). These latter illustrate what may be the most fundamental problem with business/FOSS partnerships: even when things start out well, our very definition of “business” is antithetical to “community,” and the risk of conflict never goes away. When the conflict comes, then the question of control — who, and how much — becomes determinant.
You seem to be falling foul of the overloading of the term “community”.
MySQL may have had far-reaching consequences in terms of massive adoption, but it is a failed community in terms of co-development; the number of non-MySQL-employed co-developers as a function of adoption scale rounds to zero. Indeed, the contributor agreement was the trigger for the fork that resulted from Google’s massive contribution being rejected because of their unwillingness to assign ownership to MySQL AB. I would be interested to hear of any project with both extensive, diverse co-development and commercially aggregated copyright; I am not aware of one.
As for aggregation by community-representative owners, it is indeed much less problematic but it is still widely regarded as an inhibitor to co-development participation. The act of completing a legal document is always off-putting, and academics and government employees rarely have the scope to go beyond the terms of the licence in contribution. While there may (and I stress may be benefits, it will always be a barrier to participation which has to be weighed against those benefits.
Ah, well … “MySQL may have had far-reaching consequences in terms of massive adoption, but it is a failed community in terms of co-development” is what I was gesturing towards when I talked about “redefining ‘flourish’ into tautology.”
I don’t challenge your statistics, by the way, but I think My SQL flourished, and did so in significant part because of its community. I’ve been known to pound tables over the overloading of “community” myself, again I’m with you on the regrettable miscommunications that ensue, but when we’ve qualified all our uses of the term out of ambiguity, we’ll still need a name for the sort of “community” that enabled MySQL to flourish.
As for examples: the Subversion community was originally copyrighted by CollabNet, and rights were for a time aggregated to CollabNet, as a sort of corporate BDFL. What’s really quite astounding, and not at all to be expected to happen often, is that when this arrangement raised the inevitable tensions, the community and the company were able to agree to do all sorts of sensible, communitarian, flourish-worthy things, such as transferring the rights to a foundation (at first, composed of the committers; more recently, the Apache Foundation), and abandoning aggregation at the conscious sacrifice of the (arguably dubious) chances to milk it commercially.
I think, if I dare put words in your mouth, you’ll agree that Subversion is a co-development community, even though around 25% of the effort has always and continues to come out of the CollabNet pocket, and CollabNet is just another company, with motives that begin and largely end in the bottom line. Subversion flourishes despite this commercial / community partnership/tug-of-war.
(And I do agree that rights aggregation is just too much to expect any community to survive: objectionable, awkward, imponderable, unbounded, totally destructive of all sense of … well … _community_!)