MySQL forking heats up, but not yet to the benefit of non-GPLed storage engine vendors
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.
Related links
- 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
Comments
16 Responses to “MySQL forking heats up, but not yet to the benefit of non-GPLed storage engine vendors”
Leave a Reply
Curt,
MariaDB is based on MySQL source. MySQL/Sun has the copyright on most of that code. It is GPL for the rest of us. Whether or not they are interested in it, I don’t think MariaDB can do dual licensing for anyone.
This is the first I have heard that a storage engine can remain closed-source, be distributed and not violate the GPL, but I am neither a lawyer nor a GPL expert. I would like to read more about this, especially from an expert who disagrees with the statements in this story.
Mark,
Nobody is disputing that a fork of the main MySQL code base will necessarily be GPLed, although confusion was created at first as I overlooked that basic fact.
What they disputing is whether MySQL AB can dictate business practices to another vendor, just because that vendor’s software interacts with MySQL in some important way.
It is clearly the intent of Stallman and the GPL to have that effect. But that doesn’t mean he succeeded as completely as he wishes or even claims.
CAM
There are a few issues, here are two:
1. Can closed source storage engines interact with the community version of MySQL? Yes, MySQL blessed this with IBM http://bugs.mysql.com/bug.php?id=44172 last I looked DB2 was closed source.
2. Is it a good thing to have a mixed (open/closed source) ecosystem? Yes it enables companies to target niche market segments that don’t have the critical mass to support an open source model, but can support a closed source model. Let the market decide.
More to follow on my blog soon…
Mike,
That link says it was a BSD version of DB2. (By the way, I think DB2 on AS/400 is a very different animal from other DB2.)
I look forward to your further thoughts on the subject.
Do you have a link to your blog now? I’m not instantly finding it …
Thanks,
CAM
Curt,
The portion that falls under BSD is the glue that connects MySQL to DB2. Trust me, IBM will not open source DB2 any time soon…on any platform. This glue layer connects to DB2 on i5/OS. It provides a clean buffer between GPL, which sort of acts like a virus infecting any software (making it open source, not that I’m implying O-S is bad, just not always the vendor’s intention), and closed source. They did this to protect the crown jewels…DB2 source.
My blog is coming soon, hosted on the scaledb.com site. It is a work in progress. When it goes live, I’ll send you a link. In the meantime, I’m assembling posts. If you can’t wait 😉 you might enjoy some of the white papers I wrote here: http://scaledb.com/technology.html especially the one comparing shared-nothing vs. shared-disk.
— Mike
Mike,
GPL purists would surely like to believe the buffer layer would need to be GPLed and then, based on the buffer layer being GPLed, DB2 would have to be GPLed as well. Where did that argument fail?
CAM
Curt,
ON this link http://bugs.mysql.com/bug.php?id=44172 you’ll see approval by Sun legal of the alternate license, saying it is not in conflict with the GPL license. Apparently, there is a precedent for blessing this “BSD-style” license for components embedded into the core code. Legally speaking, in any agreement the specific outweighs the general. If you say “This code is under GPL”, then in one section you basically say: “Notwithstanding the foregoing, this piece of code is under BSD” then the court will rule that the section in question is BSD, especially with Sun’s written approval. Given IBM’s cautious nature regarding licensing legalities, I’m sure IBM got written assurance from Sun to this effect prior to taking this step. If there were a lawsuit between Sun/Oracle and someone operating under similar conditions, I’m guessing that such an agreement between Sun and IBM would be made available to the defendant under discovery, but I’m not a lawyer.
–Mike
Mike,
Good point. So let’s think this through.
A. If Sun had said “Notwithstanding the GPL, we license IBM to do X”, that would have been their right, but it would not have been much of a useful precedent.
B. That’s not what happened. What actually happened is that Sun Legal is quoted as saying that the arrangement in question did not violate the GPL. That is indeed an interesting precedent if somebody else wants to do something similar.
C. It appears that Sun Legal’s position is that (MySQL + the BSD code provided by IBM) is, as a combined work, GPLed.
D. However, it also appears that Sun Legal’s position is that the GPL on (MySQL + the BSD code provided by IBM) does not infect IBM’s other code with the GPL.
E. Since IBM’s code pre-existed any connection to MySQL, and was used for other purposes, it indeed pretty clearly is independent of MySQL. Most of the products I’m concerned with, however, have only been described or marketed as MySQL storage engines. (Calpont is sort of an exception, but then they haven’t actually shipped any product at all yet.)
F. Notwithstanding the distinction I’m drawing in E, if a storage engine is as “arms-length” to (MySQL + derivative works) as the closed-source part of DB2 is, it would be hard to argue that it would be infected with the GPL.
How am I doing? And how hard would it be for you to make ScaleDB meet the criterion in F?
CAM
Curt,
I see I’m not the only one with nothing better to do on a Friday night :).
Point A: I was merely pointing out the legal interpretation of specific vs. general in an agreement. The license embedded in the GPLd MySQL is specific. My “Notwithstanding…” was merely a case of taking literary license to concisely illustrate a point. Furthermore, it is not a legal and enforceable precedent, as you point out, but it announces to the world that this sort of thing can be done, they are deemed “compatible”, shooting a hole in the “no way, can’t do that” argument.
Point B: Agreed, if it goes to court and someone points to Sun legal publicly stating that the two are compatible…kind of a smoking gun. I saved a copy for fun.
Point C: Not clear to me what this means in the big picture.
Point D: If this code in MySQL caused DB2 to be deemed GPL, and other versions of DB2 used common modules like the query processor or API, then all DB2 would be GPLd. IBM would NEVER risk this, I would bet anything that they have a side agreement (confidential, unless compelled by a court of law to disclose) stating this same thing. Nobody at IBM would take such a risk otherwise.
Point E: Agreed.
Point F: Hypothetically speaking, operating at arms length, among other things, would strengthen such a legal position.
This is a purely hypothetical discussion. My comments do not reflect any statement of position or direction by ScaleDB, just an interesting analysis of the licensing situation.
Mike,
Well, soon I’ll go to the train station and pick up my friend and fellow analyst David Ferris, who’s staying at my house while he attends his son’s graduation. 🙂 But anyway,
1) The side agreement you hypothesize in connection with Point D, if it exists, actually weakens the whole precedent argument.
2) My point in A was to point out that anything involving a “notwithstanding” is irrelevant for most purposes.
3) My point in C was to point out that DB2 seems to be directly touching something GPLed.
4) The “smoking gun” of Point B is less valuable if it can’t be shown to have shot a hole in the theory that DB2 is infected with the GPL OR WOULD BE ABSENT A SIDE AGREEMENT with Sun.
Best,
CAM
Curt,
The agreement in the code is the agreement. The side agreement that I assume exists, would merely reiterate that IBM’s code is not covered by GPL, in case Stallman and the FSF tried to make a claim that DB2 should be GPLd. I wouldn’t think that such a document would weaken the case of others in this case, but again, I could be wrong.
If someone tried to make that case that DB2 should be GPLd, it would provide quite interesting legal theater.
Have a great weekend,
–Mike
Mike,
Suppose IBM is violating the GPL by not GPLing DB2 (AS/400 version). Who has standing to sue?
I believe it is only the copyright holder — i.e., Sun Microsystems — who you hypothesize may have waved that right in a side agreement.
You have a great weekend too.
CAM
Sorry Curt, I cannot add any value in the question of standing. I’ll leave that to the lawyers.
[…] Monash recently raised the question of whether closed-source storage engines can be used with MySQL (and, by extension, MariaDB) […]
[…] 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 […]
[…] Curt Monash of DBMS two observed, “MySQL forking heats up, but not yet to the benefit of non-GPLed storage engine vendors”. […]