Official website for Linux User & Developer
FOLLOW US ON:
Sep
22

MySQL – A controversial dual licensing model

by Richard Hillesley

Dual licensing relies on ownership rights that inevitably come into conflict with the nature of open source. Richard Hillesley investigates…

MySQL was founded by Monty Widenius, David Axmark and Allan Larsson in Sweden in 1995, and rapidly became an essential element of the LAMP (Linux/Apache/MySQL/ Perl) stack which enabled the breakthrough of free and open source software in the Nineties.

MySQL was light and fast, and a popular choice for use in web applications. It was also free, and pioneered the use of dual- licensing – or the practice of releasing the code simultaneously under free or proprietary licences.

Dual licensing has always been controversial because it relies on copyright assignment and the willingness of third-party developers to surrender ownership of the code to a controlling company or organisation. Its virtue is the perception that it encourages companies to release code under a free software licence.

Dual licensing and copyright assignment has been seen an acceptable, if undesirable, compromise to some developers. However, Brian Aker, the primary developer of Drizzle, a fork of MySQL, points out that “dual licensing forces any developer who wishes to contribute into a position of either giving up their rights and allowing their work to end up in commercial software, or creating a fork of the software with their changes. In essence it creates monopolies which can only be broken via forking the software,” and there is no guarantee that new versions of the code will remain free in perpetuity.

“The GPL’s approach is to provide a stick or carrot,” Aker wrote. “If you are open source, then you don’t pay, assuming of you are ‘the right’ sort of open source. If you are closed source or pick a licence which is not compatible with the GPL, you are forced into paying for use of a commercial licence. When you ‘pay’ for open source, the freedom that was originally offered to the end user is removed. In the case of incompatible open source licences, you too are forced into the position of removing the freedom granted and possibly the freedom you granted to your own work. Take any current distribution of a Linux distribution and do the research on licences within it. The tangled mess that is found will confuse anyone. MySQL itself was only able to solve some of this by offering a ‘FLOSS Exception’ to the portions of the code it owns.”

A fanatical support team

The issue of the dual licensing of MySQL came to a head with the purchase of MySQL by Sun in 2008 and the subsequent purchase of Sun by Oracle, compounded by Oracle’s later decision to add extensions to the proprietary release of MySQL, using previously available APIs, which weren’t available to users of the GPL version of the code.

The claim of MySQL AB, the original owner of the code, and the advocates of dual licensing was that the proprietary version of MySQL, which was identical to the free software version, could be added to proprietary embedded
products without the manufacturers having to fulfil any obligation to release changes back to the community, and that this gave MySQL AB a commercial advantage.

Not all developers were convinced of this logic. Josh Berkus, a PostgreSQL developer and opponent of dual licensing, has claimed that MySQL AB owed the main part of its revenue to the traditional mechanisms for selling open source, which are subscription, installation, training, support, upgrades and maintenance.

“MySQL AB made the majority of its direct income from support contracts rather than from licensing. While these were termed ‘subscriptions’ and supposedly came with commercially licensed add-ons, customers were clear that what they wanted and were buying was MySQL’s fanatical support team, not any of the proprietary add- ons, most of which were inferior to open source alternatives.”

At the same time, MySQL’s availability as free software indisputably worked to the advantage of MySQL AB and gave it a commercial reach that would have been unattainable if it had been licensed as an exclusively proprietary product. Its popularity as a free software component gave it the profile that made it a saleable proposition to Sun and Oracle.

Ambivalences and ambiguities

The core of the problem is that dual licensing is dependent upon copyright assignment. Projects do not thrive if there are ambivalences and ambiguities around the ownership of the code. Devices such as dual licensing, copyright assignment and Contributor Licence Agreements (CLAs) may be attractive to participating companies, but act as a disincentive to the sense of community that is the lifeblood of an open source project. Dual licensing and copyright assignment result in a lack of transparency around the future direction and licensing of the code.

Copyright assignment of free software has always been a controversial topic, entailing paperwork and loss of ownership, and has played a major part in many forks and schisms in free software projects, not least MySQL.

