Oracle Acquires Sleepycat 403
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???? (Score:2, Insightful)
Uhhh... it looks to me like they are purchasing their competition to either insure it isn't developed to the point that it can be a serious threat to their own database product or to quietly change it so much that it's useless and kill the project. Wouldn't be the first time this has happened...
Taking a look at Diversity? (Score:5, Insightful)
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 (Score:5, Insightful)
Are they just trying to derail MySQL? (Score:3, Insightful)
As the developer of an application [citadel.org] that uses Berkeley DB for all of its data stores, I am more than a little concerned about this. Does Oracle see any actual value in Sleepycat, or are they just doing this to shut them down?
Cutting MySQL's other leg off? (Score:4, Insightful)
Can MySQL license the code (and any patents covering it) to continue commercial MySQL sales/support?
Re:Its not competition (Score:3, Insightful)
Now, the commercial distribution of MySQL may be weaker than the GPL version, because Oracle can stop licensing the "good" backends to MySQL AB for them to license to you. And the GPL version is highly restrictive because you can't link the client libraries to non-GPL clients.
And if MySQL AB stops developing MySQL because they can't sell people a database without transactions, the development organization of MySQL database is gone. It takes a long time and/or a lot of help to get that organization back, and by that time it may be irrelevent.
Re:Why do this? (Score:5, Insightful)
(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.
PostgreSQL is safe from Oracle (Score:2, Insightful)
Sure the MySQL engines are open source and you can always fork it if they change the license, but forking such massive projects is unrealistic, and Oracle knows this.
The project I'm currently planning is going to use PostgreSQL, instead of MySQL as usual; Oracle can't buy it because it's not owned by a single company. No matter how much Oracle tries to buy out competition there'll always be PostgreSQL.
Comment removed (Score:4, Insightful)
There arre two reasons to buy a company... (Score:1, Insightful)
Re:Two MySQL backends owned by Oracle (Score:3, Insightful)
Re:Why do this? (Score:5, Insightful)
Some people talk out of their behind.
Re:PotgreSQL... (Score:2, Insightful)
Guess it depends how you use your database. MySQL tanks under any kind of concurrent load. MySQL eats flaming death with complicated queries. Neither does MySQL support features such as procedural languages, custom aggregates, bit-mapped indexes or tablespaces. In other words, it's either a really slow filesystem with a few extra features spooged on, or a reasonably quick toy database that's about the same speed as postgres, as long as you don't go trying to do something that would require a real database.
Easy setup and administration?
Yeah, postgres is really hard to setup.
apt-get install postgresql
sudo su - postgres
createuser noob
^D
createdb its_just_not_that_tricky
Or you could just download and install one of the gui tools if command lines scare you.
Handy SQL extensions?
Oh, you mean like how there aren't any procedural languages supported? You know, the ones that would obviate the need for hackish extensions that only half solve a given problem? Or perhaps you're talking about all the dumb foot cannons that MySQL AB thought was clever [sql-info.de]?
Enterprise features for those who want them and not for those who don't?
Like... replication [slony.info]? Oh wait, that's a postgres feature that MySQL hasn't even dreamed of supporting. MySQL only just recently figured out what a transaction is a couple of years ago. They still haven't figured out NULL. I'm not sure exactly what enterprise features you're refering to, but then I don't think you are either since MySQL hasn't got any. Which is probably why nobody uses MySQL in enterprise environments whereas Postgres a non-trivial chunk of the internet [afilias.info].
Re:Interesting .... (Score:2, Insightful)
Even more scary is this: the license exception for linking MySQL's libraries with non-GPL open source software lists specific versions of those licenses. If Oracle ever managed to buy MySQL AB, MySQL itself could even become unusable with future versions of PHP unless they never update their license. Now -that- is scary.
The GPL needs to be fixed. The zealotry needs to be put aside and people need to realize that internal corporate use of software should trump so-called "freedom", so long as the modified versions of the software are not distributed outside an organization/corporation and its partners. The GPL needs to make it clear that it does not ever restrict users of software, only public distribution thereof. Otherwise, these problems will keep popping up (and getting worse).
The GPL also needs to be fixed to explicitly allow linking with software licensed under any OSI-approved open source software license, without regard to any conflicting licensing terms. I actually brought up the flip side of this issue (modifying other licenses to play better with the GPL) in an email to RMS back in the late 90s, and I seem to recall suggesting even at that time that running into linking problems between open source software over licensing terms was really rather silly. I'm somewhat surprised that even after all these years, the GPL is still such an utter pain in the ass to deal with unless you only write GPL software....
But for now, we have to deal with the situation as it is. Specifically, we need to find a viable BSD-licensed (or at least LGPL-licensed) back end for MySQL. If we don't get one, MySQL adoption could very well suffer greatly in the business world.
Oh, well. There's always Postgres (and, to a lesser degree, Ingres, as long as Oracle doesn't buy them out).
Re:PotgreSQL... (Score:3, Insightful)
What's keeping MySQL afloat? Hmmm... Incredible speed? Easy setup and administration? Handy SQL extensions? Enterprise features for those who want them and not for those who don't? These things matter, and PostgreSQL, for all that it is an impressive database, does not have them.
Not to mention built-in replication that you can setup in five minutes and just works. Last I looked, which wasn't too long ago, getting PostgreSQL replication working is a real mess involving other products.
I used to use PostgreSQL extensively but the replication situation just killed me.
Re:PostgreSQL... (Score:3, Insightful)
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...
Re:PotgreSQL... (Score:3, Insightful)
And yes, I've worked with both (not to mention Oracle, too).
Re:Interesting .... (Score:3, Insightful)
Also, remember that what you're talking about is only the FSF's legal opinion on the subject. While this can be construed as being effectively part of the license for software copyrighted by the FSF, it is not binding upon any other GPL software author, which means that for any corporate environment to embrace GPL software directly is a scary thing, requiring legal departments to contact the authors of each individual GPL program and ask them to confirm that their interpretation of the license coincides with the interpretation presented by the FSF.. About the only way I would ever touch MySQL in a corporate environment without a commercial license would be through a layer of indirection like PHP or Perl (whose licenses are dramatically more palatable for corporate use).
The bottom line is, if it isn't in black and white in the license, a legal opinion from the FSF isn't worth the paper it is written on... and even if it were, their opinion is still too restrictive to be practical for most in-house corporate use in a company with over about a hundred employees, where contractors do work at home or off-site at vendors, where vendor relationships do require sharing of internal tools, and where any limitation on internal or partner distribution will require either buying a commercial license with non-GPL terms or simply being unable to use the GPL software at all.
Re:Interesting .... (Score:3, Insightful)
Re:Interesting .... (Score:5, Insightful)
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.)
Re:Taking a look at Diversity? (Score:4, Insightful)
MySQL just had the hype.
Re:Interesting .... (Score:4, Insightful)
If you don't want a GPL'd database, use PostgreSQL.
Re:PotgreSQL... (Score:3, Insightful)
You've been warned! Prepare to duck!
Frankly, MySQL users are justifiably tired of being reminded that they picked an overhyped dog of an RDBMS and they will do just abou anything to assure their egos remain unbruised. It's not like you can really blame them. MySQL, as a company, has spread so much complete BS about PostgreSQL and even more BS about how great MySQL is, it's hard to debate the topic. You can always tell when someone is spewing the MySQL party line because it's always the same misinformation and complete BS.
Here is a list of the common party BS lines:
o PostgreSQL does not have replication. This is of course false. In fact, you have your ready choice of replication options; including commerically supported implementations.
o Replication for PostgreSQL is complicated, inflexible, and painful to set up. This is, of course false. Replication can be set up in about 10-20 minutes, depending on your skillset and capabilities.
o PostgreSQL is slow. This is of course false. Having said that, PostgreSQL may not be the fastest tool for every solution but it scales wonderfully. PostgreSQL's query optimizer, compared to MySQL's, is lasers versus clubs.
o PostgreSQL is not stable. This is of course, false. This may of been true a decade ago. Realistically, even crappy biased (in MySQL's favor) tests which have attempted to compare the two are often unable to complete their tests with MySQL because it crashes or simply becomes completely unresponsive. MySQL is both unstable and scales poorly compared to just about any other well established RDBMS.
o PostgreSQL is lacking key SQL features like MySQL. This is, of course, completely false! It is MySQL which is lacking many ANSI SQL features. In fact, like most of proprietary SQL vendors, they make every attempt to push their own lock-in extentions rather than support standard ANSI SQL.
o Oh, let's not forget the classic... I've seen a website which is mostly read only run via MySQL, therefore, it's the best RDBMS ever created!
This could go on and on and on...but you get the point.
Summary:
MySQL is used by the ignorant masses swayed by marketing hype and lies propagated by MySQL.
Re:PotgreSQL... (Score:3, Insightful)
- Because MySQL web hosting is everywhere despite it's bugs, it's lack of features, it's violation of elementary SQL statement standards thus frustrating and bogging me down fiddling with the schema while I could do better things. Think MSIE HTML bastardization.
- Because often I had to put up with it because some CMS, portal platform I wished to deploy has this damned DBMS hardcoded rather that wrapped in a sane Object to ODBC/SQLdialect mapping
- Because all these pains in the ass happen because the common understanding is that since MySQL is the M in LAMP everyone should and will use it, just like sites designed and optimized around MSIE gaping bugs.
Re:No, I'm quite right. (Score:3, Insightful)
Re:PotgreSQL... (Score:3, Insightful)
Maybe that explains it. maybe that rabid fanboyism and general jihad against everything not related to their favourite piece of software is spreading to PostgreSQL?
Nope, first and foremost I'm a unix geek. Lived off Linux since RH5.1 and got the PostgreSQL syndrome way back. Mac user since OSX because of it's unix goodness
When I started learning SQL I shopped around for a DBMS, tried MySQL, read the criticisms, hated the documentation, found the inconsistencies in the language, hated it for the inexplicable error handling, dumped it. Moved to PostgreSQL, walked through the tutorials, read about ACID, saw that I could do it on PostgreSQL and understand where I'd fail doing the right thing. Had some complaints on quoting in the SQL statements but overall found it comfortable to use opposed to messing around with obscure 'leet d00d gotchas sprinkled around.
Many php script bunches, some quite neat, take MySQL for granted, like many sites do with MSIE. I don't want MySQL lying around my systems so I'm the one that's forced to follow other people's choices! What's so difficult in wrapping dB access behind a facade? Don't want to mess around with PostgreSQL? Fine, I can write and contribute the backend but if the mysqlconnect code is sprinkled around the scripts is it my fault for whining or is it because of poor design?
MySQL bogs down when doing DB tasks, fast when doing pure reads; still slower that a filesystem though so why not just go with filesystem based spools? Those are easy to tar-up while MySQL chokes on it's own schema dumps and doesn't even warn about inconsistent data fields! It substitutes it with default values! It messes with the data and doesn't even tell me about it! Sorry MySQL is a toy, it's only good to discriminate those that know their shit from the wannabees.