Tim O’Reilly reprinted a note from Andy Oram about Oracle’s recent purchase of InnoDB, the company that produces the best of the MySQL backends.
Assuming that Oracle knows what they’re doing (generally a safe assumption), the purchase is not an attempt to attack MySQL as an Open Source product, and it certainly shows no weakness in the Open Source model or the choice to use Open Source in the enterprise. Oracle’s lawyers are smart enough to understand that since InnoDB was released under the GPL, they cannot prevent others from forking the code and continuing development. Anyone — from private users to LAMP websites to large enterprises — can continue to use MySQL with the InnoDB backend under the GPL no matter what Oracle says or does.
What Oracle can now prevent, however, is dual licensing of InnoDB itself and any future forked version. Unless Oracle gives permission, InnoDB can be licensed only under the GPL, which means that it can be used as the backend only for a GPL-licensed database. MySQL AB, the company that produces MySQL, earns a chunk of its revenue from dual licensing, and when their contract with InnoDB runs out in a year and a half, they will no longer be able to distribute a non-GPL version of MySQL that uses InnoDB. So here are Oracle’s next two likely moves:
- Oracle continues to develop and improve InnoDB, releasing its changes under the GPL, winning kudos from the Open Source community, and encouraging even more users to switch MySQL and InnoDB.
- Oracle does not allow MySQL AB to renew its contract for dual-licensing InnoDB, weaking a potential competitor even while it helps an Open Source product.
In other words, MySQL extends its lead as the predominant Open Source database, but MySQL AB loses its dual-licensing revenue source and becomes a less effective commercial competitor to Oracle. Nice move. Looking over the pieces on the board, I can see two ways for MySQL to respond to this threat:
- create a new backend to replace InnoDB in the 1+ year remaining of MySQL AB’s InnoDB contract; or
- forget about dual-licensing, make MySQL exclusively Open Source, and concentrate on support revenue.
The first move isn’t as good an idea, since Oracle will be able to use its own code and expertise to keep improving InnoDB to be faster, more conformant, etc., giving it effective control of the game while MySQL AB is constantly reacting. Heck, Oracle can even fork its own version of MySQL, as long as it stays GPL. The second move, on the other hand, will give MySQL AB back the initiative by allowing it to benefit from any work Oracle puts into InnoDB — the better Oracle (or anyone else) makes InnoDB, the more revenue MySQL AB can pull in for supporting a pure-Open Source MySQL.
If there’s any lesson in this, it’s that the dual-licensing business model has some serious flaws. Stick with selling support and professional services.
Quoderat 
I think it shows that dual licensing is dangerous if you’re using other people’s code in the core of your own.
If they go completly GPL, what will happen will all those thousands of commercial projects that have licensed MySQL to be used i proprietary products? If you use the C library or the JDBC driver in you code you have to have a MySQL commercial license to keep your product closed source. These projects will have to kick out MySQL or go Open Source.
There’s no need for the ODBC or JDBC driver itself to be GPL, though — it’s just a client that communicates over the network with the database server. Following that logic, only GPL’d browsers would be allowed to connect with a GPL’d web server.
hello there,
i am trying to reproduce a data server that a company uses to present information to its customers via the web. No problem. What they are using right now is Microsoft Access, connecting via ODBC to a server on line. The cool thing that they can do is have several tables linked together. Like if a certain field is updated in one table, it updates the same info automatically in another table. So, i want to reproduce this in MySQL, but i can’t seem to find out how. Is there a way to pull this off on the server side ? or does that have to be done on the client side ?
thanks for any tips.
jeff – what you are looking for is called triggers, and is a ‘new’ feature in mysql 5. triggers enable you to execute code upon a certain condition. you may also be vaguely referring to foreign key constraints. a foreign key is a key in one table (the linked table) that points to the primary key of another table (the foreign table). This means that if the contents of the foreign table change, then by the foreign key relationship, the linked table is pointing to somewhat different information.
foreign key example:
an employee database:
employee table
department table
the employee table would hold employee specific data such as salary, and other employee info for all company employees.
the department table would hold data specific to the company’s departments
th employee table might have a key called department_id, which could point to the primary key of the department table (perhaps called department_id, id, etc)
lets say we adjust the name of a department – now all employees in that department will have a different department name showing by their name in a report of employees and their departments.
lets say we change the department_id key value for some employees to a different department_id value – now a report which lists the employees in that department will be affected accordingly.
this is foreign keys. a consequence of foreign key constraints is that you cannot delete a specific key in the foreign table if any rows in the linked table point to that specific key.
triggers are a whole different story, and they dont necessarily impose any constraints on the data of tables you use them on, as there isnt a real relationship between them. you could use a trigger, for example, to update the salary of everyone affected in a specific department, if a minimum salary amount stored in the departments table is increased, and you would otherwise have employees whos salary is below the department minimum. if you have a foreign key relationship between tables, this kind of a situation might have to be updated with a trigger, as foreign key constraints will not update data in another table.
these are just crude examples, as triggers have much more useful purpose, i just cant think of a practical example right now, and most databases have far more complex databases than just an employee and a department table, but hopefully this helps.