Sunday, November 28, 2010

Dispelling some unintentional MySQL FUD

Sakila dispelling FUD There are three types of FUD: the first and more genuine is (#1) the intentional spreading of falsehood, mostly to gain some marketing advantage over a competing product. While I despise this practice, I understand it.
Then there is (#2) FUD spread by ignorance, when the originators are so blindly enraged by their hatred for a product that they don't care about getting the facts straight.
And finally, there is a third kind, not less dangerous, which is (#3) the spreading of FUD with good intentions, when the authors believe that they have the facts straight and they want to help.
I have recently come across two examples of unintentional FUD. For different reasons, my comments to these public cases did not get through, and then I have to say something about that here in my blog.

MySQL is not ACID complaint

This surprising piece of news came in the blog of a company that calls itself the remote DBA experts.
The claim is this: if I insert a record in a table and then issue a ROLLBACK command, the record is not rolled back.
Anyone who has a minimal knowledge of MySQL knows about InnoDB tables (luckily for the poster, InnoDB is default in MySQL 5.5.6, which he was testing) and autocommit.
Reading through the example, one sees that the poster did not know about this piece of information. In MySQL, autocommit is ON by default. So if you want to rollback a record, you need to deactivate it. This is not optimal, and it can be debated, but if you read the docs, you don't claim something that is simply the result of your lack of knowledge. MySQL has shortcomings, but being unable to rollback a record is not one of them. Hence, this is FUD type #2.
Why I am writing all this here and not as a comment in that blog? Because I did post a comment, on November 23rd, but as of today, it has not been approved yet. The same is true for comments posted by other more knowledgeable people.

MySQL licenses. When it's free and when you need to pay for one.

This article is well intentioned. MySQL Licenses: The Do's and Don'ts of Open Source, or What's All the Fuss About? is a well thought piece, with practical examples, to help users decide what to do with MySQL licensing, i.e. when they need to pay and when they don't. Unfortunately, the article contains some unintentional confusion, and therefore leaves the readers with more wrong ideas than they had before.
I left a long comment on that blog, but for some unfathomable reason it was reduced to a tiny piece, and thus the need for explaining the matter here again.
The poster says this:
I make commercial software, which needs to have MySQL installed. My customers can use my commercial software, for which they do need to buy a license, in combination with the MySQL database engine, for which they don't need to pay. Because the MySQL engine is not embedded in my commercial software and I don't redistribute MySQL together with my software, I don't need a commercial license for MySQL and neither do my customers.
I am afraid that this wishful information is not correct. The GPL FAQ states it clearly:
If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL or a GPL-compatible license?
Yes, because the program as it is actually run includes the library.

Another quote:
However... as long as I have no desire to sell the embedded MySQL source code commercially, I can let the GPL license apply.
Also this is not true. The GPL does not regulate commercial transactions. It only deals with distribution of software. If I want to distribute a public domain but GPL-incompatible software linked to a GPL application or library, I am violating the GPL, even if I don't charge anything.

Another source of disinformation is "If you decide to pay for a MySQL license, you don't actually pay for the software."
This is also incorrect. Oracle sells two kind of things with MySQL. One thing is a subscription to services (MySQL Enterprise). If you buy this, you are not getting a license (unless you ask for it explicitly) but an agreement about services for a given periods.
The other thing that Oracle sells is licenses. They can do it because they own the source code, and they can decide to release it either as GPL (which is what you download from the MySQL site) or with a commercial license. If you ask for a license, you will most definitely get one. You can also get a license together with a subscription, if you are so inclined, but that doesn't mean that you aren't buying a license.
The important thing to understand to put the matter in perspective, is that the above information about licensing was still true before 2008, when MySQL was owned by MySQL AB, and it is still true today. Oracle, despite all the preemptive accusations of being ill intentioned, has not changed the rules of the game.

14 comments:

Anonymous said...

I take your point about the MySQL client library being GPL, and not LGPL, but it's worth mentioning that libdrizzle is a BSD licensed client library that is compatible with MySQL.

Giuseppe Maxia said...

@anonymous,
So what?

Henrik Ingo said...

Hi Giuseppe

Actually, you are also a bit behind on the latest news here.

Another source of disinformation is "If you decide to pay for a MySQL license, you don't actually pay for the software." This is also incorrect. Oracle sells two kind of things with MySQL. One thing is a subscription to services (MySQL Enterprise). If you buy this, you are not getting a license (unless you ask for it explicitly) but an agreement about services for a given periods.

On this point neither of you are correct: with the new Oracle pricelist, they do sell licenses. (Or in the case they are not perpetual licenses, you might say they "rent" licenses.) If you take an Oracle subscription, the default is that Oracle offers you binaries under a proprietary license. This is according to http://blogs.the451group.com/opensource/2010/11/11/is-mysql-open-core/ where the author also talked directly to Oracle.

I am afraid that this wishful information is not correct. The GPL FAQ states it clearly: If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL or a GPL-compatible license? Yes, because the program as it is actually run includes the library.

The idea of how the GPL works is clear to us. Where the effect of the GPL actually begins and ends has always been a matter of debate, especially for MySQL and the standard use case of a client server application. For instance, you yourself was active in removing comments from the source code claiming that the GPL travels from the server to the client via the "proprietary" MySQL client protocol, which Sun MySQL sales manager asserted even relatively recently. (http://krow.livejournal.com/684068.html?thread=2669860#t2669860) Probably against the official company policy of course, but still a good example of over asserting the GPL quite recently.

Anyway, Oracle has been very clear that in their view the GPL does not affect an application that connects to a MySQL server via the standard interfaces like JDBC etc. This opinion is well documented for instance from the acquisition process.

Whether you personally agree with Oracle's interpretation is of course a different matter, but since the original poster claimed to have talked to an Oracle representative, I have every reason to believe that a) he reported on that discussion correctly and b) Oracle is being consistent in their view on this issue. (Which is very welcome, to be honest!)

(There are of course still many use cases where most of us agree that the GPL would apply, such as the trivial example of an OEM that actually mixes his own code into MySQL source code. Most FOSS lawyers also agree that libmysqld is a clear such case, but there are also differing opinions.)

Giuseppe Maxia said...

(Comment received from Henrik Ingo)
Hi Giuseppe

Actually, you are also a bit behind on the latest news here.

Another source of disinformation is "If you decide to pay for a MySQL license, you don't actually pay for the software." This is also incorrect. Oracle sells two kind of things with MySQL. One thing is a subscription to services (MySQL Enterprise). If you buy this, you are not getting a license (unless you ask for it explicitly) but an agreement about services for a given periods.

On this point neither of you are correct: with the new Oracle pricelist, they do sell licenses. (Or in the case they are not perpetual licenses, you might say they "rent" licenses.) If you take an Oracle subscription, the default is that Oracle offers you binaries under a proprietary license. This is according to http://blogs.the451group.com/opensource/2010/11/11/is-mysql-open-core/ where the author also talked directly to Oracle.

I am afraid that this wishful information is not correct. The GPL FAQ states it clearly: If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL or a GPL-compatible license? Yes, because the program as it is actually run includes the library.

The idea of how the GPL works is clear to us. Where the effect of the GPL actually begins and ends has always been a matter of debate, especially for MySQL and the standard use case of a client server application. For instance, you yourself was active in removing comments from the source code claiming that the GPL travels from the server to the client via the "proprietary" MySQL client protocol, which Sun MySQL sales manager asserted even relatively recently. (http://krow.livejournal.com/684068.html?thread=2669860#t2669860) Probably against the official company policy of course, but still a good example of over asserting the GPL quite recently.

Anyway, Oracle has been very clear that in their view the GPL does not affect an application that connects to a MySQL server via the standard interfaces like JDBC etc. This opinion is well documented for instance from the acquisition process.

Whether you personally agree with Oracle's interpretation is of course a different matter, but since the original poster claimed to have talked to an Oracle representative, I have every reason to believe that a) he reported on that discussion correctly and b) Oracle is being consistent in their view on this issue. (Which is very welcome, to be honest!)

(There are of course still many use cases where most of us agree that the GPL would apply, such as the trivial example of an OEM that actually mixes his own code into MySQL source code. Most FOSS lawyers also agree that libmysqld is a clear such case, but there are also differing opinions.)

Anonymous said...

@datacharmer
So what? My point is that you're assuming Mr Schonewille's hypothetical commercial application is linked with the GPL'd client library. If they linked with libdrizzle they wouldn't need a license, and it wouldn't be wishful thinking.

Stewart Smith said...

good to clear it up.

libdrizzle is an interesting one as it means that if you are not distributing the MySQL Server and your product is not GPL licensed, then you can use libdrizzle and avoid licensing fees from Oracle (as you have included no GPL licensed code from MySQL).

Also interesting only to the superbly pedantic: Oracle doesn't own all the MySQL Server code. Interestingly enough, there's parts to which it just has an appropriate license (BSD).

shantanu said...

>> This surprising piece of news...
may be wrong. But the bug 45309 is real and it justifies raising the concern about ACID compliance.

http://bugs.mysql.com/bug.php?id=45309

I guess some people are more annoyed due to bugs like (29898) Date function returns inconsistent results or (28929) Comparing date field with now broken.
or atleast I evaluated my options when I was hit hard by the bug 29898. I could upgrade the version, but in that case there are other bugs related to the new version waiting in wings. Tracking bugs should not be the only task I will be doing.

Mark Callaghan said...

@shantanu - I am confused by your comment.

The "MySQL is not ACID" article cited by Giuseppe is misleading to some of us because it really should be "MySQL DDL is not ACID". I don't care much about. It would be nice if DDL could be part of a transaction but it isn't a big deal to me.

The bug you cited has nothing to do with DDL. Nor does it have anything to do with violation of ACID behavior. The bug is that InnoDB does not rollback a transaction in some cases when a statement is killed. That means that the transaction is still open and can be committed or rolled back by the user. While the behavior is probably not desirable, the transaction is not busted.

Finally, what do any of the other bugs you mention have to do with the topic of this post?

Surachart Opun said...

I don't use mysql, but I know about "MySQL is not ACID complaint" topic.

He can use "autocommit=" for rolling back data.
and we can change transaction isolation on mysql...

hingo said...

@stewart:
"it means that if you are not distributing the MySQL Server and your product is not GPL licensed, then you can use libdrizzle and avoid licensing fees from Oracle"

What you say is true otherwise, but the "not distributing the MySQL Server" part is irrelevant/distraction. The GPL itself even states that just because you distribute two separate pieces of software together doesn't mean that GPL applies from one to the other. On the other hand this also follows from copyright law, that one piece of software is not a derivative work of another just because they are stored on the same CD, same ZIP file, etc... As an example, many packages on a Linux CD can connect to a MySQL Server, but this doesn't make them GPL (such as PHP with its own PHP ND driver).

In other words, whether MySQL Server is distributed together or separately with something else is a completely irrelevant factor.

strcmp said...

He uses BEGIN and ROLLBACK, which should switch off autommit temporarily. At least that's what the manual says:

"
To disable autocommit mode for a single series of statements, use the START TRANSACTION statement:

START TRANSACTION;
SELECT @A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summary=@A WHERE type=1;
COMMIT;

With START TRANSACTION, autocommit remains disabled until you end the transaction with COMMIT or ROLLBACK. The autocommit mode then reverts to its previous state.

BEGIN and BEGIN WORK are supported as aliases of START TRANSACTION for initiating a transaction. START TRANSACTION is standard SQL syntax and is the recommended way to start an ad-hoc transaction.
"

Justin Swanhart said...

@strcmp,

The autocommit thing is somewhat of a red herring.

In MySQL all DDL (with minor exceptions like CREATE/DROP TEMPORARY TABLE) do an implicit commit.

Transactional DDL is actually rather uncommon.

SET storage_engine=INNODB;
SET SQL_MODE=STRICT_TRANS_TABLES;

BEGIN;
CREATE TABLE blah (c1 int); #implicit commit

#note autocommit is true
#we are no longer in a transaction because CREATE TABLE committed.
insert into blah values (1);
#committed

#does nothing
rollback;

-- Contrasted with the right way --

#implicit commit
CREATE TABLE blah (c1 int);

#start new transaction
BEGIN;

#we are in a transaction
insert into blah values (1);

#rolls back the change
rollback;

Anonymous said...

Perhaps Datacharmer, or somebody should take the time and publicly discuss the implications of using a BSD license "shim" to interface with a GPL'd project that has a collection of FOSS exceptions.

I believe all of those parts (GPL, FOSS exception, BSD) come into play.

GPL:
GPL requires open sourcing of all code.

FOSS EXCEPTION:
GPL including MySQL may include a FOSS exception. Meaning linking with other open source code such as BSD , or apache, or whatever PHP uses.. is okay.

BSD SHIM:
By linking to the BSD code and isolating the GPL code the user is able to isolate the requirements of the GPL's viral nature.

This topic is very very important for a dual licensed project like MySQL especially due to the opinion regarding "linking" and use of the protocol.

Or perhaps for other reasons..

--
Tom Hanlon

Ivan said...

Giuseppe,

"One thing is a subscription to services (MySQL Enterprise). If you buy this, you are not getting a license (unless you ask for it explicitly) but an agreement about services for a given periods."

This is not correct. MySQL Enterprise now comes with a commercial license.

Perhaps for the sake of the article you mentioned, it does not change anything, but for end users, this is a change that has a massive impact.