Come on Monty

What on earth is Monty (and Richard) thinking? How can you spin around 180 and expect to come of believable? How can suddenly the GPL be the wrong choice? How can suddenly OSS depend on proprietary sales? Anyways, even without this change of minds, I do not believe in their arguments. I also do not hold stock in any of the involved companies (well I do not hold any direct stock in any company only indirectly by way of a few retirement funds I hold), so why do I keep posting on this? The reason is that I think this kind of stuff hurts OSS. It creates the kind of FUD we were worried about Microsoft spreading about OSS. Now that they are shutting up more and more, some seem to feel a void that they need to fill with some FUD of their own. To me Monty is just abusing the lack of understanding but the growing interest from the EU commission about open source to get his baby back on the cheap, or at least as much control as he can, since after all his baby can never be taken away .. its GPL stupid! But just as well anyone can have his baby on the same terms and of course only one company can claim to own the original copyright.

Now he is sending his employees out making bogus claims like that Eben supposedly has stated that "any fork using GPL code has the exact same business opportunities Oracle has is". Well since I do not follow this case full time I can obviously not claim to have read everything that Eben has said and I must admit I have any skimmed his letter for about 30min but I have read nothing of the sort in that letter. All that was said is that MySQL cannot be killed by Oracle and that there are viable business models in the MySQL space. And the more Oracle tries to kill MySQL, the more viable business models arise for competitors.

I do take issue with some of Eben's statements. For one I do agree that the vast majority of GPL projects are not dual licensed, a significant number of the more well known ones (JBoss, MySQL, SugarCRM to just one a few from the top of my head) do indeed follow this model. So I think it hurts his argument to claim to try to relegate MySQL AB's business models to be "atypical". It has certainly been a very effective business models for some of the bigger OSS companies to make it there.

I also take a bit of an issue with his arguments in regards to storage engines. While there might significant truth in there and especially the business model concerns in regards to Falcon are beyond what I know about the internals of MySQL AB's business (why does Eben know?), but overall there are technical reasons that do make storage engines advantageous. Anyways here is the section from his letter I am referring to from (copied from a Groklaw article):

18. "Storage engines," for example, are much discussed in the SO, under the impression that it is a virtue of MySQL that it is designed around replaceable storage engines, which the SO asserts can only be created and implemented by venture-funded firms needing proprietary distribution opportunities in order to recoup development costs. This, I think, is a misunderstanding of the technical history. MySQL's design was an outcome of the need for dual-license revenue, not a pre-condition to it. PostgreSQL, for example, does not have or need multiple storage engines: it contains a single highly-configurable storage manager which is not independent of the database engine. MySQL's use of multiple storage engines resulted from MySQL's need to have something to sell dual-license customers different and better than that provided to users under GPL. The resulting uncertainty that could arise over whether a table had been created using a transaction-safe storage engine or by the original freely-available MyISAM storage engine contributed to the problem with occasional corruption of MySQL databases that was long a primary drawback to the enterprise use of MySQL. MySQL AB contemplated and designed a single multi-purpose high-performance storage engine, named Falcon, that would have substantially replaced all existing MySQL storage engines, but the business-model consequences of that step were sufficiently negative for MySQL AB, because of its need to produce dual-license revenue, that the project was never completed.

I do agree that the entire storage engine stuff did become part of their business model. And yes in some ways it was also a disadvantage in that suddenly in order to get optimal performance/features out of a MySQL install one would have to tune multiple storage engines instead of just one. Or that due to setup mistakes an app would not work as expected. But its also an advantage, in that in PostgreSQL for example you do not get a choice if you want the overhead of transactions (heck I just dropped the import of some CSV's from 3 hours to 10 minutes by switching to MyISAM) or because you want optimistic locking. At the very least I see a lot more radical experimentation going on in the MySQL ecosystem than I see in any other existing OSS RDBMS project.

Anyways, the point remains however: If you want to keep control over the copyright of your own code, do not go sell it to VC's even if your CEO promises that you will not sell yourself to another company. But I am sure Monty, you have made a bit of money with this mistake, so for you the lesson learned at least came wrapped in dollar bills.