Open Source has become significant enough - as either threat or
opportunity - for Oracle to throw about half a Billion into a
buying spree of Open Source companies. Do they understand what
they've bought? Two of the acquisitions are designed to
discomfit MySQL, but MySQL will have no trouble side-stepping
Oracle's maneuvering. And Oracle may soon find: you can't
really buy an Open Source project. Open Source leader
Bruce Perens presents a strategic analysis of
Oracle's purchases and their effect on MySQL.
Does Oracle Understand What It's Buying?
Bruce Perens <bruce@perens.com>
Oracle's eaten the only two companies that make transactional
database back-ends for MySQL: InnoDB last year, and now Sleepycat
Software. The purchases send a message that MySQL won't
achieve high-end database features without being beholden to
Oracle. But the message is hollow.
When the InnoDB purchase was announced, I asked MySQL CEO
MÃ¥rten Mickos: you're going to write your
own transactional back-end now, aren't you? Mickos is
loath to announce that, but it's a no-brainer. The database
back-ends in question handle file storage and low-level query
operations, don't understand SQL, and are plug-ins - ready to
be unplugged and replaced by some new transactional design by
MySQL.
What will Oracle have gained once MySQL announces a new
transactional back-end? Sleepycat: an excellent, simple, SQL-less
embedded database that's been a successful cottage industry
for a decade, and InnoDB, which I suppose might produce a
back-end for Oracle's own database. And not a bit of
discomfort for MySQL.
But MySQL has an alternative to rolling their own back-end: they
can continue to use the InnoDB and Sleepycat products under their
Open Source licenses, which are valid forever and for anyone,
instead of the commercial licenses that MySQL currently has for
these products. Because MySQL is a server, physically separate
from its client applications, the GPL and its restrictions
won't be a consideration for MySQL's customers.
MySQL could slap Oracle in the face by going with the GPL
strategy: they wouldn't have to negotiate with Oracle, they
could use InnoDB and Sleepycat in perpetuity, and they
wouldn't have to pay Oracle a cent. I'd be tempted to
take such poetic vengeance. But Oracle, which has tried to buy
MySQL before, could trump the GPL strategy by increasing what it
offers for MySQL enough to make that purchase go through. CEO
Mickos won't dabble at vengeance and will keep looking at
offers that - if nothing else - increase the evidence for
valuation of his company. But MySQL probably won't merge -
they see too large a market, and intend to have it for
themselves.
Even an outright purchase of MySQL by Oracle would not prevent
anyone from using MySQL's server in a commercial application,
without charge. That's possible today if you use an
unofficial (and non-GPL) client library to communicate with
MySQL. Other companies in the Open Source community would happily
provide training and support for MySQL, while an independent Open
Source project would evolve to maintain the program.
You can't really buy an Open Source project. The GPL was
designed to make it possible for any Open Source participant to
circumvent any other party who gets in the way. Other Open Source
licenses are similar. Larry Ellison can buy business and
influence over an Open Source project, but if he tries to have
absolute control, Open Source developers will code elsewhere,
replace whatever Larry holds close, and create new businesses.
JBoss, the Open Source J2EE company said to be a $400 Million
Oracle acquisition, hardly owns its market today. Commercial Java
projects, even those using Open Source code, may develop on JBoss
but predominantly deploy on proprietary software from IBM or BEA.
Years ago a large contingent of JBoss developers split off into
what is now Apache Geronimo project, an eminently viable
competitor to JBoss.
If Oracle is true to their history of eating their own ecosystem,
they might now use JBoss to go after BEA. BEA moved this week to
beef up their own presence in the Open Source community by
releasing some previously proprietary work as Open Source. Why?
they'll be using Open Source to go after Oracle. Open Source
developers smile as proprietary software companies fight each
other by collaborating more.
Bruce Perens is sponsored by Sourcelabs to spend half of his
professional time working for the Open Source community, with no
company control over his activities or his speech (including this
editorial). The other half of his work time, he's a Vice
President for Sourcelabs, responsible for policy, the
company's relationship with the Open Source developers, and
professional services for Fortune 100 companies. Perens is best
known as co-founder of the Open Source Initiative and the primary
author of the Open Source Definition, the manifesto of Open
Source. He is series editor of the Bruce Perens' Open
Source Series with Prentice Hall PTR Publishers, which
has published 21 books about Open Source. Each of the books has
its text licensed as Open Source. He is Senior Scientist for Open
Source with George Washington University's Cyber Security
Policy Research Institute.
But MySQL is dual-licensed. For those people who use it commercially, it isn't GPL. Thus, wouldn't this give Oracle a lever and require MySQL AB to possibly license the back-ends from Oracle? This is all assuming they don't write their own transactional plug-in.
If Company A makes a product that is not GPL and it uses MySQL as a backend, then they must pay a license to MySQL. This is, from what I understand, a big revenue stream for MySQL AB. Oracle's purchasing of the transactional backend companies can put a squeeze on that revenue by doing the same thing and making them dual-licensed.
The MySQL server doesn't have to be dual-licensed. They could use it under the GPL in its commercial role, if they wished. The client library, which they provide, could still be dual-licensed.
Currently, MySQL FUDs the GPL a bit to get commercial sales. You don't need their commercial license to use it. They'd have to - at least partially - give that up to follow the GPL strategy I outlined. But customers would still want their support and training, so I'm not at all sure they would lose anything.
Okay, MySQL changed things a bit with v5.0. They used to flat out have a FAQ that said "if you aren't giving away YOUR source, you MUST buy a license". Now they have the "community edition" vs "pro certified edition", and I found nothing stating that you can't use the GPL community edition in a commercial product without first buying a license.
What you meant is that customers need not buy MySQL server license, but they do need to buy MySQL client license if they want to use MySQL's J/Connector. Is that right?
Yes. But depending on their application, they also have the alternative of using unofficial, "forked" client software for the MySQL server that is not under the GPL.
That doesn't cover folks who integrate or embed the MySQL server into commercial products. A friend of mine, for example, works on a parts-cataloguing tool for mechanical engineers: MySQL is used as a back-end to store CAD files. The program is proprietary and it is not his to release under the GPL. Hence, he had to seek a commercial license from MySQL. Oracle now owning InnoDB and Sleepycat gives them the ability to cut off MySQL from this revenue stream.
Interestingly, no one mentioned that MySQL actually has a working transactional store of their own (NDB) which is currently used only in cluster mode.
But most applications don't actually embed the server. They embed client libraries and the server lives in its own separate executable. Simply packaging the server in a product does not activate the GPL terms. You have to create a derivative work.
Thank you. That was the explination that made sense.
I had some difficulty understanding how MySQL could live on in propriatary applications and that answered it. I hope this seperation is understood by those who may decide to support MySQL in their products. It will ensure that MySQL will live on as an open source product no mater what happens to its various parts.
Bruce - any take on the SugarCRM licensing situation? Now that MSFT has announced its partnership with Sugar, I took a look at its Mozilla-based license. I didn't really understand how their corporate versions -- which at first blush appear closed-source -- could jibe with the Mozilla-style license. Wondering if you had any thoughts on that.
"You can't really buy an Open Source project. The GPL was designed to make it possible for any Open Source participant to circumvent any other party who gets in the way. Other Open Source licenses are similar. Larry Ellison can buy business and influence over an Open Source project, but if he tries to have absolute control, Open Source developers will code elsewhere, replace whatever Larry holds close, and create new businesses."
You can't buy the project, but you can buy the developers. SleepyCat was a software company, and one that made money. It paid its developers, and now Oracle does (presumably). I don't know what portion of the development of the SleepyCat DB was done in-house and what portion was contributed, but I'd guess that significant effort came from inside.
"You can't buy the project, but you can buy the developers."
It's unclear just how viable a strategy this is. There always seems to be new developers ready to step into the breach. I'm sure it works OK as a holding action.
As an example, take TOra. (http://tora.sourceforge.net/) The developer was hired away by a competing product, users were told to contact the company, company representatives told them licenses could not be purchased, etc. On the surface it seems as though the intention was to kill Tora, although I've surely not investigated throughly so please don't take this as conclusive.
It did seem to slow TOra down, for maybe a year. (It's hard to say.) But today TOra seems to once again be moving forward and is back to kicking proprietary butt. (Again, I have not investigated throughly so don't take away from this any particular quantity of butt-kicking.) TOra was with pretty much a one-man project, you'd think a larger project wouldn't lose as much momentum.
Without more data points it's hard to tell how well the "buy the developer" strategy will work. One thing's for sure, the FOSS developer comes out ahead no matter what. This will hardly keep developers away from FOSS projects.
This IS really great: Oracle are actually telling the rest of the world with its own hard cash, that the quality of OpenSource DB software is remarkably good and that they do fear the competition of it. Their spending is even spreading this news throughout the press which is now telling more of their customer base about these opportunities to lower their TCO. Many of the end users of DB technology, are spending far too much money, without knowing that there exist not only one, but actually several OpenSource engines which would not both lower their initial cost, but even give them lower maintenance needs and cost. Oracle is hopelessly trying to catch the huge and increasing OpenSource wave, but they will apparently crash head on shore.
History has proven that when the owner of an open application does not prove itself to be a good steward of the code, a fork will emerge that is maintained by people who truly care about open source. Remember the example of OpenSSH. The original SSH code was true open source, but "SSH Inc." eventually closed it down. What happened next, as everyone knows, is that some folks took the last version available under an open license, forked it, and began the OpenSSH project. And now, OpenSSH is the dominant version -- SSH Inc. now languishes in relative obscurity.
I am a developer who uses Berkeley DB in a large project. We make extensive use of the database -- our entire data store is based on it. Will we be changing data stores anytime soon to get out from under Oracle's thumb? Nope. Lots of open source applications rely on Berkeley DB, and we can be sure that if Oracle ever attempts to either close or discontinue this insanely powerful, scalable, and reliable database library, some talented folks in the open source community will begin an "OpenBDB" project to pick up where Sleepycat left off.
For the time being, though, we should be optimistic. Sleepycat has assured us that the dual license development of Berkeley DB will continue. There's plenty of time to let them demonstrate that this is the case.
"For the time being, though, we should be optimistic"
I agree, at least partially with "cautious optimism". It could just be of a case Oracle realizeing that most of thier partners and competitors have already gotten involved in open source and it's time they jump in, and the easyiest way to jump in is to get the chequebook out.
Of course, untill time passes it's best to remain cautious, as it could be a move to wipe out the open source competition or something that is little more than an agressive hireing policy.
Does Oracle Understand What It's Buying?
Open Source has become significant enough - as either threat or opportunity - for Oracle to throw about half a Billion into a buying spree of Open Source companies. Do they understand what they've bought? Two of the acquisitions are designed to discomfit MySQL, but MySQL will have no trouble side-stepping Oracle's maneuvering. And Oracle may soon find: you can't really buy an Open Source project. Open Source leader Bruce Perens presents a strategic analysis of Oracle's purchases and their effect on MySQL.
Does Oracle Understand What It's Buying?
Bruce Perens <bruce@perens.com>Oracle's eaten the only two companies that make transactional database back-ends for MySQL: InnoDB last year, and now Sleepycat Software. The purchases send a message that MySQL won't achieve high-end database features without being beholden to Oracle. But the message is hollow.
When the InnoDB purchase was announced, I asked MySQL CEO MÃ¥rten Mickos: you're going to write your own transactional back-end now, aren't you? Mickos is loath to announce that, but it's a no-brainer. The database back-ends in question handle file storage and low-level query operations, don't understand SQL, and are plug-ins - ready to be unplugged and replaced by some new transactional design by MySQL.
What will Oracle have gained once MySQL announces a new transactional back-end? Sleepycat: an excellent, simple, SQL-less embedded database that's been a successful cottage industry for a decade, and InnoDB, which I suppose might produce a back-end for Oracle's own database. And not a bit of discomfort for MySQL.
But MySQL has an alternative to rolling their own back-end: they can continue to use the InnoDB and Sleepycat products under their Open Source licenses, which are valid forever and for anyone, instead of the commercial licenses that MySQL currently has for these products. Because MySQL is a server, physically separate from its client applications, the GPL and its restrictions won't be a consideration for MySQL's customers.
MySQL could slap Oracle in the face by going with the GPL strategy: they wouldn't have to negotiate with Oracle, they could use InnoDB and Sleepycat in perpetuity, and they wouldn't have to pay Oracle a cent. I'd be tempted to take such poetic vengeance. But Oracle, which has tried to buy MySQL before, could trump the GPL strategy by increasing what it offers for MySQL enough to make that purchase go through. CEO Mickos won't dabble at vengeance and will keep looking at offers that - if nothing else - increase the evidence for valuation of his company. But MySQL probably won't merge - they see too large a market, and intend to have it for themselves.
Even an outright purchase of MySQL by Oracle would not prevent anyone from using MySQL's server in a commercial application, without charge. That's possible today if you use an unofficial (and non-GPL) client library to communicate with MySQL. Other companies in the Open Source community would happily provide training and support for MySQL, while an independent Open Source project would evolve to maintain the program.
You can't really buy an Open Source project. The GPL was designed to make it possible for any Open Source participant to circumvent any other party who gets in the way. Other Open Source licenses are similar. Larry Ellison can buy business and influence over an Open Source project, but if he tries to have absolute control, Open Source developers will code elsewhere, replace whatever Larry holds close, and create new businesses.
JBoss, the Open Source J2EE company said to be a $400 Million Oracle acquisition, hardly owns its market today. Commercial Java projects, even those using Open Source code, may develop on JBoss but predominantly deploy on proprietary software from IBM or BEA. Years ago a large contingent of JBoss developers split off into what is now Apache Geronimo project, an eminently viable competitor to JBoss.
If Oracle is true to their history of eating their own ecosystem, they might now use JBoss to go after BEA. BEA moved this week to beef up their own presence in the Open Source community by releasing some previously proprietary work as Open Source. Why? they'll be using Open Source to go after Oracle. Open Source developers smile as proprietary software companies fight each other by collaborating more.
Bruce Perens is sponsored by Sourcelabs to spend half of his professional time working for the Open Source community, with no company control over his activities or his speech (including this editorial). The other half of his work time, he's a Vice President for Sourcelabs, responsible for policy, the company's relationship with the Open Source developers, and professional services for Fortune 100 companies. Perens is best known as co-founder of the Open Source Initiative and the primary author of the Open Source Definition, the manifesto of Open Source. He is series editor of the Bruce Perens' Open Source Series with Prentice Hall PTR Publishers, which has published 21 books about Open Source. Each of the books has its text licensed as Open Source. He is Senior Scientist for Open Source with George Washington University's Cyber Security Policy Research Institute.