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."

Comments

Taking a look at Diversity?

[hedronist]

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.

Chump change to Oracle

[jonsmirl]

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.

Re:Why do this?

[jadavis]

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.

Re:Why do this?

[IdleTime]

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.

Re:Interesting ....

[HiThere]

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.)