The recent Open for Business article "The MySQL License Question brings up the issue of MySQL strongarming users into purchasing commercial contracts from MySQL if they are not an 100% open source project:
The information on MySQL's commercial license page also seems to be a bit far reaching when it suggests that one's program must be licensed under the GPL or another Free Software license if MySQL is distributed with the product. A good analogy here is that it is legal for a proprietary web browser to communicate with a GPL licensed web server, and vise versa -- the programs are communicating to each other, but not actually combining code together. In the same way, it is theoretically possible to communicate with the MySQL server either using a third party Free Software tool that allows linking to proprietary packages, such as one licensed under the LGPL or BSD licenses or by developing a proprietary program that can communicate with MySQL through networking protocols.
I understand MySQL's motivation -- making a good database available to the open source community is not free and the MySQL employees want to get their paychecks. And there is nothing wrong with that. But, there is a fine line between who is a commercial customer and who is not. Interpreting this fine line will be as difficult as Google sticking to their mantra of "Don't be evil!". I wish (both of) them good luck in interpreting this line...
However, should MySQL start pushing too hard to get commercial licenses, there will be a backlash from the open source community. And if that happens, guess who the overall winner will be?
I'm not intending to start a religious war between MySQL and PostgreSQL, so please skip those comments. But if you have any thoughts about how MySQL can balance running a commercial enterprise and still be a good open source player, please speak up!
Categories
Web
Comments (10)
Read More Entries by Robert Kaye.
"good enough" often wins
Wait.... I take it back. :-)
MySQL Licensing - open source in the real world
Licensing is a tricky thing. Finding the best path for a dual licensed software product inevitably involves making mistakes and subsequent adjustements. I think that is fine.
MySQL AB consists of real people with goodwill - responsive to feedback. It's a process. Naturally, not all things can be fixed instantly, and particularly legal issues sometimes take more time than one would like, but those are just facts of life.
Open Source and business go together well.
If you have a specific concern regarding MySQL licensing, do feel free to contact either myself or someone else at MySQL.
Arjen Lentz
MySQL AB
But where is the simplicity?
I keep hearing people tout the "simplicity" of MySQL. I've used both MySQL and Pg. I don't get it. Why is the "absence of features" considered a win here? If anything, PostgreSQL is simpler because you can use any off-the-shelf SQL92 reference or tutorial to learn what you need.
As for SQLite, I see SQLite at the low end below MySQL and Pg. And from what I've seen recently, you end up with SQLite and Pg overlapping, leaving no room for MySQL's benefits.
Getting back to the topic of the thread... even if MySQL had an advantage, they are slowly strangling it because of the successively harder push to commercialization. At some point, there will either be a fork or an abandonment.
Windows Install...
I think that the ability to easily install on windows is very important for getting that initial look. I had played with MySQL even though I had heard that Postgres was better, simply because it was the path of least resistance to getting a database running on my box at work. Now that Postgres offers the same functionality, guess what's sitting on my box for me to play around with, and guess what I'll use next time I need a db...
PostgreSQL brought a gun to a knife fight
PostgreSQL is a good OLTP database--MySQL is not.
On the other hand, not all database applications require the features that make PostgreSQL an Oracle competitor. We use Oracle to feed larger databases that Oracle can't handle.
In particular, I wouldn't use Oracle for a data warehouse. It's just not got the horsepower for a large installation, and it's overkill for a small one.
It's okay technically to build a data mart on one (though many of its features aren't needed there), but why spend the money on Oracle if you don't need it?
For a mart, you want screamingly fast selects and fetches on preplanned queries and reports and on ad hoc queries over a small subset of massaged data, and not much else. For a warehouse, you also want efficient loading and unloading, good performance for ad hoc queries and some reporting. These are places where MySQL has enough to offer, and where PostgreSQL maybe has a little too much.
Some of what Oracle's features cost you is money--not true of PostgreSQL--but they also cost you in resources. In context, PostgreSQL's ability to act like Oracle can be a negative feature.
horses for courses
I still see many applications where I would choose the (possibly enforced) simplicity of mysql over postgres.
There are many places you don't need or want oracle or its equivilent. If I want a fast, simple, lightweight and well supported and documented RDBMS and don't require subselects or stored procedures then MySQL is the best choice.
I would also start looking at SQLite between the application domains of postgres and mysql as it others some of the power of the former and the lightweight and simplicity of the later, of course it doesn't quite have the support and maturity of the others, but I don't like to decide a solution until I have seen the problem.
The winner of the MySQL license debacle
My god, you're right!
Hang on a minute, I'll just put all my company's entire accounting and personnel databases up on the internet so that I can search them using Google. Gosh, I hope non of out competitors find out about it!
Oh, can you remind me how to use Google to produce a report of all employees earning over £35,000 a year and display their expense claims details for the last 6 months? I seem to have forgotten how to access that function in Advanced Search.
Simon Hibbs
The winner of the MySQL license debacle
Here again we have the old dichotomy of who's the winner when both are actually losers.
Systems Query Language was aboriginally a non-proprietary and public license program. That came about because the Army contracted to have it written, no matter what it's previous names were.
IBM, always quick to try to hijack any and all software and hardware, claimed authorship under the SQL acronym.
But IBM had already hijacked Grace Hopper from J. Presper Eckert and John Mauchley, and gotten her to write her version of Algol, called Cobol. Thus snaking around Copyright Law by hijacking your competitor's employees. Grace gladly accepted as the Colonel whose liaison funded the first computer in 1946 offered her to become the first female general. Not a bad deal for corporate espionage.
Both SQL's are going to die anyway. Their file and database structure are outmoded. What will beat them is an http database that stores items discretely and recoverable from any browser or text editor. Storing each item as a webpage has far too many advantages, like searching without even having to run the database program. Emails can be saved as html pages and searched even with the standard command line or Explorer search facilities.
And this is how emails should be filed, so that you can find them when you want, and not just when some SQL or other database program is executing.
Try to find any archived email with any email program and you will run into archive problems. Try to find them with SQL and you won't. They are just not universal enought to perform the task.
But HTML is. Doing a text search on a hard drive, you can find any phrase that you remember, email sender, email recipient, or whatever criterion you choose.
Databases cannot do this. Their code is too specific. They will not search outside of the bun, i.e., the database.
And someone said that there are no new killer apps emerging.
An html database which stores every page in a tree structure is also more efficient than any database, with keys, relative databases, fixed databases, and all the other holdbacks of databases.
Which is why databases, as they currently exist, are obsolete.
The whole idea is to find what you're looking for, not to get lost in the syntax of some allegedly proprietary database program.
If a search engine can find an item anywhere in the world, on any operating system, then HTML is the database of the future. But it must have the tree structure of one file per record, regardless of content, without regard to tables, record numbers, keys, and all of the other obsolete garbage that makes all current databases obsolete.
"good enough" often wins
VHS vs Beta.
MP3 vs FLAC/OGG.
Windows vs Linux/BSD/OSX.
PHP vs Ruby/Python
MySQL vs PostgreSQL
Though the folks in-the-know know better, "good enough" often wins for most folks.
Even me: I've heard a bunch of reasons why PostgreSQL is better, but eh: MySQL is good enough for me. It's entrenched into thousands of lines of code. I'm stuck with it, and OK with that.
I think PostgreSQL already won
At this point, a lot of my professional associates are recommending PostgreSQL over MySQL in all applications where there isn't a legacy reason (mindset or bolt-ons). You've got full Oracle-like features, decent speed (it's starting to be neck and neck depending on the benchmarks), better robustness, and a simple license (BSD style).
There's less motivation to migrate if you already have a working installation, but I see some of my clients are even doing that.
A few years ago, MySQL was the main player. Those days are gone. PostgreSQL is indeed Oracle without the price.