MySQL AB ships the same source under two mutually incompatible licences: the GNU General Public License (GPL) and a paid commercial licence. This is the mechanism that makes a freely downloadable database saleable. To see why it works you have to look at the GPL clause that nearly everyone treats as a defect.

Context

MySQL has been under the GPL since version 3.23.19, released in June 2000. Before that the server used a licence of its own, more permissive in use but with less clear-cut conditions on redistribution. The move to the GPL did not make the product more free than before — it was already downloadable at no cost — but it changed the legal nature of what a third party may do with the code once it integrates it into a product of its own.

The same scheme turns up elsewhere. Trolltech has shipped the Qt library under the GPL — or, alternatively, under the Q Public License — since 2000, and sells a separate commercial licence to anyone developing proprietary software. Sleepycat Software ships Berkeley DB both under a copyleft licence and under a proprietary one. Aladdin Enterprises applied a variant of the scheme to Ghostscript for years. In every case the holder owns the copyright over the entire code base: without that condition it could not release the code under different terms to different recipients.

Anatomy of the licence

The technical crux is section 2(b) of GPL version 2: it requires that any derivative work, if distributed, ship in full under the GPL. For a library, or for client code that an application links into its own executable, the consequence is direct: the resulting application inherits the obligation, and if you distribute it you must make its source available under the GPL.

For anyone developing proprietary software to sell in binary form, this obligation is not acceptable. There are two lawful ways out. The first is not to link the GPL code at all and to speak to the database only across a boundary that creates no derivative work — usually a separate process communicating over a network protocol. The second is to buy from MySQL AB a commercial licence to the same code, without the reciprocity clause.

Dual licensing therefore sells exactly what the GPL withholds: the right not to redistribute one’s changes and not to make the final product GPL. The commercial value of the paid product grows with the binding force of the free licence. A permissive BSD-style licence, which already lets you close the derived source, would hollow out the commercial version: there would be nothing left to buy.

Where the derivative work ends

The trickiest part technically is not the server, which runs as a process in its own right, but the client library libmysqlclient. An application links it in order to speak to the server, and that link is exactly the act the GPL treats as the source of a derivative work. From here a concrete problem arises for open source projects under a licence other than the GPL. The PHP language, say, ships under a more permissive licence of its own, and its MySQL extension links libmysqlclient: read strictly, an extension of a non-GPL project that links to GPL code sits in a position that is arguable at best.

This is where dual licensing shows its fragility. The boundary of the derivative work, in the case of linking, is not set by a mechanical test but by a legal interpretation never tested in court for cases of this kind. Companies pay the commercial licence also, and sometimes mainly, to get out of this grey zone: they buy certainty, not functionality. Part of what they sell is the absence of interpretive risk, not better code.

Knock-on effects for the storage engine

The same reasoning extends to the storage engines that MySQL integrates. The InnoDB transactional tables are developed by the Finnish firm Innobase Oy and end up inside the server: distributed with MySQL, they follow the GPL. When the database integrates third-party code under different licences, every component must stay compatible with the terms under which MySQL AB wants to release it twice. A component under a licence incompatible with the GPL, or with a copyright holder who does not grant MySQL AB the right to relicense it, would break the chain: the company could no longer offer it under the commercial licence.

It follows that the dual-licence model constrains the technical structure of the product. Every external dependency must be handled not only on functional grounds but on copyright grounds: either the rights are assigned, or the component stays out of the commercial version, or it is rewritten. The architectural freedom of whoever maintains the product is limited by the need to be able to release it twice.

Limits of the model

Dual licensing needs a condition that not every open source project has: copyright concentrated in a single party. A project with contributions spread across hundreds of authors, each owning their own, cannot relicense anything without the consent of all of them, and so cannot sell a proprietary version of the shared code. This is why the scheme almost always belongs to companies that ask contributors to assign or broadly grant their rights — a practice that shifts control of the project towards the holder and away from the distributed development of Linux or Apache.

One point stays open that no licence settles on its own: deciding what counts as a derivative work in the case of linking depends on the jurisdiction and has no settled precedent. Dual licensing leaves this uncertainty standing and turns it into a revenue line.

Cover image: David Axmark and Michael “Monty” Widenius, the two founders of MySQL AB, photographed together in 2003 — photo by Werner Popken, CC BY-SA 2.5 — https://commons.wikimedia.org/wiki/File:Monty-Widenius-David-Axmark-MySQL-2003-05-09.jpg