Posted
by
CmdrTaco
on Thursday April 23, 2009 @08:31AM
from the this-cracks-me-up dept.

viktor.91 writes "Sun Microsystems announced three new MySQL products: MySQL 5.4, MySQL Cluster 7.0 and MySQL Enterprise Partner Program for 'Remote DBA' service providers."
which showed up in the firehose today next to Glyn Moody's submission where he writes "Michael Widenius, founder and original developer of MySQL, says that most of the leading coders for that project have either left Sun or will be leaving in the wake of Oracle's takeover. To ensure MySQL's survival, he wants to fork from the official version — using his company Monty Program Ab to create what he calls a MySQL "Fedora" project. This raises the larger question of who really owns a commercial open software application: the corporate copyright holders, or the community?"

If MySQL had a BSD license it would be owned by the community.If MySQL had a "non-free" commecial license it would be owned by Oracle.The mess MySQL, and you, find yourselves in is because of MySQL's stupid dual-level license bullshit. Nobody seems to be able to figure it out or agree on it and it has caused more column inches of claptrap on Slashdot than the MySQL/PostgreSQL threads themselves. MySQL's originator's wanted to have it both ways: Lots-O-corporate money AND GPL poster child. Well they got their money alright, but to get it they had to pray for a really wealthy, poorly managed corporation to come along and vet their convoluted business plan. That would be Sun.

Now, with a billion dollars spent to "buy" MySQL but a bunch of forks still out there, no company in their right mind is going to invest anything in MySQL because they'll be worried Widenius will just steal the improvements and fork it again. MySQL is pariah, it's poisoned.

If you're running any kind of data volume worth talking about you're better off with PostgreSQL. Not only is it faster with *real* queries and more robust, but now it's safer going forward.

Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein.

Once the rights have been granted to copy, distribute and modify the program any attempt to revoke those rights is imposing further restrictions, which as the quoted section says is forbidden.

they way MySQL and stuff from the GNU/FSF is set up, they require contributors to sign the work over to them. Then the body in charge has ALL the rights and can do what they will. Like when the FSF moved everything to GPL 3, they could do that unilaterally because they had assignment.

Mozilla also has assignment and releases just what you say under a tri-license, the same code base published 3 times. Two are open source (MIT & LGPL) but the main Firefox branded binary is actually NOT open source. Anybody can fork the MIT or LGPL versions but has to strip all branding and can't call it "firefox" or "mozilla".

They can't UNLICENSE things already in the wild though. But much like Red Hat/CentOS, they could beat you up over every little point of branding (because they own the name) and keep suing you for every little code comment if they were that petty, leaving mountains of work for somebody to get "every reference" to the old name/logos out before distribution. Of course a fork is only useful if enough people follow you, and that's where nearly all the projects break down.... only the new parent company is big enough to provide new features and timely support.

On the other hand Linux is pure GPL 2. Because Linus has no "foundation" when he wrote it, contributions are still owned by the individual coders... moving off of GPL 2 is nearly impossible because many early contributors no longer work on Linux or are deceased. The copyright sticks, so the only way to change the license would be to rewrite the modules entirely.

As long as you don't need concurrent users. As soon as someone tries to update anything in the database, SQLite will lock the entire database until that update is completed.

I always consider SQLite to be a replacement for ad-hoc file formats, client-side storage, or anywhere else where you've got some data and something like SQL would be handy to manipulate it. Not so great as a replacement for database servers, unless everything's read-only.

I don't think that you can revoke GPL from your own previous releases (say MySQL 5 before the sun aquisition): "However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance." (from GPLv2)

Sun owns MySQL, they can do whatever they like with its source code, because MySQL the company requested copyright to be assigned to them to all contributors, now Oracle can even use that code inside their proprietary databases and even create a "MySQL mode" for Oracle DB like FreeBSD have a linux mode for its kernel, but using the real MySQL sources to implement it.

What can Monty Program Ab? do improve (deteriorate is an option too) the code, distribute it following the GPL, but creating a dual licenced version like they did previously, I do not think so, unless they request copyright again to all the people that worked building MySQL other than the developers at Monty Program Ab

SQlite has supported per-table locking for a while, and I believe it supports per-row locking in some situations. It is not designed for concurrent writes, but it can be great for anything read-heavy workloads. It's certainly not suited for situations where you have a lot of concurrent writes, but for a CMS it can be a very good fit.

If you want full-text indexing, transactions, and lots of concurrent users, PostgreSQL is generally a better bet. MySQL is being squeezed at the bottom by SQLite and at the top by PostgreSQL, and both have less restrictive licenses (public domain and BSD, respectively). I'm amazed that it's survived this long.

Most people I know that plan to start with a OSS database and move to Oracle start with PostgreSQL, since PostgreSQL mirrors the capabilities and features of Oracle pretty close, just it's not quite as fast. (But the PostgreSQL folks have been making progress).

The copyright holder, also, in theory, reserves the right to revoke any licenses that were given out.

I am going to have to see a citation for that. Unless that is written into the original license, that is completely wrong. In the case of the GPL, that is most certainly *not* the case. I am calling FUD.

Unless those principle devs are still working at Oracle they can't do the former, and the latter is only possible on future versions of MySQL so one can fork the last free version of the software and Oracle can't do a damn thing about it.

