ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life

Oracle goes shopping. Do we have an answer?

The topic at hand is Oracle buying one dual license open source company after another. This is getting a lot of people worried. Of course it also got me thinking.

Dual licensing is a business model associated with companies distributing their code under two very different licenses. One license is a classic proprietary license. It usually includes all the goodies like warranties and the right to embed the code into own proprietary code without any additional requirements.

However the same code is also provided through some open source license, usually one of the so called reciprocal licenses (GPL and friends). Reciprocal means that these licenses require that any code that is linked with the open source code may only be distributed under the same open source terms. The idea being that enough people will find exactly this point sufficiently annoying that they are willing to shell out the money for the proprietary license.

That system is pretty nice on many levels. Everybody gets the code with the license they prefer. "We", the open source folk, get nice well maintained open source code. Usually the company behind the product will make sure that people get paid for all the boring grunt work that often lacks in resource in pure open source projects like productization (packaging, documentation etc.).

The dual licensing company benefits through a cheap open source style distribution model. However they can still make money with selling licenses which is a very lucrative business model, while they can also make money through support. However support requires increasing numbers of employees as the number of support contracts increases. Licensing in theory just requires initial development and then you can license to a virtually unlimited number of people. Every customer not willing to spend the money for the proprietary license might go with your open source license instead of course. Which just means there is less money to be made for the competition. The idea being that you hurt the competition more than you hurt yourself.

However there are some serious flaws as well:

  • The company needs to own the full IP to the code, so it really cannot accept any outside code. Dual licensing companies therefore do not employ an open source development model.
  • Speaking of IP, its essentially impossible to prevent the competition to examine their code. But that draw back is somewhat offset by the fact that their customers can educate themselves and so selling licenses requires much less resources compared to the proprietary competition
  • Another result of the fact that the company owns full IP is that they can at any point turn closed source all the way. An example of this is the popular unix security scanner tool Nessus that turned closed source. This is one of the things a lot of people are concerned about with the Oracle purchases. At this point the company sponsored open source development would cease. Worse still, all current developers are employed by said company, so there is no real open source community readily available to continue development.

So from the point of view of a proprietary customer they are faced with dangers they are well accustomed. If someone snags up a software supplier you might run into licensing issues. The good thing is that at this point they at least of the option of moving to the open source licensed version. Though its unlikely that this makes sense for them. However some companies might have just paid for the proprietary license to get some warranty and not because they fear being bound to the open source license terms.

From the point of view of the open source user nothing all that serious has really changed either. They can still use the code like they always did. However something did change. Usually a popular open source project will rarely run out of developers. This makes using open source code such a safe investment. However for dual licensed code you might be faced with a sudden disappearance of all developers. Essentially a full exodus! Now the challenge for the open source ecosystem is if they can pick up where the company has left off. Can they keep the momentum going. Can they build up the necessary infrastructure and know how to prevent the code to stall?

Another interesting bit here is that MySQL AB is both a proprietary and an open source customer of InnoBase and Sleepycat software. Its certainly a headache for them. Less so from a technical perspective. More so from a customer relationship perspective. Oracle now gets all the inside know-how they ever wanted on MySQL AB's customers, who are very concerned about the possible negative implications (I do not assume any will be clapping their hands at all great opportunities that an Oracle acquisition brings them). Furthermore MySQL AB might have to get their customers to migrate to a new table handler once they manage to write one up in order to make sure they actually are able to provide their customers with all the bases required for enterprise level applications.

Its obviously not yet clear that Oracle has in mind. I don't really think they were targeting MySQL AB with this move. More likely they were trying to get at SAP through MySQL AB. This would make it however more likely that they in fact just want to kill off usage for SAP customers and not that they are trying to compete in the open source database market.

So are we up for the challenge if we are faced with such an exodus?


Customer details

Through what means do you figure Oracle would gain access to MySQL customer details? Anyway, it's incorrect. There are contractual safeguards in place that prevent dissemination of any limited confidential information that business partners may have, even in the event they are taken over. That's basic/standard stuff.

But why would anyone care about that anyway, what strategic insight would it provide an onlooker? Many of the big MySQL deployments are very well documented in the press, case studies, user conference talks, etc. No secrets there.
The value simply does not lie in secrecy.

Re: Customer details

Well I made the assumption that InnoBase had infos in MySQL AB customers for products they bought through MySQL AB or from InnoBase directly as a result of entering into a proprietary relationship with MySQL AB.

While a lot of this may be available as case studies I am sure that a fair number is not .. possibly for good reasons. Furthermore Oracle might have gotten an opportunity to get an idea of what kind of licensen and support fees MySQL AB charges in the real world and how and what kind of discounts might have been given.

Obviously this is speculation and you clearily state that this speculation is false. I am still not convinced that this topic is so irrelevant.

Re: Oracle goes shopping. Do we have an answer?

I was talking to one of the Oracle guys during the last PHP Conference, and the issue of InnoDB came up. His comments of course came with all the standard "just my opinion" disclaimers, but one of his "ideas" for why they bought the company was because with the company came a a list of clients who were obviously interested in Enterprise Level database systems. He also mentioned that owning InnoDB put them in a position to be the logical upgrade path for the customers who outgrow InnoDB. They could offer simple upgrade tools, support etc.

Re: Oracle goes shopping. Do we have an answer?

They also tried to buy MySQL AB: http://news.com.com/Oracle+tried+to+buy+open-source+MySQL/2100-7344_3-6040197.html?tag=nefd.lede

Before you can post a comment please solve the following captcha.

your name: