MySQL mistake is a wake-up call on open source ownership

There was a moment of panic in the open source community this week when a developer on the MariaDB fork of MySQL discovered that Oracle had quietly changed the license on all the man pages for MySQL from GPL to a restrictive proprietary license two months earlier. Prompted by the bug report, Oracle’s staff quickly discovered that an error had been made in the build system and promised to immediately undo the change and restore the GPL to all of MySQL. Problem solved!

All the same, the incident was a wake-up call to many. Although there’s no reason why they should and have promised not to do so, Oracle could change the license for MySQL, or indeed any of the open source projects it owns, at any time without notice. Oracle is able to do this since, unique among the rest of the open source community around each project, they are not themselves bound by the open source license.

This unique power exists in turn because Oracle owns the entire copyright to MySQL, even to parts of it the company has not written. Why is that? It’s because all contributors to the code have to sign a “contributor agreement” assigning ownership of the copyright to Oracle, which is not alone in this. Sun before them used contributor agreements to get full source ownership, and many other projects do the same.

What are contributor agreements, and why do they exist? The need for them often arises from the interaction with open source and certain approaches to business. They meet a need, 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 with a practical guide to the assumption that “everyone uses contributor agreements” because not everyone does. I’m by no means the first to tread this ground; this old but comprehensive article by LibreOffice developer Michael Meeks ends with a useful list of other articles.

Dual licensing

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 license used; the second arrangement is usually a proprietary license or contract exempting the customer from some of the terms of the open source license. This can be better described as selling exceptions to the open source license, and it is commonly done in conjunction with the GNU 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 license, commercial terms that offer additional guarantees and (most famously) anything-but-the-GPL as the license under which the software is used. This last option means that 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 license …”

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 the contributor must also hand over their rights to the addition. To achieve this, the copyright owner requires the contributor to sign a legal document 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 of originality (“this is my work and I didn’t plagiarize 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 any individual work in some form or receives a license back, but it’s only the aggregator who owns 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 free from usage restrictions, with guaranteed freedoms to use, study, modify, and distribute it — in other words, “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, or participate in a design, they are not “working for free” or “donating their work” so much as they are “participating in co-development.”

That favored 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 gain leadership based on the merits 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 or even impossible for genuine co-developers 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 nonprofit 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 license later. They may also include the granting of additional rights such as patent licenses in the case where the open source license does not adequately deal with patents, or to help in countries where copyright law is sufficiently different from U.S. law that the U.S.-centric concepts behind open source fail.

Even with these benefits available, many communities choose not to aggregate their copyrights — notably the Linux kernel, GNOME, and Mozilla communities. The policy and guidelines on copyright assignment by the GNOME Foundation is 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 that the open source community it is seeding will remain small and lack co-developers. With the rise of “value add” business models such as Apache-style 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 given the purpose it serves it might be better termed a “participant agreement.” This is because it mainly addresses community norms and specifically avoids copyright aggregation. Indeed, some suspect that vaguely using the term “contributor agreement” to describe agreements that also aggregate copyright is a tactic designed 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, then you should eschew aggregated copyrights or vest them in a nonprofit 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 marginalized whereas influence delivers success.

This article, “MySQL mistake is a wake-up call on open source ownership,” was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.