But what would the business model be? Any MySQL fork no longer has the ability to dual license the software since the copyrights have been sold. That's how MySQL AB made money.

Developers, and their families, can't eat freedom and self righteousness.

Exactly. Most OSS projects source files supply a header detailing the Copyright holders and the License it is distributed with. Mostly they grant you a non revocable right/requirement to use, extend and redistribute the code with your modifications added. If you add code, that peace of code is owned by you and is automatically under the parent license. It's the same with mySQL, although their License text is a bit murky, but the FOSS exception basically aims for GPL v2.

As for the trademark: it lies with Sun/Oracle and they can basically do whatever they want with it. The worst thing of which is that you are no longer allowed to call it mySQL. A simple rename to something else would solve that problem (you could for instance fork the code and call it ourSQL).

That's what most open source is about: play in one sandbox as long as you like, and fork once you have different non-compatible ideas.

That is not the case for the GPL family and BSD. The original author can't revoke at will any code licensed under those licenses.

Also, being irrevocable is a prerequisite for both OSI and FSS accepting a license, except when that revogation comes as a consequence of one act you practice, and is limited to the person practicing it.

If you want a really fast free database that supports fulltext indexing, and you don't need transactions, MyISAM in the engine to use.

That's exactly what I thought for a while. Then I built a system where many, many people were using it all at once and figured out that MyISAM has another "feature" that InnoDB doesn't: full table locking. It locks an entire table when running queries on it. When I've got a table that holds 400k records for a total of 90k users, and many of them are trying to access or update at the same time, MyISAM's table locking is a deal-breaker. InnoDB implements row-level locking instead. MyISAM is great for smaller hobbyist things, but it's terrible for concurrent access on large data sets. I would open the process list in phpMyAdmin and see 30 or 40 queries in the queue waiting for one to finish. So if your data set is small enough that MyISAM can handle it, then it's also going to be small enough for InnoDB to operate on it quickly, at least as quickly as MyISAM. I don't see any reason to use MyISAM when InnoDB is an option.
I'm not trying to get into the politics of which engine is better to use, but InnoDB walks all over MyISAM in the real-world performance area, unless you're building yourself a shopping list or something similar.

You know, I never understood the point of InnoDB. One may want a complete, fully functional DBMS, in that case, there is PostgreSQL, or one may want a lightning fast data indexing/accessing machine, and for that case there is MySQL.

The point of MySQL isn't a "lightning fast data indexing/accessing machine". The point of MySQL is the modular backends which enable it to serve as a common gateway to tables that each use the storage engine most appropriate to the way the table is used. (some of which may require a lightning fast data indexing/acessing engine and accept some risks to get it, some tables may not.)

The point of InnoDB (and, presumably, Falcon) is to support the kind of usage scenarios for which traditional RDBMS are designed, while the point of certain other MySQL table drivers is to support other types of loads.

The case related to a company who used ODBC and whether or not they binded to MySQL. It was not the NuSphere case, but one that used ODBC and MySQL.

The question was if your application used ODBC and MySQL was it binding in the GPL sense?

The answer was in the fact whether or not the application could function with another database. At the time the result was that MySQL lost the case since the application could function with another database.

It was around that time MySQL GPL'd all drivers, and changed their syntax so that it would only work on their servers. That way it is a GPL binding as per the court case.

PostgreSQL is the open source database that can comepete with Oracle in terms of features and reliability. EnterpriseDB aims to be a drop-in replacement for Oracle with a PostgreSQL backend. The partnership is going to create a path for EnterpriseDB to be a drop-in replacement for Oracle with a DB2 backend.

It creates a migration path from Oracle that IBM can take advantage of.

Problem easy to solve. Don't distribute the MySQL JDBC drivers in the case of a Java app, for example.

If the application is going to be distributed as part of an appliance like Google-in-a-box [google.com], then it just wouldn't work.

Better yet, use the application online and provide it as a service.

Not practical for an otherwise Internet-disconnected network. And in many areas, this isn't even possible without an extra $720 per year or more to the cell phone company for a tetherable data plan, as dial-up just isn't good enough anymore.

Oh, sorry to reply yet again. Yes, I can name a number of project forks in which the original fell by the wayside as a fork took off. Not all the originals are dead, mind you, but the forks are much more popular. A few of these are situations in which the original is still viable (Debian, for example), but in which the fork has a huge number advantage or a lot of momentum.

The company that writes some application that talks to a GPLed MySQL will have to follow the GPL in distributing MySQL. They will not have to license their own code as GPL.

From GP's comment, it sounded to me like MySQL AB has argued that any application that absolutely needs MySQL to function is a derivative work of MySQL, and thus, cannot be distributed without license from MySQL AB; and that therefore, to distribute such an application, one must either license it under the GPL, or obtain a commercial license from them. The argument seems to hold that whether the application links to a GPL-licensed MySQL client library or not is irrelevant; what would matter is whether the application can be functionally severed from MySQL.

If you want a really fast free database that supports fulltext indexing, and you don't need transactions, MyISAM in the engine to use.

That is a load of bullshit. There are a number of cases where MyISAM will be actually slower. It depends not on the engine, but on the usage patterns of the database and database structure. And, interestingly, it varies from application to application.