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.