Like a tea kettle, the ongoing acquisition of Sun by Oracle, objected to by the EU, has gone from cold to boiling to cold to boiling and back again these past few months. The diversity of opinions, even amongst the those considered to be experts on the subject, is remarkable and has led to a wide ranging, passionate debate.
Nor has the debate been purely academic; the past two weeks have seen progress sufficient for some to declare that the transaction’s endgame is – mercifully – at hand.
Still, as evidenced by the ongoing debate, whatever the future might hold, questions remain. And as always, we at RedMonk love to answer questions. So on to the Q&A.
Q: Before we begin, do you have anything to disclose?
A: Yes indeed. A high percentage of the vendors in, or concerned with, this transaction are RedMonk clients, including both Oracle and Sun, as well as market competitors such as EnterpriseDB, IBM, and Microsoft. Orthogonal competitors such as Cloudera, a vendor selling services around Hadoop, and Basho, responsible for the Riak project, are also RedMonk clients. Ventures such as Percona and Monty AB are not RedMonk customers. So consider those disclosures and make of the following what you will.
Q: Now, for readers new to the topic, can you provide a quick recap of the background before we get into recent events?
A: Sure. As everyone’s probably aware, Oracle announced its intention back in April to acquire Sun, which in turn had purchased the open source database MySQL in January of the previous year. But while the US DOJ approved the transaction relatively quickly, the EU objected, with its concerns specifically centering around Oracle owning the MySQL database assets. If you want the blow by blow, the 451 Group has put together the sequence for you.
Q: So what’s been happening over the past month or two?
A: Quite a bit, presumably, behind the scenes. Enough that, three days ago, Monty – one of the founders of MySQL – asked for help in “saving MySQL,” while yesterday, Oracle released a set of 10 items it would ” publicly [commit] to.” On the surface, however, there’s been little change, and Sun and its employees remain in limbo.
Q: All of which means what?
A: That we probably are nearing the endgame. It’s likely, in fact, that these commitments from Oracle are better regarded as a gesture, a means of appeasing the EU which Oracle had seemingly backed into a corner. Hence the favorable reception.
With both parties apparently having saved face, we could see the transaction concluded swiftly from this point forward. As the “favorable reception” above reflects and BusinessWeek’s Aaron Ricadela discusses, in fact, that Neelie Kroes is “‘optimistic’ that Oracle’s Sun acquisition can be completed while protecting competition in the database market.”
Q: What do Oracle’s 10 promises actually mean?
A: Well, they are gestures, and much depends on your perspective. Still, they are not likely to materially impact the future of the project for better or for worse.
Q: Why not?
A: Because it’s very difficult to tell a company what to do with its asset. Take, for example, one of the promises that involves an actual dollar figure:
Increase spending on MySQL research and development. Oracle commits to make available appropriate funding for the MySQL continued development (GPL version and commercial version). During each of the next three years, Oracle will spend more on research and development (R&D) for the MySQL Global Business Unit than Sun spent in its most recent fiscal year (USD 24 million) preceding the closing of the transaction.
On the one hand, this is a positive, because it means that Oracle is pledging not to immediately decommit from the project post-acquisition – not that I believe that would happen in any event. On the other, it makes no guarantees about the way and channels in which the product is marketed, nor does the financial commitment imply such: 24M is, essentially, a rounding error for Oracle.
Some of the proposed remedies either already exist, according to Henrik Ingo, or are non-binding, or both.
So do I think yesterday’s public commitments are material from a project future perspective? Not particularly.
Q: Do you think they’re important, politically, in allowing the transaction to proceed?
A: I do indeed.
Q: You are on the record publicly as believing that the transaction should be allowed to proceed: do you still believe that?
A: Yes.
Q: Why?
A: Because I never believed that commitments or remedies were necessary. Like IBM’s Steve Mills, the threat to competition is not obvious to me.
Q: What about experts like Jeremy Zawodny, who ask: “Trust Oracle? Why?.”
A: Well, the short answer is that you shouldn’t. Oracle, as a for profit entity, should be trusted to do what makes it the most money. Jeremy believes – unlike Mark Callaghan, but like Bjoern Schotte – that MySQL and Oracle compete directly, and thus the acquisition will lead to a decrease in the commitment to MySQL. Which is possible. Equally possible, however, and more likely – in my view – is a future in which Oracle and MySQL, which are still highly differentiated technically, are used to attack different markets. High end transactional and application oriented workloads for Oracle, web and departmental markets – and more specifically, SQL Server – for MySQL.
But no, MySQL users should trust only that Oracle will look out for itself, because that’s why a for profit venture exists. Those who “trusted” the original MySQL founders, for that matter, were likely disappointed when they sold the asset to Sun.
Q: Speaking of the founders, let’s revisit Monty’s request for help saving MySQL. Do you believe it’s self-serving?
A: Unfortunately, it can’t help but appear that way, because the reality is that this is all the result of Monty and the other owners having sold the asset for a massive premium. Paul McCullagh, the author of the PBXT storage engine for MySQL, however, argues that this is actually Monty being selfless rather than selfish.
The fact is, Monty’s own company, Monty Program Ab, stands to benefit the most from bad stewardship of MySQL by Oracle.
If Oracle slows and closes up development, rejects community contributions and creates a commercial version of MySQL, then Monty Program’s MariaDB fork will become very popular, very quickly.
Which would translate into income for Monty Program Ab as customers come to his company for additions, features and bug fixes that they need to secure there own production.
While I follow the reasoning, it doesn’t acknowledge what seems to be the more general fear here: that by bad behavior on Oracle’s part, the MySQL ecosystem could be sufficiently damaged so as to make it non-viable for all parties, third party or otherwise. Which constitutes, to some degree, self-interest rather than selflessness.
Matt Asay and Pamela Jones, meanwhile, make the case that some of the “remedies” proposed by the Monty AB camp, up to and including a migration from the GPL to the Apache software license, are intrinsically self-serving.
Personally, I think Monty would simply like for MySQL to go back to the way it was, pre-Sun – to get the band back together, as it were – but it’s too late for that.
Q: What is at the heart of Monty’s issue? Is this about the GPL?
A: No. Or at least: not directly. The quarrel rather seems to be with the way that the GPL enables the dual license business model. Here’s Eben Moglen:
My view on the role of the GPL in this situation has been strongly contested by my friend Monty Widenius and others who work for Monty or who are otherwise in sympathy with his position. So far as I have seen their expressions of their views, no one has disagreed with my positions on the GPL in general. All the writers have concentrated their attention, as has Monty in his very thoughtful and educational personal conversations with me, on the particular business model consequences of GPL’s operation in this situation. Monty and his colleagues believe that MySQL cannot flourish without an ecosystem containing venture-funded small firms making proprietary add-ons, plug-ins and enhancements to MySQL. They believe that if Oracle is the copyright holder, it can and will act to stifle these firms by denying them “OEM licenses,” which actually are GPL exceptions in return for royalties. But they also recognize that such firms would be stifled if the license of MySQL, which is GPL, were simply to be uniformly enforced by any acquirer, instead of being held by a firm that needed the income gained by commuting the GPL for money.
Translation: Monty thinks that Oracle will see that the GPL license is enforced, with no exceptions, and that a third party ecosystem needs exceptions to the license to survive. Monty acknowledges, however, that any potential owner of the MySQL copyrights could do the same.
This is why their argument has nothing to do, in the end, with competition law. Any holder of MySQL, be it for-profit company or non-profit trustee, that didn’t agree to commute the GPL for money would be equally unsuitable from their point of view. Whether Oracle is or is not “competitively constrained” by MySQL is irrelevant to the reasons for their concern. In fact, they don’t want the license of MySQL to be GPL, because they believe the GPL is unsuitable for economic reasons. This may or may not be right, but it isn’t a question to be resolved in a competition investigation.
Translation: Because this is effectively about any holder being able to grant exceptions to the terms of the license, rather than a specific concern with respect to Oracle, it’s not about competition law. As evidence of this claim, consider that Monty would prefer that the old license itself – which he helped choose – be abandoned for economic purposes.
In fact, I think they’re wrong. I don’t think the GPL is a bad economic fit for MySQL. I believe that Oracle sees clearly the nature of its business interests. It knows that MySQL is much, much more valuable to it alive than dead. In fact, Oracle has almost as much reason to improve MySQL as it has to improve its flagship product. For a small firm, like MySQL AB, dual-licensing revenue was the only efficient revenue source with which to develop the product. But for Oracle, service revenue is much more significant than dual-licensing royalties. As all parties who have spoken about the merger agree, regardless of which side they are on, enterprises that use Oracle are very likely to use MySQL also, because MySQL is the world leader in number of installs. Which means that companies that pay Oracle to service Oracle are very likely to pay Oracle to service MySQL as well, if Oracle is not only servicing MySQL but acting as primary funder and participant in a flourishing MySQL ecology. Even if Oracle were only willing to invest in MySQL the extent of its ability to increase the MySQL service business, Oracle would be the best thing that ever happened to MySQL. In fact, Oracle has an immense incentive to invest far more in MySQL than the extent of its increased winnings in the MySQL service market. MySQL driven technologically and economically by Oracle will be a price-zero full-GPL missile aimed at Microsoft SQL Server.
Translation: Dual license revenue is far more important, proportionately, to a firm of MySQL’s size than one of Oracle’s. As most shops that use Oracle also use MySQL, the ease of extracting service revenue from MySQL installations from existing Oracle customers goes up, tilting the revenue percentages even more in favor of service. Given this, Oracle has substantial incentive to continue developing the product. Also, the real target is SQL Server.
Which is why even if Monty is correct that venture-funded proprietary startups would disappear if MySQL were pure GPL, the outcome is still positive for MySQL: that venture market could never have been more than a few tens of millions of dollars, and Oracle will have the incentive to invest many times that every year. This isn’t a matter of trusting or distrusting Oracle: both Marten Mickos and I as independent observers unaffiliated with Oracle have come to similar conclusions. Having known both men for years, I yield to no one in my respect for Monty’s technical strategies, but I’m comforted to find myself in agreement with Marten’s business analysis.
Translation: Even if Monty’s correct, and the venture-backed proprietary startups die out, the additional revenue injected into the MySQL ecosystem via the Oracle acquisition is much larger. Hence, trust is not a factor: one just has to understand the profit motive that drives Oracle.
Q: Is this likely? Would the inability of parties other than Oracle to dual-license the product create an anoxic environment for third parties?
A: I’ve never subscribed to that viewpoint. Josh Berkus, of PosgreSQL fame, elegantly deconstructs that argument by reminding us of a simple fact: the overwhelming majority of open source related revenue derives from non-dual licensing related models. MySQL’s own business notwithstanding.
Q: What about the idea that a decommitment from Oracle would somehow kill MySQL itself, rather than the codebase?
A: As Brian Aker relates, this is likewise a groundless fear:
The entire concept of taking what has been made publicly available, and somehow removing it from the commons is inane. It makes me think about how American Society of Composers, Authors & Publishers tried to sue the Girl Scouts for singing songs around the campfire. Once the tune is in your head, it stays in your head.
Once software has been published under an open source license, it continues to be available, whether its current owners wish it to be or not.
The rights that apply to MySQL today will apply today will apply to the code in perpetuity, per the terms of the license.
Q: But couldn’t Oracle not make future updates to the project available without making them open source?
A: Indeed they could, as the copyright owner. But this would have the effect of making the new, hybrid distribution immediately incompatible with a host of GPL licensed third party patches, addons and tools. Which means that this fork, effectively, would be dead on arrival. So what sense would that make?
Q: What would you tell the “Save MySQL” crowd?
A: Nothing, really. I respect their position, their passion for the project, and their willingness to defend it. I simply don’t share their set of concerns about the projects future, since – if we’re examining motivations – Oracle has little incentive to kill MySQL, but would substantially benefit if it continues to be successful.
Q: But isn’t a successful MySQL likely to cannibalize the Oracle market?
A: I’ve seen no evidence of that. Remember June of 2008? Oracle hiked its prices by 15-20% with no detectible impact to its volume. If MySQL was a real, substantial alternative, wouldn’t we have seen wholesale migrations away from Oracle to MySQL? That we didn’t, and continue not to, tells me they’re two different markets. Which in turn tells me that what’s good for MySQL’s business is good for Oracle’s business. And if it’s easy to see how it’s good for their business, but difficult to build a case that says it’s harmful to their business, what are we afraid of?
Q: But what if – just for the sake of argument – the project is killed by Oracle? What happens?
A: Developers keep using it, patched and updated by third parties. Commercial customers get their support elsewhere. Life goes on.
Q: And what if Oracle releases a version that includes non-open source code?
A: Then the community has the ability to compete by producing versions with mixed copyright. On the one hand, Oracle would have its version, the differentiating code of which would be non-open source and produced solely by them. The MySQL community, on the other hand, would have its own version which could include any suitably licensed code, irrespective of its copyright assignment. Which version do you think the millions of current MySQL users the world over would get behind?
Exactly.
This all, ultimately, boils down to whether or not you believe that the ability to dual license an asset is vital for an open source ecosystem. Given that I believe that to be a provably false assumption, I don’t perceive the same issues that some in the MySQL community do. We’ll see who the EU agrees with.
