Over the course of the last week or so, conversation around the proposed Oracle acquisition of Sun – and thus, MySQL – has reached a boiling point, with commentary arriving fast and furious. There are plenty of pro and con positions on the transaction, and yet I am compelled to comment, both because my opinion has been requested and because I don’t see anyone making the case quite as I would.
So, with no further preamble, the Oracle/MYSQL 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. Cloudera, a vendor selling services around Hadoop, is also a RedMonk client. Ventures such as Percona and Monty AB are not RedMonk customers. So consider the disclosures and make of the following what you will.
Q: Can you provide pointers to the “discussion” you referred to above?
A: Sure. Here’s a letter from Mårten Mickos to the EU in favor of the acquisition. Here’s one against it, signed by Richard Stallman among others. Here’s a statement from Carlo Piana – now co-counsel to Oracle – in favor. Here’s one from Monty Widenius – one of the original founders of MySQL – against it. Here’s Bob Evans from InformationWeek questioning the EU’s motives. Simon Phipps, meanwhile, looks at Stallman’s position on license vs copyright. Matt Asay evaluates the GPL versus the Apache licenses. Tim Bray looks at the implications of the acquisition on the industry. Kirk Wylie, for his part, nicely deconstructs the transaction. Groklaw is concerned about the implications for the GPL. Matthew Aslett compares the transaction to free speech. And so on: there’s doubtless lots more commentary I’m leaving out.
Q: Let’s start with the basic question, then: do you believe that the transaction should be allowed to proceed?
A: I do.
Q: Why do you hold that position?
A: To me, how one answers that is a chain of questions. All of which presumably cascade from the big question: does the acquisition of MySQL remove a potential competitor in the market, thereby granting Oracle an unreasonable position that will negatively impact customers?
Q: Well, does it?
A: This is what I mean by cascading questions. To answer that, you need to answer two questions: 1.) do Oracle and MySQL compete, and 2.) would the removal of MySQL leave insufficient marketplace competition for Oracle?
Q: Ok, let’s take the first question: do Oracle and MySQL compete?
A: In some accounts? Certainly. Have there been Oracle kickouts of MySQL and vice versa? No doubt. And I should note before continuing that Jeremy Zawodny, who is not only extremely reputable but very close to the MySQL ecosystem, argues that Oracle and MySQL do in fact compete:
Sadly, there’s some background information that I should not publish here, but suffice it to say that Oracle was and probably still is threatened by MySQL. Their sales/marketing tactics made this quite clear long ago. But those deals were rarely public–for good reason.
In spite of that informed commentary, however, I do not believe that MySQL and Oracle compete on a material basis.
Q: Why not?
A: Because MySQL and Oracle are different tools for different jobs. Do customers attempt to use MySQL as the proverbial Amdahl mug? Absolutely. Do they and their Oracle rep both know it’s a bluff? Of course. Consider that it wasn’t until version 5 of the product – released in March 2005 – that MySQL added support for some basic, table stakes RDBMS features such as stored procedures and triggers.
MySQL’s market success and ubiquity owes as much to its rejection of such RDBMS standard features as it does to their inclusion. Developers seeking a lightweight, easy to learn database for web properties and departmental workloads found an ideal candidate in MySQL. That market, generally ignored by the bigger database manufacturers because of its low margins, offered a massive opportunity for growth.
But it also meant that MySQL has had to tread a fine line with its development, because the factors that made it successful in the web space left it less than ideal for the higher margin, transaction oriented market that Oracle dominates. Indeed, as MySQL continued to add the features that would make it more palatable to up market customers, it distanced itself from its roots sufficiently that its own developers chose to fork it. Drizzle is, if anything, a reaction to what MySQL was trying to become.
Years prior to the acquisition, MySQL employees, developers and customers alike would tell me quite candidly that they didn’t compete with Oracle outside of some opportunistic poaching. So my position remains the same: I have never seen MySQL as serious competition for the typical Oracle database workloads.
Q: In spite of the commentary from Jeremy, in spite of Gartner’s 2008 recommendation to consider MySQL as an alternative to Oracle, and in spite of “Project Peter?”
A: Yes. Gartner’s recommendation was, to my view, a logical recommendation from a negotiating perspective, but not one to be taken too seriously. Project Peter, meanwhile, was largely aspirational. Much of Sun’s ambitions for MySQL depended on their ability to use their enterprise standing and account management to drive their offerings up the stack, and so realize the higher margins those markets offer.
But it remained, in my experience, less than realistic. The truth is that aside from the fact that they are both relational databases, MySQL and Oracle have little in common. PostgreSQL is, in fact, the more realistic Oracle alternative amongst enterprise customers, which is probably why we’ve seen a commercial entity formed around it in EnterpriseDB, and why that vendor has targeted and had success in Oracle heavy markets.
Q: Ok, let’s go back to the question of whether removing MySQL would leave the market with a dearth of competition?
A: It seems self-evident to me that the removal of MySQL would not leave either an absence of competition, open source alternatives or both. DB2 is already a realistic commercial alternative to Oracle, depending on a customer’s needs, as is SQL Server. Relational open source options include standard PostgreSQL, as well as commercially supported and extended versions from EnterpriseDB, and Ingres.
Q: That’s fine from a technology perspective, but what about MySQL’s marketshare? Isn’t that the real asset?
A: It’s an asset, most certainly. MySQL is – as its ex-CEO, Mårten Mickos, argues: “the world’s most popular open-source relational database, and potentially the most popular relational database of all.” But the question is whether or not this is material to the market that Oracle competes in along with DB2, SQL Server and, increasingly, EnterpriseDB flavors and Ingres.
My view is that an acquisition would make Oracle a dominant player in two distinct – as I see it – database markets, rather than having an overwhelmingly popular database in a single market. That’s an important distinction, I think, if we’re talking about competition issues.
Q: What are the database markets?
A: Part of the problem with many of the responses I’ve seen is the assumption that the RDBMS market is in fact a single market. I do not subscribe to this view, and I believe the market adoption actively invalidates it. We’ve known for a while that the relational database market is highly stratified: the layman probably thinks of Teradata and others in the warehousing market, DB2, Oracle and SQL Server the big three of the transactional market, MySQL dominating the web usage category, and departmental databases consisting of everything from Access to MySQL to SQL Server to Sybase. And that’s without getting into more specialized niche categories, or even how many of them are threatened by non-relational projects like Hadoop.
The long and the short of it is that I don’t see Oracle wielding enough power over the various relational markets so as to eliminate or prohibit competition. If they bought DB2 or SQL Server – neither of which would happen, of course – sure. But not via a MySQL acquisition.
Q: What are the copyright concerns that Simon Phipps and Matt Asay raise?
A: In short, they center around copyright ownership. Reciprocal licenses that govern projects like Linux and MySQL guarantee user rights, but they do not prohibit exclusivity with respect to business models. The copyright for Linux, as an example, is decentralized, ensuring that no single entity – be that a Novell, a Red Hat, an Oracle or whomever – has the right to exclusively profit from the codebase. Changes made and incorporated by one into the project must be made available to all, per the terms of the GPL license that governs it. In single entity copyright ownership, however, the copyright to a given project is held not in a collective, but by a single commercial entity. This permits them to employ what is commonly called the dual license model, or parallel licensing as Stallman refers to it. In dual licensing, MySQL may grant in a commercial transaction the right to buy out of the license terms. If a vendor, as an example, wishes to embed MySQL but not abide by its reciprocal provisions, they can enter into a licensing agreement and purchase a second, or dual, license with more commercially acceptible terms.
Simon, if I’m interpreting him correctly (and he can certainly correct me if I am not), is arguing that Stallman’s position has evolved from one that is licensing-focused to one that acknowledges copyright’s role in project governance. Asay, on the other hand, is arguing for consideration of the permissive Apache license because it permits no such exclusive licensing.
For my part, I think that the actual mechanisms of the dual license model are still obscure, even after much discussion, and that not enough attention has been paid to the costs of the dual license model.
Q: How would you describe the mechanisms of the dual license model?
A: There are three, and they work in conjunction with one another: license, copyright and trademark. The license tells users what they can and cannot do with the asset, and in the case of MySQL provides the purchase incentive. Copyright protects the rights of the code creator, and in MySQL’s case grants them an exclusivity with respect to the license. Trademark protects the name, logo and so on, and as Monty told me in an interview, means in practical terms that forks cannot call themselves MySQL.
In simple terms: the reciprocal terms of the GPL mean that MySQL changes/fixes/additions must be shared, the centralized copyright model means that MySQL can obviate the terms of the license for commercial gain, and trademark means that MySQL’s brand is protected. That’s dual licensing. The license, which is receiving the majority of the focus, is an important component, but is not the only important piece – Simon and I are in agreement, I think, on that point.
Q: What are the costs? Asay seems to be arguing that the GPL is prohibiting software freedom rather than protecting it:
Now consider if MySQL were licensed under the Apache 2.0 license. MySQL 2 could arise, take the code, hire all of the developers, and development of the open-source database would not miss a beat.
Could MySQL 2 achieve the same with the GPL? No, it could not, because the copyright holder, Oracle, would always have a superior commercial opportunity, because it has more rights than downstream users, as the GPL leaves the copyright holder with a greater range of business model options, and not simply support/services.
Is that accurate?
A: Some of that is true, yes. It is true that if MySQL were licensed under the Apache software license rather than the GPL that anyone could take the code (though not the trademark, remember) and produce their own version of the code.
It is also true that this would prohibit the type of exclusivity that is enabled by the combination of the GPL’s reciprocal provisions and the centralized copyright ownership.
But Asay’s assertion that Oracle would “always” enjoy a “superior commercial opportunity” is – in my view – not accurate.
Q: How is it inaccurate?
A: Much of the commentary around the future of MySQL seems to assume a few things: one, that the product’s marketshare is indefinitely sustainable, two, that dual licensing is such a vital portion of the revenue stream that it’s impossible to build a MySQL based business without it, and lastly, that dual licensing has no downside to it. All of these, I believe, are questionable assumptions.
Q: Ok, let’s start with the marketshare question. Is MySQL’s marketshare declining?
A: Not in any obvious ways. But it’s not obvious that its flagship market – the web space – is wedded to the database. MySQL itself seemed to question this when it permitted the creation of the Drizzle project. Externally, we’ve seen a spike in the number of non-relational alternatives. Cassandra, CouchDB, MongoDB, riak, TokyoCabinet and the like are all being actively considered for the types of projects that used to default to MySQL. Has this had a material impact on adoption rates? Not yet. The cloud, whether we’re talking public or private, will have a tremendous impact on the data layer. So assuming that MySQL is the once and future dominant open source persistence option is, I think, a reach.
Q: And the dual licensing as a portion of revenue argument?
A: With the rare exception, post-bootstrapping, dual licensing is a secondary revenue source at best. The overwhelming majority of open source revenue is derived from traditional support and service agreements, along with custom development. To assert, then, that a company deprived of dual license revenues is less than viable seems incorrect to me.
More, it doesn’t adjust for context. At the time of MySQL’s inception, the volume of viable open source projects was certainly less than it is today. Thus the choice in any given category would-be dual licensees was substantially less, making commercial relationships with vendors like MySQL a good alternative. Given the increasing multitude of non-reciprocally licensed alternatives to any given GPL project today, it’s harder for vendors to justify paying dual licensing revenues when they have a credible, permissively licensed choice as well.
Throw in the costs of dual licensing, and it’s reasonable to question how compelling the business model is longer term.
It’s also worth mentioning that forked vendors are not at all prohibited from leveraging – and exclusively licensing and differentiating – hosted versions of the database, because hosting does not trigger the protections of the GPL. That’s a business model and an additional revenue option that is as viable for them as it is for MySQL.
Q: So what are the costs of dual licensing?
A: For smaller firms, the primary limitation is the development. Unlike non-dual licensed projects which need only concern themselves with the quality and provenance of code contributions from external parties, dual-license vendors need also consider the question of copyright ownership. Because dual licensing depends on ownership of copyright for the entirety of the asset in question, third parties must either assign or be willing to jointly hold the copyright for any potential contributions. Early in a project’s lifecycle, this is a minor concern because the project owner likely employs most of those qualified to improve it. As a project matures and becomes more popular, however, this is a more pressing issue. First, because it acts to inhibit community participation (see slide 18 of this deck produced by Monty), but second – and more problematically – it means that third parties can, in practical terms, offer a more complete product.
Jeremy Zawodny made reference to the practical implications of the dual license in a post from December of last year entitled “The New MySQL Landscape.” In it, he made the assertion that “You can get a ‘better’ MySQL than the one Sun/MySQL gives you today. For free.” This is the cost of the dual licensing model: in return for the right to exclusively relicense the code, you forfeit a.) the right to amortize your development costs across a wide body of contributors, and b.) the right to uniformly integrate the best patches/fixes/etc that are made available under the original license because you cannot always acquire the copyright.
This doesn’t mean that dual licensing is a uniformly bad strategy, but it does imply that it has costs, and that those costs escalate over time. This situation is the inevitable result of the dual license model over time as applied to a successful project. For those looking for perspective from a MySQL and Drizzle developer, I’d recommend reading Brian Aker’s piece here.
Q: So what does all of that mean, with respect to the proposed transaction?
A: It means that the dual license model has, like many business models, costs and benefits attached to it. Which in turn means that while it’s exclusively the right of MySQL and its owners to employ, that should not be viewed purely as a positive for Oracle and a negative for competitors. Evaluating the pro’s and con’s of the proposed transaction require more nuance than that.
Q: What about Monty’s recommendation that Oracle be required to sell MySQL?
A: My first question would be: who would he consider a “suitable” third party? Kirk Wylie nicely runs down the alternatives, but the obvious candidates are all non-starters for one reason or another. I think it’s probable that if Oracle was compelled to find another home for MySQL by the regulatory authorities, its eventually landing spot would prove similarly unpopular with the current critics of the deal.
Q: Let’s take a question from the audience: How does Oracle propose to split budgets fairly between the two interests?
A: I don’t know, and frankly I’m less concerned about that issue. I share Mårten’s faith in the market and the power of open source.
Q: And what has Mårten said on that subject?
A: In his open letter, he said the following:
In the MySQL ecosystem, there are already a number of forks. Each one of those forks may perhaps currently be individually weak and unpromising. But the reality remains that if the main steward of an open-source product fails to live up to reasonable expectations, the forces of open source will take over.
There is no question that we already have forks of the project; Morgan Tocker has an excellent diagram of their respective derivations here. What people question, rather, is their viability.
Which is fair, because in a world where MySQL is sufficiently funded and appropriately managed, the risk/reward ratio in embracing a particular fork as a strategic rather than tactical option is heavily weighted against derivatives. And the derivatives, remember, are obligated to respect MySQL’s trademark.
But let’s assume a worst case scenario for a moment: what might the response be if Oracle decided to either dramatically lower the project’s funding or kill the project off altogether? Like Mårten, I believe that the above risk/reward ratio would tilt dramatically back in the other direction, and that the MySQL brand would find itself immediately and possibly irreparably damaged (as would Oracle’s, though to a lesser extent), which would in turn create an immediate market opportunity for alternately branded drop-in replacements for MySQL.
Q: If you don’t believe it’s an attempt to corner the relational database market, then, why do you think Oracle is interested in acquiring MySQL?
A: I’ve answered this one before, and I stand by that answer:
Mårten sees this, at least in part, as a response to the Microsoft competitive threat, as he told Forbes. It seems extremely unlikely to me that Oracle – who’d been a rumored acquirer of MySQL before Sun snapped them up – would acquire the business just to kill it, particularly since that MySQL’s phenomenal growth has not come at the expense of their own relational database product. They’ve already played in the MySQL acquisition space, remember, buying InnoDB back in 2005 and maintaining it effectively.
In the abstract, it’s easy to see how Oracle could use MySQL as a complement to its flagship product; MySQL for low end, low margin accounts where Oracle doesn’t currently compete or, tactically, to undermine SQL Server and/or DB2 in particular accounts. The products are the perfects foils for one another, in many respects: MySQL is to startups/developers as Oracle is to the enterprise mission critical workloads.
Practically speaking, however, one can see obvious problems ahead. As a few folks have pointed out, the Oracle sales force is going to dislike MySQL even more than the Sun sales force did, as it is a low margin product competing – at least in some sense – with a high margin staple. The other question is the reporting structure: will Oracle fold MySQL into their database division? Or keep it reasonably autonomous? The former would likely be disastrous, the latter is difficult to imagine given a.) the political landscape and the absence of strong leadership at MySQL. While Karen Tegan Padir is well thought of within MySQL and the hand chosen replacement for Mårten, I agree with those who predict that it would be difficult for her to compete successfully with the entrenched Oracle database chieftains.
Given that Oracle has a negligible presence in the markets that Microsoft has been successful in, then, I think they’ll be the primary target. Meaning that competition shouldn’t be much of an issue.
