Oracle vs. Google... and the web?

Unless you've been living under a rock, by now you've heard about the case that is certain to keep the armchair lawyers busy for years to come: Oracle vs. Google. It's already been dissected elsewhere, but in a nutshell: Sun owned their GPL-licensed Java virtual machine, and various patents on it; Google wrote their own JVM for the Android platform, Dalvik; Oracle bought Sun; Oracle uses those patents to sue Google over their JVM; Hilarity ensues.

So what? How does that affect us, as PHP and Drupal developers? Well it doesn't... except indirectly via another product that Oracle bought as part of Sun: MySQL.

Let's be clear about one thing: Software patents are bad. Period. At this point pretty much everyone who knows the subject agrees on that, except for some of those who hold lots of software patents (and even some of those agree that the patent system is broken).

So for one mega-corp to bring a patent suit, about a Free Software project no less, against another mega-corp is something of a problem. Whether or not Oracle has a valid case under current law, and it's possible that it does, it exemplifies that current law is broken in this regard.

Predictably, Oracle has been getting some backlash. Some have been trying to read the tea laves and figure out what Oracle hopes to gain from this move, as they had to have known there would be negative PR. There have even been some influential developers stating that Oracle needs to be hurt as punishment, and suggesting that because PHP and MySQL are joined at the hip that we, as PHP developers, can and should reject MySQL and drop MySQL support in our projects to send a clear message to Oracle.

Now, I won't go that far. For one, Oracle is a corporation and like any publicly traded corporation is doing what its accountants believe is in their best short-term financial interests. It's not being evil, it's just doing what it is legally required to do. For another, Oracle like Sun before it is a massive company. The Java and MySQL divisions are totally separate, and I would not at all be surprised if the MySQL division didn't even hear about the case until they saw it on the news. Oracle also has a not-too-shabby track record with supporting open source themselves, and with the acquisition of Sun is one of the world's largest open source contributors.

Too, PHP developers abandoning MySQL is a fool's errand. MySQL is too widely deployed, the integration too deep. MySQL itself is just as good a product today as it was a week ago. And it's not even feasible, given the number of projects that are hard coded to MySQL (from their SQL flavor through to lots of mysql_query() or mysqli_query() calls all over the code base). It also would result in dropping support for the non-corporate MySQL forks that have appeared since MySQL ceased to be an independent company, such as MariaDB. You don't want to hurt an innocent bystander.

Besides, that wouldn't hurt Oracle. Oracle doesn't care about random open source projects using MySQL. They care about support contracts; that's where they make their money. Open source projects using MySQL are, from a business perspective, just a means to an end. It's not PHP projects migrating away from MySQL that would get Oracle to sit up and listen, it's paying customers migrating off of MySQL, or really, Oracle eponymous database. But they can't do that as long as the PHP projects they depend on are hard-coded to MySQL, as noted above.

Oracle vs. Google was not in any way the reason that Drupal 7 included a massive push for greater DB independence. However, it does illustrate the benefit of avoiding vendor lock-in, even when you're an Open Source project. Controlling your own destiny means not having a "hard dependency" on anyone; not on a particular web host, a particular commercial company, a particular 3rd party product, even a particular 3rd party open source project like MySQL.

Drupal 6 ran on one and a half databases: MySQL and PostgreSQL (sort of). Drupal 7 aims to run on six: MySQL, PostgreSQL, and SQLite in core; MS SQL and Oracle in contrib; and we've recently confirmed that the MySQL driver works with MariaDB, too. And it's designed to be extended via contrib, so other databases are possible in the future as well. Yes, that forced API changes and increased the complexity of the system, no question. The vendor independence that bought us, and the hundreds of thousands of down-stream users of Drupal 7, is worth that investment.

If you're a Drupal developer incensed by Oracle's actions, don't get mad; get coding. There are still some outstanding issues in Drupal 7 on PostgreSQL and SQLite, and we are not releasing Drupal 7 until we can say that we support four databases out of the box with a straight face. If you maintain a contrib module, make certain that you're not doing anything MySQL-specific. Make sure your module works on PostgreSQL and SQLite at least, so that your users have the freedom to choose their database. It's all about the freedom to choose, and freedom from vendor lock-in.

If you work on another PHP project, make sure your project has good database independence, too. Avoid ext/mysql (you should be doing that anyway) and ext/mysqli and use PDO instead, which makes cross-DB support easier. If you know C, help with PDO itself; really, it desperately needs some love. If you don't want to write your own DB abstraction layer (really, it's not easy) there are plenty to choose from already. But whatever you do, don't force your users into being tied to one specific database; not just MySQL, but don't force them into PostgreSQL either; nor Oracle, nor SQLite, nor MS SQL.

If you want to send a message to Oracle about software freedom, write software that is Free. Free as in speech, free of patent encumbrances, free of vendor lock-in, even to another open source project. Give your users the freedom to choose, and to send what messages they will.

I'll see you in the issue queues.