Last month, I wrote “This is a REALLY good time to actively strengthen the MySQL forkers,” largely on behalf of closed-source/dual-source MySQL storage engine vendors such as Infobright, Kickfire, Calpont, Tokutek, or ScaleDB. Yesterday, two of my three candidates to lead the effort — namely Monty Widenius/MariaDB/Monty Program AB and Percona — came together to form something called the Open Database Alliance. Details may be found:
- On the Open Database Alliance website
- In a press release
- On Monty Widenius’ blog
- In a Stephen O’Grady blog post based on a discussion with Monty Widenius
- In an ars technica blog post based on a discussion with Monty Program AB’s Kurt von Finck
But there’s no joy for the non-GPLed MySQL storage engine vendors in the early news. A key quote from O’Grady’s post is Monty Widenius’
We aim to support by default all open source storage engines. In our current tree we already have PBXT. Within a couple of weeks we will also have XtraDB and FederatedX. We are talking with some other storage engine vendors to include their engines too.
Monty’s blog post also refers to “open source storage engines.” Thus, absent further developments, it sounds as if the non-GPLed MySQL storage engine vendors are still wedded to Sun/MySQL (soon Oracle).
The reason I keep mentioning the GPL (GNU Public License) is that it’s an obstacle to selling a MySQL storage engine without Oracle’s consent. I previously posted on the subject, whereupon somebody who appears to be Mike Hogan of ScaleDB commented:
It is my understanding that commercial storage engines can create an OSS glue layer that makes calls to storage engines (multiple). This same OSS glue could work with Berkeley DB, PostgreSQL and Ingres. Thus it is DB independent. Such glue could then call multiple commercial storage engines, aking it storage engine independent. This way the two pieces (MySQL and storage engine) are not considered one product. This satisfies another aspect of the buffer between GPL and commercial. With an open source glue that supports X DBMS and Y storage engines, and by making the glue OSS, you are good to go.
I tend to agree with Mike, the key quote from the GPL FAQ being:
in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and non-free programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.
Of course, there’s a counter-argument that goes something like “It sure looks like a single product, namely a DBMS, and both Oracle’s and the Free Software Foundation’s lawyers are ready to sue based on the it’s-a-single-product interpretation. What user organization would want to risk messing with them?” The counter-counter-argument to that is: “If the Free Software Foundation brings a high-profile suit and loses, the whole copyleft movement could fall apart. And this would be a terrible case for them to bring.”
Here’s why I think Mike is right. MySQL storage engines use MySQL first and foremost as a parser. Yes, immature engines use it to handle whatever execution they can’t do themselves, but vendors work as soon as possible to reduce that to zero. And a parser can be very easily separated out from the rest of a DBMS. The same goes for ODBC/JDBC interfaces, stored procedure execution, and whatever other front-end stuff the MySQL engine does.
Maybe the front-end/back-end interface isn’t clean today, but in principle it could be, should be, and in this hypothetical future code likely more or less would be. In a clean interface, what moves back and forth is essentially data — specifically, SQL statements and results sets for same. Infobright’s (or another vendor’s) storage engine simply is not a derivative work of MySQL, or at least wouldn’t be after a relatively simple and straightforward refactoring.
Obviously, we could discover next week that the Open Database Alliance had struck deals with multiple closed- or dual-source storage engine vendors. But that’s not the vibe I’m getting now. Rather, Monty Widenius — and by extension this whole effort — seems to be focused on being very OPEN, Widenius’ previous involvement with dual-source vendor MySQL AB notwithstanding. For example, Widenius recently wrote:
Monty Program Ab is following the Hacking business model to the letter and it will be interesting to see how things will work out. I will keep posting about this to let you know what works and what doesn’t work and the challenges we face as we grow.
Perhaps he’ll decide he needs to work with the specialist MySQL storage engine vendors anyway; I don’t know the guy, so I can hardly say for sure. But based on his recent writings, that doesn’t seem the way to bet.
- A Slashdot discussion of the Open Database Alliance news actually raised some substantive points in the perennial MySQL vs. PostgreSQL debate
- A few days before Percona participated in the Open Database Alliance announcement, a Percona blog post raised similar issues, and lively discussion ensued in the comment thread