Slashdot Mirror
Oracle Acquires Sleepycat
Deven writes "Computerworld is reporting that Oracle has just acquired Sleepycat Software (makers of the open-source Berkeley DB embedded database) for an undisclosed sum. Having previously acquired Innobase, Oracle is certainly taking a look at diversity."
Diversity? It looks more like careening towards homogeneity to me. First they bought Innobase, giving them the ability to cut MySQL's transaction nuts off, then they buy another open-sourece-friendly DBMS which has transaction capability.
Now, if you were the largest commercial DBMS vendor in the world and you were worried about the OSS people moving into your space, what would you buy in order to stop them cold? Me? I'd keep them out of atomic transaction space.
Do keep in mind we are talking about Larry Ellison here. Just google on "larry ellison greed" to see what some other people think of this champion of diversity.
The price of these acquisitions is chump change for Oracle. My bet is that they are buying these companies to destroy them. Oracle does not want something like Mysql becoming a real threat to their DB business, so the tried and true solution is to kill the babies before they grow up. They will attempt to migrate what customers they can and then stop development on the acquired code bases. The acquired developers, if they stick around, will be put to work building migration tools.
This seems like it fits with their other purchases if their strategy is to kill of the commercial incarnation of MySQL. First the InnoDB purchase threatened MySQL's commercial business being the primary transaction based backend, and now BDB too is threatened.
Can MySQL license the code (and any patents covering it) to continue commercial MySQL sales/support?
LL
There are two important decisions that I think are relevent:
(1) Oracle bought not one, but TWO mysql backends, which happened to be both of their transactional backends.
(2) MySQL AB licenses the client libraries under the GPL.
The only conclusion that I can come to from either of those is control.
MySQL AB needed control over their MySQL database, and so they restricted the distribution of the client libraries. You can argue about what licenses are acceptable for libraries in general, but for a client-server program, it is very strange to restrict the distribution of the client libraries. The decision therefore must have been deliberate, and made for a business reason. That reason is control.
And Oracle obviously made a business decision. There was question about the motives after buying Innobase, but those questions are now answered when they purchased the only remaining candidate for a transactional storage engine for the MySQL commercial product.
So here we have Oracle which clearly thinks they have control over MySQL AB, and MySQL AB which clearly thinks they have control over the MySQL database. For that to be false you would have to assume that one of those companies made a serious error in their business decision. So, Oracle now has some substantial degree of control over MySQL database.
To prevent Oracle from exercising this control, we need to
(1) fork the MySQL database
(2) do a cleanroom reverse engineering of the client libraries and make them LGPL/whatever (in order to keep current commercial MySQL users in business)
(3) fork InnoDB and/or BDB to make sure we have an open source backend that is actively developed.
By that time, it will all be irrelevant.
Fortunately, PostgreSQL is immune from these types of licensing problems. The client libraries and the database itself are freely destributable. And the developers work for a wide variety of companies. As far as I know, FirebirdSQL, Inges, and SAP DB are also free of licensing problems. That's 4 good alternatives if Oracle really tries to set MySQL back.
Social scientists are inspired by theories; scientists are humbled by facts.
Comment removed based on user account deletion
Good Luck in writing a transactional backend engine. It's hard work and requires quite a few people with deep knowledge of databases on a very low level and I know since i work in the business. Add to the fact that you have to start from scratch, that you will have to come up with something that has enough performance to be a viable alternative and it needs to be tested thoroughly on all platforms and be wordsize and endian independent.
Some people talk out of their behind.
If you mod me down, I *will* introduce you to my sister!
I completely agree: PostgreSQL should now be *the* open-source database of choice.
I used to use MySQL extensively. Then six months ago, a new client required that we use Postgres. What an eye-opener! Honestly, I'm *never* going back to MySQL. I can't believe I wasted all that time trying to get MySQL work properly, configured right, rewriting SQL to work-around holes in their implementation...
PostgreSQL is fast, stable, and full-featured. It also has a good *open-source* front-end GUI client, pgAdmin. Our production database has never failed in the four months since we released. The required configuration, administration, and maintenance is pretty minimal. You can fairly well just install it, create tables, and start putting data in. The feature set is so much better than MySQL. And you don't have to worry about some company (MySQL AB, or worse, Oracle) controlling your future.
There are probably areas that MySQL does better (replication, perhaps?), but for most situations I have to think that Postgres is better. Plus, when your company gets bought out by the suits for big bucks and they switch you to Oracle, you'll have to rewrite less SQL than if you started with MySQL!
Why is MySQL so popular? Marketing. I think MySQL just got some marketing buzz behind it (probably because they actually have a company to do public relations), then someone coined that dumb LAMP acronym, and O'Reilly publicized the heck out of it. Forget that LAMP stuff; go with LLPRR (OK, an even worse acronym) -- Linux/Lighttpd/PostgreSQL/Ruby/Rails. Or maybe Nitro/Og instead of Rails; hear it's great but haven't checked it out yet...
Unh.... The problem exists because those programs *weren't* under the GPL.
Now I suppose that it's true that you can equally fork the open code of a BSD project, but it won't necessarily all be open.
OTOH, it's also true that if MySQL were involved with the SleepyCat code, it wouldn't take them long to issue a new edition...provided that the licenses allowed this, as I'm pretty sure they do. (I don't know. I'm not lawyer, and I've always though of SleepyCat as proprietary, with all the dangers that that implied. I've also thought of it as OpenSource, in distinction to, e.g., Faircom's CTree.)
Maintaining the back-end to the database would be more work, but there doesn't appear to be anything inherently impossible about it. And until you do get it working, you can continue to use the present version.
InnoDB may be much more problematical....but isn't MaxDB a totally separate product that is equivalent to MySQLDB, but with built-in B+Tree? (This *is* a serious question, as I've only been peripherally following this issue...but I thought that I had heard that it wasn't really anything serious.)
I think we've pushed this "anyone can grow up to be president" thing too far.
The _whole point_ of the GPL is to have conditions on the very things you say should be removed. The GPL doesn't need to be changed - if you don't like the conditions of the GPL, use BSD (or other) licensed software. MySQL chose the GPL for a reason - if they wanted a license with the features that you list they would have used a license like that; but they did not.
If you don't want a GPL'd database, use PostgreSQL.
Oolite: Elite-like game. For Mac, Linux and Windows