Comments on: Yet more on MySQL forks and storage engines

By: Mike Hogan

Mike Hogan — Thu, 28 May 2009 23:06:09 +0000

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.

By: Curt Monash

Curt Monash — Tue, 26 May 2009 20:45:31 +0000

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

By: Mark Callaghan

Mark Callaghan — Tue, 26 May 2009 14:58:33 +0000

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.

By: Curt Monash

Curt Monash — Mon, 25 May 2009 20:03:00 +0000

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

By: Christoph Rupp

Christoph Rupp — Mon, 25 May 2009 07:33:10 +0000

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.

By: Curt Monash

Curt Monash — Mon, 25 May 2009 04:26:22 +0000

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.

By: Ashish Thusoo

Ashish Thusoo — Sun, 24 May 2009 23:04:51 +0000

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.

By: to mySQL or not? | Sam Hamilton

to mySQL or not? | Sam Hamilton — Sun, 24 May 2009 11:18:14 +0000

[...] 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 [...]

By: Robert Young

Robert Young — Sun, 24 May 2009 02:15:10 +0000

@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.

By: Robert Hodges

Robert Hodges — Sun, 24 May 2009 01:31:40 +0000

@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