Category Archives: mysql
EU tilting at windmills
OK, I confess. I didn’t expect the EU to worry about the Oracle-Sun takeover. At least, not more than it is obliged to do by virtue of the sheer size of the companies. Unlike the once-rumoured IBM-Sun deal, there are few areas of major overlap between Oracle and Sun, and none in which the companies are so dominant as to smell of monopoly. The US competition authorities raised no concerns, and I’d’ve expected the EU ones to do likewise.
Well, OK, there’s Java, over which some have concerns. And there’s the database. It’s true: Oracle and Sun own two market-leading databases: Oracle leads in the enterprise, while Sun (MySQL) leads on the Web. This latter is what apparently causes concern to the European Commission.
So what’s the worst that could happen? Oracle lets MySQL wither on the vine and supports only a proprietary derivative at a high price, thereby depriving the MySQL community? Erm, that’s exactly what caused concern amongst some when the deal was first announced! But it’s hardly realistic: MySQL’s open-source heritage ensures it can’t be killed so long as it has a community of interested users. Indeed, there are already MySQL forks out there, and MariaDB, Drizzle, or AN Other could stand to take the place of the original amongst the community if Oracle were to try anything too dumb.
As could PostgreSQL, or maybe some alternative disruptive technology we haven’t thought of in this context.
I have no doubt Oracle is well aware of this, and that they didn’t get to be a 100-billion-dollar company by shooting themselves quite so spectacularly in the foot.
No, the biggest risk to competition lies in the cloud of uncertainty that prevails while the deal is in limbo. By worrying about an Oracle/Sun monopoly and delaying the deal, the EU commission could inadvertently come close to handing one to IBM.
He told us so!
Anyone who works in or with software knows the danger of a product/project being orphaned: left unsupported, and its users in limbo, facing forced migration to something else[1]. It is a strong argument in favour of open source: if you have the source, then if the worst happens and your supplier/support organisation disappears, or is bought up by someone hostile to it, you can hire someone else to maintain it.
My Apache colleague Gianugo Rabellino (one of the most interesting thinkers and inspiring speakers anywhere in the FOSS world) has argued for years that open source alone is necessary but not really sufficient, and for a product, you need open development. This evening he’s one of the many bloggers to comment on the Oracle acquisition of Sun, and argues there is now a danger of MySQL being orphaned and its users left in limbo despite MySQL being open source (GPL)! His thesis (here) is that if Oracle wants to stifle MySQL, they can make it very unrewarding for anyone else to pick up development.
I don’t think his point completely stands. If enough of the original/current MySQL team were to leave Oracle en masse, they could pick up development, and make a support business of it on the basis of their reputation, in spite of not owning the IP. But that’s not a nice scenario, compared to MySQL as an independent or within Sun. Or of course within a supportive Oracle.
On the subject of MySQL itself, I’m more optimistic (albeit through the perspective of benefit of the doubt – I want this to be good). While acknowledging the danger, I’m sure Oracle can see the business case for maintaining a healthy MySQL product and community[2]. LAMP and other FOSS users are not short of credible alternatives: obvious candidates include PostgreSQL for serious applications or SQLite for lightweight php-ish stuff, and if MySQL loses its bloom, they’ll migrate. Surely better for Oracle to keep them on-side, make tiny margins on LAMP business and support, but gain a serious market from those who grow big and might be sold a smooth upgrade to a top-end platform where Solaris and Oracle replace Linux and MySQL.
[1] Even Government seems to have got the basic message!
[2] What’s MySQL’s current market share? Is it more than all other SQL databases combined?
Apache, PHP, MySQL Library Versions
There’s a problem that’s being discussed on techie lists, but could probably use the marginal extra exposure of a blog entry here.
Symptom: An Apache+MySQL application works. An Apache+PHP+MySQL application works. But try to run them both on the same server, and it segfaults.
Diagnosis: PHP’s native MySQL support links the libmysqlclient.so client library, but Apache’s DBD (apr-dbd, part of the apr-util library that manages a dynamic connection pool) links the libmysqlclient_r.so client library. Linking both libraries in the same executable creates a conflict, causing a crash.
The difference between the two libraries is that libmysqlclient_r.so is thread-safe and reentrant, whereas libmysqlclient.so only supports simple apps. Since APR and Apache use threads, they must use the former version. In PHP’s case, there is (AFAIK) no difference, so it could equally well use either version. That leads us to
Solution 1: Rebuild PHP to use libmysqlclient_r.so. Alternative (at your own risk) build apr-util with libmysqlclient.so. The alternative will probably be fine with Apache if you use the prefork MPM (which you’re almost certainly already doing if you use PHP), but could screw up other APR applications that rely on thread-safety.
Could the same conflict reappear elsewhere? I don’t know of any cases, but I wouldn’t rule it out. So here’s a solution that’ll fix it once and all. Globally!
Solution 2: Remove libmysqlclient.so and substitute a symlink to libmysqlclient_r.so.
I don’t know if there’s a downside to either of those solutions: don’t do anything irrevocable until you’ve tested! I guess libmysqlclient_r.so might have a bigger memory footprint than libmysqlclient.so in apps where either would work. If any more serious issues come to my attention, I’ll document them here.
Mergers & Acquisitions Day
So, all within a day, Sun acquires MySQL, and Oracle acquires BEA.
About the latter, I have nothing to say, beyond “may I be spared having to work with their ghastly software ever again“. But the former is definitely interesting, and probably good news. If nothing else, it removes any risk of MySQL being gobbled up by someone altogether more sinister, as happened to sleepycat.
There are some pretty convincing reasons why Sun should be interested in this. MySQL is by far the biggest database in the Web applications world, which is obviously important to them. And Sun is leapfrogging its big rivals IBM and Microsoft, both of whom have major SQL database products but nothing like MySQL’s market share. Furthermore, MySQL’s approach based on open source with corporate governance should be thoroughly at home at Sun.
As for MySQL – well, apart from the money, I expect the Sun name and worldwide organisation may open new doors for them. Not that they were some startup-in-a-garage, but they did come from low-end origins, and have moved up the market over the years. I expect the alliance with Sun will help MySQL’s image as a top-end product backed by a top-end company, for those who care about such things.
New DBD drivers
Today I committed two new DBD drivers to APR: the MySQL driver apr_dbd_mysql, and the FreeTDS driver apr_dbd_freetds. Note that these are in /trunk/, and will not feature in an APR release for a while.
The MySQL driver was formerly available from WebThing, but not committed to apache because of licensing issues. But the subject was discussed again in August, and we finally decided there isn’t a licensing issue that prevents us including it, so all that remained was for me to get a round tuit. That should make life easier for packagers, such as the debian folks.
The FreeTDS driver is new, and brings support for Microsoft SQL Server and Sybase to APR and Apache. Not everything is fully functional, but it’ll suffice for typical web applications.
The FreeTDS driver also adds a new feature to DBD: Perl-like strong taint checking of user inputs to prepared statements. I’d like to think about moving that to the apr_dbd.c level, so it’s available to all drivers.
Apache/APR MySQL Driver
The subject of bundling the MySQL driver with APR has resurfaced on the APR developer list.
It looks different to last time it was discussed. We can still argue over whether the driver or anything else is a derived work within the meaning of the GPL. But we don’t really need to: we have MySQL’s FOSS “exception” explicitly sanctioning what we want to do. And we’ve reviewed it in the context of Debian bundling the driver.
Suppose we were distributing a non-free product that was arguably a MySQL “derivative work” under the terms of the GPL. We could negotiate terms with MySQL. For a commercial product, that would probably mean paying them money, but that’s beside the point. Under our agreement with MySQL, we can distribute our product on our agreed terms, without reference to the GPL. No problem.
But that’s exactly what the FOSS Exception gives us. Explicit permission to distribute our product under the ASL. We didn’t pay for it, but we got it anyway. End of problem.
I think that driver could finally be migrating to apache.org. Thanks to Joachim for prompting me to revisit the subject.
Interfacing MySQL to Apache
It seems my attempt to post to the mysql general list has been silently rejected, or otherwise lost. It would probably be futile to speculate on what’s going on. If anyone reading this has the ear of the MySQL devs, perhaps you can draw their attention to it.
To: mysql@lists.mysql.com
Subject: Tying actions to (re)opening a connection
Date: Sat, 7 Jul 2007 10:44:05 +0100The Apache DBD module maintains a dynamic pool of connections.
SQL statements may be defined at system startup. Such queries are then treated as prepared statements. In the MySQL driver, the sequence is:
mysql_real_connect for each defined SQL statement { mysql_stmt_init mysql_stmt_prepare }So far, so good. However, we also need to deal with connections that go stale. Our API defines a check_connection function. mysql_ping is *nearly* right for this, but unfortunately leaves us (silently) with a new connection without the prepared statements.
It would work perfectly if we could tie a callback to mysql_ping. Something like:
int mysql_ping2(MYSQL *mysql, int (*callback)(MYSQL*, void*), void *dptr);where the callback (if non-null) is invoked whenever mysql_ping detects a stale connection and reconnects.
Is this something you’d consider adding? Any other suggestions for a workaround to check the connection now?
Re-licensing apr_dbd_mysql
OK, I’ve re-licensed apr_dbd_mysql to permit distribution under the ASL 2.0 when aggregated with APR-UTIL. Due to the licensing incompatibility, this is necessary if it is to be aggregated. Which in turn makes life easier for end-users.
This follows recent discussion with the Debian packagers. The original problem is discussed in more detail here.
Apache/APR/MySQL packaging
My attention has just been drawn to Debian bugs 395959/403541 re: packaging the MySQL driver in apr-util. This is a legal problem of meeting the terms of all licenses involved.
That’s bad, because I believe packagers such as Debian are precisely the people best placed to make this integration available to end-users. Speaking as a key holder of the intellectual property in question, maybe I can help. I just posted an entry to the Debian bug tracker, but I’m not sure how that works. So I’ll blog it here for the record.
Hi,
Joachim has just drawn my attention to this report.
I am the original developer of the MySQL driver, and it was originally my decision to license it under the GPL. I’m also director of WebThing, and a member of the Apache Software Foundation (though not, in this message, speaking in an official capacity).
I’m not dogmatic about the licensing, and I’d be happy for it to change if it helps, subject to the constraints of the other licenses involved. Originally I’d have been more dogmatic about it, because apr_dbd_mysql released under the Apache license seems to risk undermining MySQL’s GPL rights, and I didn’t want to be responsible for that. However, MySQL AB has made it clear that they are happy to live with that: indeed, they explicitly name APR and the Apache license at http://www.mysql.com/company/legal/licensing/foss-exception.html
So the sticking point is no longer the GPL, but rather ASF policy, which does not permit us to distribute anything that would impose restrictions on our users, over and above those in the Apache License. The ASF takes the view that to take advantage of MySQL’s exception risks leaving our users in limbo. That clearly doesn’t apply to Debian: your primary license is after all the GPL.
A quick google reveals that some Linux distros have apr_dbd_mysql as a separate (RPM) package, and have presumably built apr-util to enable dynamic loading of a DBD driver. This seems to me an excellent solution.
I hope Debian will see a way to make this available for your users. If I can help, please ask.
Half-open source
On October 17th, MySQL AB announced a new commercial offering, based of course on their renowned opensource database product. Apache folks Ian Holsman and Steve Loughran comment on the announcement.
But we have a very similar scenario even closer to home, with the acquisition by Breach Security of mod_security. I’ve actually been thinking about the possible implications of that one, with a view to featuring it in my column for El Reg, and my conclusion is that if Ristic and Breach play their cards right, this could be good news for everyone. Ristic’s interview with securityfocus is reassuring on this count.
One thing that may have profoundly affected the mod_security situation is the use of the GPL. Of course, Breach (like MySQL) can do exactly what they like with their product. But if AN Other bases a new product on it – and mod_security certainly has scope for that – it has a profound effect. In effect, Breach have bought themselves a monopoly on the right to release a closed-source enterprise edition.
niq's soapbox 