Open Channels

A while back I was doing some research for a client and came across an apparent GPL slight of hand engineered by Sun and IBM.  Time constraints and competing priorities kept me from writing about this until now, and Oracle’s acquisition of Sun has taken Sun off of the hot seat (see in particular paragraph 2, Non Assertion), but it’s still a pretty juicy story.  What’s more, I think it’s healthy to expose vendor behaviors that cut against the spirit of open source, creating unfair advantages for a privileged few at the expense of everyone else.

If you’re not familiar with the GNU General Public License (GPL), which is at the heart of this article, you can get a quick and relevant primer here.

Brief History

Sun acquired MySQL AB in 2008, and through that transaction became the copyright holder of the MySQL database intellectual property.  MySQL includes a Storage Engine API that allows vendors to integrate their storage engine technologies into MySQL.  However, the MySQL open source product is licensed under the GPL.  Thus, vendors of MySQL Storage Engine technologies had to make some hard choices:

1. They could license their storage engine products under the GPL as derivative works of MySQL Community Server (the open source version of MySQL).
2. They could cut a deal with Sun to integrate their closed source products with MySQL Enterprise Server (the commercially-licensed version of MySQL).  Examples of vendors that chose this path include Infobright, Tokutek and Calpont.  Since products in this category were licensed to integrate with MySQL Enterprise Server, they could not “officially” certify integration with MySQL Community Server without risking GPL infringement.  So vendors that chose this path “unofficially” claimed compatibility with Community Server (e.g., “the APIs are identical and we ran some lab tests to make sure everything works as expected”), and Sun looked the other way.

Along Came IBM with a Sham of a Shim

Among many other products, IBM ships a closed source commercial version of the DB2 database for System i (DB2i).  In  2008, IBM completed development of a software interface that allows DB2i to be used as a MySQL Storage Engine.  IBM called this software IBM Storage Engine Enablement; I’ll refer to it as the “DB2i shim”.

Early in 2009, IBM and Sun evidently worked out an arrangement for the DB2i shim to become part of MySQL. Why did they do this?  We may never know the complete story, but here are a few facts:

1. The DB2i shim is an interface that talks to the MySQL Storage Engine API on one side and the DB2i database interfaces on the other side.  Thus, it technically creates a layer of insulation between MySQL and DB2.
2. IBM crafted a “BSD-style” license for the DB2i shim.  BSD-style licenses are significantly more permissive than the GPL.
3. IBM contributed the DB2i shim to the MySQL code base, and Sun’s committers accepted that code contribution.
4. The Sun community guys were, themselves, confused by the DB2i shim license, as evidenced by this Laurel and Hardy MySQL community discussion thread, which initially classified the DB2i shim license as a “bug”.

So what was really going with all this furtive activity?  My take is that it was precisely the type of vendor-privileged nonsense open source aims to ovecome.  I believe that IBM did not want to expose DB2 to the GPL, but they wanted a better deal than the other closed source Storage Engine vendors were getting at the time.  They probably paid Sun a pile of money for the right to do a closed source commercial integration with MySQL Enterprise Server, with the agreement that Sun would also accept the DB2i shim into the MySQL code base under a BSD-style license.  Through that contribution, IBM would be able to openly pursue the entire community of MySQL developers, application vendors and end user organizations – an unlevel playing field for sure.  Importantly, they’d be able to do so without exposing DB2 to the GPL.

A Blunder Asunder

Leaving IBM’s motives aside for a moment, in my opinion Sun severely stubbed its toe by accepting the DB2i shim under IBM’s BSD-style license.  Although I’m not a lawyer, it seems pretty clear to me that Sun created a license backdoor that any closed source Storage Engine vendor could use without risk of GPL exposure.  All a vendor would have to do is build an interface to the DB2i shim the same way IBM did for DB2i (i.e., not directly to the MySQL Storage Engine API), and their closed source IP would be insulated from the GPL.  We can argue all day about whether or not this would be a wise path for a Storage Engine vendor to take.  But one thing is not debatable – this was a very stupid maneuver on Sun’s part.

Lessons Learned

There are a couple of important take-aways here.  The first one is identified above.  Open source vendors have to be extremely careful not to inadvertently create license pin-holes, as Sun evidently did by accepting the DB2i shim/license.  The second, more important lesson is that vendor-managed open source communities are much more susceptible to commercially motivated influences than pure community driven projects.  In an open community process, someone would have blown the whistle on the DB2i shim shenanigans.  But even in the world’s most successful vendor-managed open source project (MySQL), the gatekeepers were sound asleep.

3 Responses to “Sun, IBM and MySQL Storage Engine Chicanery”