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 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]
Comments are closed.