Some thoughts on MySQL and Oracle

Fear #1 is that Oracle will kill MySQL, which Oracle is said to see as a threat to its cash-cow relational database management system. One might respond that similar fears were expressed after Oracle's acquisitions of Innobase and Sleepycat Software, but that things have not turned out that way so far. One might say (as Eben Moglen has) that keeping MySQL healthy is in Oracle's economic interest. One might also respond that Oracle could arguably do more damage to MySQL by breaking off the acquisition and allowing Sun to simply die. But what is most interesting about this particular concern is the lack of faith it shows in our community's ability to cope with such an outcome.

MySQL is licensed under GPLv2; it is free software. It can always be forked; indeed, some groups have already done so. There is nothing Oracle could do about that. Oracle could stop developing the free version of MySQL; it could even release future improvements which are available only on proprietary terms. But all it can take from us is the stream of future development which (we assume) we would have otherwise had from Sun. We might wish we had some of those enhancements, but it is another thing altogether to say that we are entitled to them. Free software generally does not come with a promise of future enhancements; what it does come with is the freedom to make those enhancements ourselves.

To say that Oracle would kill MySQL is to say that our community is not strong enough to continue its development outside of Oracle. That suggests that MySQL never really was an independent free software project. MySQL users who believe that should be clear about the position they think they have put themselves in: in this view, they are users of a proprietary product which happens to put out its code under the GPL. If this code has no future without its supporting company, the fact that it is freely-licensed has relatively little value. But such a view essentially writes off the community that has built the amazing collection of free software that we use every day. We are stronger than that.

Another interesting claim is that MySQL's license is the problem. Richard Stallman signed his name to a letter which expresses this worry:

The "more flexible license" in this case would be to add the "or any later version" language to MySQL's GPLv2 license. This statement looks like an attempt to push a license change onto MySQL, based on the assertion that GPLv2 somehow inhibits community contributions. Your editor is unaware of any study showing that developers are less willing to contribute to GPLv2-licensed projects; if such a study exists, it could certainly benefit from wider exposure.

That is not the only attempt to use this situation to bring out regime change on the licensing front, though. Consider Monty Widenius's "Help saving MySQL" post from December 12. He is asking readers to send messages to the European Commission; suggested text is helpfully provided. It includes:

Back in the days of MySQL AB, Monty and others were happy to put the GPL onto the MySQL code. It allowed them to release the code freely while building a business around selling proprietary licenses to companies which did not want to be bound by the GPL's terms. But the right to engage in this kind of business was sold to Sun with the company. Now Monty would like to get it back so that he, too, can sell proprietary versions of the software. This certainly looks like a bit of a request to have his cake and eat it too; it is not surprising that some observers have not been entirely impressed.

What we are really seeing here is the logical outcome of the corporate-controlled open source project model. Such projects may well create an external development community, but that community tends to be weak compared to well-established, independent projects. Additionally, the use of copyright assignments - common with company-owned projects - puts control of the entire code base into a single company's hands. As Eben Moglen noted in his submitted opinion on the acquisition, the single ownership of the MySQL code is part of the problem:

Anybody who has dealt with corporations for any period of time has probably learned one fundamental lesson: the company that one deals with today may differ significantly with the company one encounters tomorrow. Even in the absence of acquisitions, corporations tend to be just one bad quarter away from a total change of attitude. Being acquired will almost certainly change a company's approach to a project it owns - especially if that company is the sole copyright owner for the code in question.

Developers who contribute to a corporate project should be aware that they are signing their code over to an entity which may take a distinctly unpleasant turn tomorrow, regardless of how friendly it seems today. Users of this type of software should be aware that they cannot count on any promises which do not exist in a signed agreement with the owning company. The only exception is the license that the existing code is released under: that will not be going away. For a lot of MySQL users, the GPLv2 license is a more than sufficient promise for the future. Companies which have based products on the availability of affordable "GPL exception" licenses will be on less certain ground - though it is worth noting that Oracle has promised to extend those licenses for at least another five years.

Users of PostgreSQL (for example) need never worry about a takeover by Oracle or any other company; it is an independent project which will never be controlled by a single organization. Users of MySQL probably need not worry either; it is a well-established project which should survive a shift to a more community-oriented mode of development, should such a shift prove necessary. But the worries about this acquisition - at least, those which are not motivated by personal agendas - shine a light on what can happen with software which is controlled by a single organization. Being used as a political football in a regulatory fight, with all the associated uncertainties, is just one of the risks involved.