If the ownership of a piece of code is assigned to a third party, be it a corporate or a non-profit, that third party is usually given the right to release the code under another licence, now or at a later stage, and the licence may not always be open source or free. Code that is ‘owned’ becomes an ‘asset’ that can be reused and sold.

A project that is a distinct entity and is ‘owned’ by no one is more attractive to developers and less vulnerable to splits and divisions than a ‘product’ which is controlled by a single company. And when the code for a project is ‘owned’ by a single firm, other companies are less likely to step forward and make contributions of their own.

A licence and a promise

The attraction of open source to a proprietary software company is that it gives access to communities of users and developers who bring with them reductions in cost, collaborative opportunities, software libraries, and opportunities for high-quality input from all kinds of sources. It is in the nature of corporate culture that the primary objective is to maximise the return on investment for shareholders and to take an unsentimental view of open source components.

But there is more to open source than a licence and a promise and, as events have demonstrated, companies change and ‘assets’ can be bought and sold. A licence means nothing if the ownership of the project has been signed over without guarantee, or segments of the framework or the code are entangled in ‘IP’ agreements that give control to the holding company and not to a disinterested foundation or non-profit organisation.

As Brian Aker observed: “At the heart of dual licensing is ‘ownership rights’, which inevitably come into conflict with the nature of open source. Open source projects that preserve the ability to dual-license come into conflict with the developers who contribute the code. For the project to continue, it must ask the original developer to give up their rights to the code via copyright assignment (there is some debate on whether copyright can be held in joint, but this is often disputed by lawyers). Thus dual licensing forces any developer who wishes to contribute into a position of either giving up their rights and allowing their work to end up in commercial software, or creating a fork of the software with their changes. In essence it creates monopolies which can only be broken via forking the software…”

Unsurprisingly, MySQL has been the subject of quite a few forks, branches and patch sets, dating back several years. The best known variants are probably MariaDB, led by Widenius; the Percona patch set; and Drizzle, led by Aker, who had been MySQL’s director of architecture.

The joy of forking

The ability to fork and rescue an ailing project is often touted as one of the big advantages of free and open source software. Whereas a proprietary software package might die if its parent company is bought or sold or goes out of business, a free software package will live on as long as somebody, somewhere, is willing to support its development.

Forks usually happen because circumstances change; because personal, behavioural or technical philosophies collide; or because developers want to experiment or take the software in a different direction. A freeing of the code from the chains of a company with a proprietary interest in the marketing and development of the product is an opportunity for growth and development. A free software project where the code belongs to no one attracts more developers. Decisions are made collaboratively, and terms for contribution are well-defined and clear. The greater the number of individual and corporate developers, the greater the pool of ideas there are to work from and the faster the project grows.

Forks and branches usually signify unhappiness within a community, as Nathan Willis observed in 2009: “The real question is not which fork is the MySQL, but whether the multiple patch sets and forks indicate sickness or health for MySQL as a whole. Excluding Drizzle, all of the projects were started because someone who cared a great deal about the future of MySQL saw something wrong with MySQL’s development process (and for its part, Drizzle was spawned by even deeper dissatisfaction with the technical direction of MySQL).”

For his part, Aker reported that in the first year of its operation the Drizzle fork “achieved a larger base of contributions than MySQL achieved in its decade-long existence. Community contribution at the expense of proprietary extensions is a small price [to pay] if you consider the value that surrounds us by releasing that opportunity.”

  • Tell a Friend
  • Follow our Twitter to find out about all the latest Linux news, reviews, previews, interviews, features and a whole more.
    • colin mcdermott

      After reading the article I don’t get what the issue is here:

      If I own the code and I open source it, You can develop the Open source side. If you want to commercially license your version of the code you need to talk to the license holder. If the commercial side is funded by support agreements over code modification…. Does it matter?

      Sure if the license changes hands, then the commercial contributions will stop. But your community is free to continue. If the community does not fork the code and stops contributing to it…. Well that is the communities decision.

      Yes, the dual license could be a legal battle, and lawyers will eventually work out the finer details of how GPL is implemented in Law. But I fail too see what the key issue is here?