Yet more on MySQL forks and storage engines
The issue of MySQL forks and their possible effect on closed-source storage engine vendors continues to get attention. The underlying question is:
Suppose Oracle wants to make life difficult for third-party storage engine vendors via its incipient control of MySQL? Can the storage engine vendors insulate themselves from this risk by working with a MySQL fork?
As laid out most clearly in a comment thread to a previous post*, Mike Hogan (CEO of ScaleDB) believes closed-source storage engine vendors can use a MySQL fork without running afoul of the GPL. In a nutshell, what he proposes is an inbetween layer of software, itself open-sourced, that on one side interfaces with MySQL, and on the other side talks cleanly enough to storage engines that it doesn’t infect them with the GPL.
*For some reason, the identical comments have also appeared one by one on a Stephen O’Grady blog post, with links back to the original thread. I did not actually post the comments attributed to me, so I presume there’s some automated process going on.
The most natural way for such software to be created would be obviously be in connection with the new Open Database Alliance. So Matthew Aslett of the 451 Group asked the ODA’s two founding CEOs — Peter Zaitsev of Percona and Monty Widenius of Monty Program AB — what they thought on the subject. He got rather different-sounding answers. Zaitsev in effect said “Yes, Mike Hogan’s idea probably works, but one never knows for sure when there are lawyers involved. ” Widenius in effect said “Nope. A license would have to be purchased from MySQL.”
On a first reading that all looks discouraging, but let’s probe further. In particular, let’s invoke the open source community’s famous distinction between two kinds of freedoms: “Free as in speech and free as in beer.” “Free as in speech” takes care of most technical fears — there’s no way Oracle can directly stop forkers from creating their own version of MySQL.
True, third-party storage vendors might have to compete with Oracle’s own storage engines, where Oracle has four kinds of competitive advantage:
- General business clout
- A whole lot of database development expertise
- The opportunity to build tight hooks between MySQL’s generic front end and Oracle’s own preferred back end(s)
- Alternatively, the opportunity to foot-drag on MySQL development and thus sabotage the third-party storage engine market altogether
But the first two of those points are exactly what independent DBMS vendors already have to deal with when they compete with Oracle, many of them quite successfully (especially in the analytic DBMS market). Ditto, really, for the third one. And the fourth is exactly what forking takes care of.
The situation for “Free as in beer” is not quite as clean. Could Oracle could successfully charge a financial “tax” on every closed-source MySQL storage engine sale, prohibitive or otherwise — even the ones running with forked MySQL rather than Oracle’s code line? Mike Hogan says No, Monty Widenius says Yes, and Peter Zaitsev isn’t sure. I find Hogan’s argument fairly persuasive, but he and I are probably in the minority.
So let’s suppose Widenius’ pessimistic view is correct. Right now it seems that MySQL charges a non-prohibitive tax those engine vendors are perfectly happy to pay. If Oracle made drastic increases in those charges, it could face all sorts of PR, business, and even legal adverse consequences. So the risk that Oracle cripples the MySQL storage engine vendors strictly through licensing fees seems relatively low.
One last question complicates all this even further — why would the storage engine vendors want to rely on MySQL-compatible front ends indefinitely anyway? The whole point of specialized storage engines is to do things very differently from generic MySQL, so I’m not clear on what kind of user technical skills argument there is. For most uses, the Postgres interface is as good or better than MySQL’s. Perhaps a third open source front-end flavor could eventually become popular. And by the way, Monty Widenius himself wrote:
The reason we decided on the name “Open Database Alliance” was to be able to include companies and people working on all other open source database in the Alliance.
This is work in progress. We will make this clear on the Alliance web site ASAP.
Interesting times indeed.
Comments
11 Responses to “Yet more on MySQL forks and storage engines”
Leave a Reply
>> Interesting times indeed.
That’s a mouthful. The key point, to me anyway, is what value exists in MySql sans ‘storage engine’? I admit to not being in the loop with regard to where the lines of demarcation exist; what part of MySql is “just” the ‘storage engine’? I assume that not ‘storage engine’ means at least the SQL parser, and whatever DDL utilities. In particular, the ‘storage engine’ executes the ACID functions, if any.
MySql <= 3.2 (approx.), which is when I was involved (yes, ages ago) was little more than the parser fronting native files. Which is why it was/is (Drizzle, or one of the other new MySql, is said to be 3.2-ish) fast, and not legitimately a RDBMS. KiddieKoders did and do love it for that reason; they write lots of ACID code in whatever language the application is written. But this is not a relational application.
So: I don’t see how one can meaningfully separate the ‘storage engine’ from even the parser, since the semantics and syntax of an ACID compliant ‘storage engine’ won’t exist in a MySql/3.2 parser. Conversely, MySql/5.x can’t be supported (or, I wouldn’t try) by the 3.2 ‘storage engine’ (Drizzle).
What part of the GPL-ed MySql codebase can be independent and shared between contradictory ‘storage engines’? My guess is not much.
@Robert Young
The separation to which you refer actually works quite well. Drizzle and MySQL 5.0/5.1 use the same InnoDB engine. This means that you get ACID and the same access method behavior for both databases. However, above this level there are many differences visible to applications–connectivity protocols, SQL syntax and data types, binlog format, etc.
One of the somewhat unexpected outcomes of the MySQL forks over the past year is that they have shown that the storage engines, especially InnoDB, are the rock on which MySQL is built and not the other way around. Drizzle has freely modified MySQL semantics but does not change the storage engines.
Cheers, Robert
@the other Robert
Interesting. What I recall reading was that Drizzle was returning to the roots, so to speak, of 3.2; no transactions, no foreign keys, and the like.
Postgres folk have been gloating, discreetly, of late. Interesting.
[…] apparent is that mySQL seems to be a melt down – have a read here (updated with…) and also here as it seems that more people are thinking the same way Share and […]
Maybe the confusion in the ODA is around what version of GPL is used for MySQL licensing. As far as I know, using a well defined interface is good enough to protect these storage engines from GPL under GPLv2 but under GPLv3, since they run in the same process space as the MySQL frontend, they would have to buy a license in order to protect against GPL. I think this is quite well accepted by the lawyers that I have talked to.
Ashish,
Interesting. MySQL uses GPL 2, so any code released before a change to GPL 3 — if such a change ever occurs — could be used in some form or other w/ 3rd party storage engines, if your lawyer acquaintances are correct.
IANAL but it’s perfectly possible to avoid the GPL constraints by moving the storage plugin to a different address space. Maybe this comes with some performance constraints – performance could be improved if more logic is moved to the plugins (and therefore more code is executed in the plugins instead of the “real” MySQL).
BTW – this is the same model as suggested by the Linux kernel for the (relatively new) user-space driver infrastructure. It allows closed-source, binary kernel drivers to be used in combination with the GPL kernel.
Mike Hogan of ScaleDB is running into some sort of a posting bug, so I’m putting up his comment for him:
———————————
Curt,
I see you are stirring the pot again. If you keep baiting me into commenting, I’ll have nothing left to write about on my blog (http://scaledb.com/Company_Blog.html) .
Just to be clear on my position:
1. I do not consider a storage engine to be a fork, it is a separate and complementary application that need not be integrated into the MySQL code.
2. Actual forks complicate the issue. Monty wants storage engine vendors to purchase an OEM license from Sun, but Sun can OEM the Enterprise version, not Community and certainly not MariaDB or other independent forks. If you believe that closed-source storage engines require an OEM license (I don’t), then MariaDB cannot work with closed-source engines.
3. As you astutely point out, storage engines can work with other open source databases just as easily. If MySQL becomes inhospitable to storage engines, they will surely move on. The question to MySQL is whether they are more interested in satisfying user needs or serving other strategic corporate objectives.
— Mike
I am not sure how Enterprise vs Community vs forks have anything to do with this. MySQL owns the copyright to most of the code whether that code is in Community, Enterprise or a fork. That code is published with a GPL license.
Mark is right that Mike’s point #2 was garbled and/or knocked down a straw man. But the rest of Mike’s argument seems a lot clearer.
CAM
Regarding my point #2 above, my understanding is that Sun OEM licenses limit the OEM to creating product for and supporting ONLY Enterprise, not Community. As a result, I don’t know why they would license commercial storage engines for MariaDB, which has got to be a far lower strategic priority to them than the Community version.