Slashdot Mirror
MySQL Writes Exception for PHP in License
ryanjensen writes "According to an article on News.com, MySQL wrote an exception into its license to allow PHP to use its libraries. From the article: 'Because MySQL owns copyright to all the MySQL code, it can include additional license provisions to its software. The new provision, called the Free and Open Source Software License Exception, enables people to use MySQL client libraries with other open-source projects under other open-source licenses other than the GPL.'"
This is good news for all those PHP kids out there. It is nice to see some licenses being made specifically more lenient, and I don't doubt this has had something to do with the recent change in the XFree86 license and how people reacted to that. Well done MySQL, your domination is secured :)
...but I'm sure some GPL zealots might.
To me, it looks like an issue of pragmatism and the MySQL folks apparently aren't hung up on religious adherence to GPL principles.
It's an issue of maximum applicability, to me.
PHP and MySQL are very close. One can't really thrive without the other, so if one adopts a more restrictive license, both lose out. And considering the massive penetration of PHP and MySQL, neither can risk this kind of thing.
This license exception is BS. It requires that "The Derivative Work does not include or aggregate any part of the MySQL Server" where "the term 'include or aggregate' means to embed, integrate, bundle, aggregate, link, distribute on the same media or in the same packaging, provide with instructions to download or automate any of the preceding processes." This effectively means that any non-GPL program that links to MySQL client libraries cannot be distributed in an operating system distribution with the MySQL server. It also means that the documentation for such packages can't even mention "www.MySQL.com" because that would count as "provid[ing] with instructions to download".
I really enjoy using PHP for web development. I find that you can't beat scripting languages for ease of maintenance, quick turnaround time, and tweakability.
One of the big reasons I chose PHP was the availability of "LAMP": Linux, Apache, MySQL, PHP. I know these technologies have been around for years and will be around for many more years, so it's an easy sell to management. There's plenty of talk on the newgroups if you ever get stuck and PHP's online documentation with user comments is priceless. I think more documentation should follow this example.
That aside, the pure performance and reliability of the above is excellent. These technologies were made to work together, and from what I hear the teams even collaborate to make sure their stuff stays working together. It really shows.
Years ago I worked on ASP/SQL Server solutions and where you had to go with native code for high-performance with ASP, I find that with PHP it is high performance on its own.
Great job to everyone who has helped put together these technology solutions. A shining example of the high quality that can come out of the collaborative efforts of many.
Im sure i saw this within the Mysql license over 2 months ago. Its good to see mysql making exceptions for other opensource projects, and acknowledging that there are other non gpl licenses. I wonder if the PHP crew will reevaluate the decision to remove mysql client from php5?
FOSS license Exception. Scroll down for the table.
Probably for the same reason that they don't switch to PostSQL -- massive investment of time in learning MySQL (we're talking years, here) which makes them hesitent to switch to an incompatible technology, and unable to do the heavy programming required to create a new branch from old MySQL code.
Will Debian now remove MySQL or move it to non-free?
~Darl
I have no problem with the making such a license change per se--they have the right to do it and it doesn't limit the existing license in any wqy.
But, the approach itself strikes me as unnecessarily complex and short-sighted. There is a growing list of compatible licenses in there--who is going to keep that up to date? What's going to happen when MySQL disappears and nobody can make such little changes to the license anymore?
A fairly straightforward compromise would be to put them under the LGPL license. I think that would also make sense because it would get vendors of commercial tools to incorporate the client libraries into their software. But it seems like MySQL's business strategy is getting into the way there because they appear to want to make money from licensing even the MySQL client libraries that way.
This situation seems vaguely analogous to Qt's GPL license: in both cases, a commercial owner of an OSS project is choosing the GPL license as an encumbrance in order to be able to get money from some class of commercial users. In the case of MySQL, they are trying to limit the "collateral damage" to non-GPL compatible OSS projects by making exceptions. But in both cases, I suspect that having these libraries under the GPL is itself a suboptimal strategy because it limits the adoption of OSS. For things like GUI toolkits and database client libraries, it seems best for OSS if companies incorporate them into their commercial software as much as possible, and that means choosing a license more liberal than the GPL. But, again, commercial interests prevent that in these cases.
Well, I personally had just assume that the MySQL client libraries were LGPL or BSD. Thanks for bringing this up. Not the license change itself, but the fact that it has brought the MySQL license situation to my attention, is a reason for me to think about using SQLite and PostgreSQL more seriously.
MYSQL just received $19.5 million in venture capital funding.
While this could and should be great, it remains to be seen what impact the influx will have.
The same reason millions of people continue to use windows and OS X.
Everyone knows how to use it, it's well-documented, It works, and (in the case of OSX), it's pretty damn good at what it does.
-- If you try to fail and succeed, which have you done? - Uli's moose
The RH enterprise 3, releases has all MySQL v3.
The MySQL changelog says:
* Thu Jul 03 2003 Patrick Macdonald 3.23.57-1
- revert to prior version of MySQL due to license incompatibilities
with packages that link against the client. The MySQL folks are
looking into the issue.
I think the phrase you're looking for is "GNU Dogma." Correct?
Because MySQL is GPLed?
Since the license of several open source scripting languages are not GPL-compatible, MySQL grants these projects additional rights above those already provided through the GPL.
So these 'atrocious license changes' are like the TV-sales people who when you order you new set of stake knives insist on also giving you a juicer and a can opener for free.
Try out fish, the friendly interactive shell.
Lots of reasons.
Scales better with large numbers of simultaneous connections, larger tables, etc.
Mature transactions. MySQL just gained these, but they aren't in heavy use. For applications where consistency matters, you need either transactions or locks. In MySQL you spend a lot more time coming up with locks and resolving deadlocks.
Stored procedures. Sometimes it's useful to put code right in the database that can abort an invalid transaction or perform some other automated action. With MySQL you have to put this code in your PHP application, everywhere you access the database, rather than just once in the database. Much more code, much more debugging, and often much less efficient. The primary procedural language (PostgreSQL supports several) is Pl/PgSQL, essentially the same as Oracle's Pl/SQL. If you learn Postgres, you're well on your way to learning Oracle.
Multi version concurrency, like the big commercial databases.
A query optimizer that gets much better performance as your queries get complex. MySQL often can't do the same complex queries at all, and when it can does them naively at unusable speeds.
Rule system, implementing views and other big-iron features, allowing applications to be simpler.
Correct behavior under crash scenarios or disk full. I've never had PostgreSQL corrupt a database. MySQL will occaisionally, so your backups will get more exercise, and you'll have lost some data.
subselects. You can often contort your MySQL queries to work around the lack of full subselects, but again, you do more work, and there isn't always a workaround.
Foreign keys (implemented using triggers). These allow you to ensure that your data follows certain relationship rules (every sale points to a valid buyer for instance) at the database level. In MySQL you just have to make sure in PHP (outside the database) that you always generate good data.
Mistakes happen, Postgres lets you program more defensively.
Temporary tables. Very useful when building a complex operation inside a transaction.
Security and authentication. Postgres has a very wide array of authentication methods, ranging from allow these IPs to do anything to local sockets, with SSL available to use to encrypt and authenticate as well.
postgres is not as good at altering tables in production, especially if you've used the advanced features like triggers and rules (you may end up copying the data, deleting the tables, and reloading them, all inside a transaction of course).
MySQL client libraries have been included/bundled with PHP for a long time now, and MySQL support was enabled by default. As of PHP 5, these client libraries are no longer bundled, and MySQL is not enabled by default. This essentially makes MySQL support like any other PHP extension, nothing special. To install, simply download MySQL and configure PHP with --with-mysql. Not a big deal. You do the same for PgSQL, CURL, TIDY, GD, etc.
q .databases.mysql.php5
An official FAQ on this issue can be seen here:
http://us2.php.net/manual/en/faq.databases.php#fa
You'll notice that the license issue isn't the only reason PHP 5 stopped bundling these MySQL libraries so I assume despite this license change PHP 5 will not bundle MySQL by default. One might say the marriage continues to exist...but that it's no longer "forced" onto people.
For me the situation with MySQL's licensing shenanigans is quite sad. For small commercial software development shops who have been loyal to MySQL over the past few years, it's sad to have to say goodbye.
It's fine that I have to pay money for a database server and all, but the GPL-licensed client library makes light usage of MySQL impossible for small software vendors. Even Microsoft SQL server has LGPL client libraries available (like freetds)! I can't see how MySQL can compete with other commerical software vendors that have less restrictive client-library licensing.
For the MySQL folks to claim that the GPL is binding through a regular socket connection is quite a strech at best, and a slap in the face to those of us who write [L]GPL-licensed software.
Postgresql is underdocumented, the MySQL online documentation simply excels.
Complete and utter bullshit. How is this for documentation? There are also excellent books about it.
There is no readily available workforce that has actual Postgresql knowledge. There are on the other hand buttloads of people available that can drive average sized MySQL installations for cheap money.
That's a circular argument: everybody uses MySQL because everyone else does. (I can name a certain OS that benefits from this situation...) A good DBA would have no problem picking up PostgreSQL in a matter of days. I don't care about trained monkeys.
There is no readily available workforce that has actual Postgresql knowledge. There are on the other hand buttloads of people available that can drive average sized MySQL installations for cheap money.
Again bullshit. PostgreSQL supports multiple databases per server very well, including separate access controls for each db.
Postgresql replication is regarded mostly experimental and is not properly integrated with the server. In larger MySQL deployments, replication is often used for load sharing (direct read only queries against any replica), and for backups.
Replication (in both MySQL and PostgreSQL) is mostly useless since it is asynchronous. That is, when you commit a transaction you can not be sure if/when it gets propagated to the slaves. Therefore, if you read from a slave you can never be sure that it's up to date. I'll grant you that there are certain situations where this can be tolerated, but for high availability mission critical sites, it's useless. For that you need distributed transactions. The only open source DB that supports them is firebird.
BTW, I'm glad you mentioned backups. PostgreSQL , just like any real database, can do on-line backups. However, to back up MySQL, you need to read-lock all the tables! The only way to get around that is by setting up replication and backing up the slave.
Postgresql already has many features MySQL either just got with 4.1 or is planned to get in 5.x. That is useless, though, if you do not need these features, but need to deploy in a hosted standard environment, relying on the available workforce.
Yeah, I'm sure you don't need transactions, subselects, triggers, stored procedures, or even *gasp* correct and predictable behaviour.
But you are right about one thing: everybody uses MySQL because everybody else does.
___
If you think big enough, you'll never have to do it.
Perhaps PostgreSQL is not as unreliable as MySQL, so it doesn't need replication nearly as badly. I have yet to see a slashdotted site running postgres fall over and die (although it does get slow).
Replication is not limited to reliability issues, in fact, even in MySQL it is not used for that most of the time. It is instead being used for scalability, and for convenience.
When MySQL sites fail, they usually fail due to the MySQL connection pool being exhausted - MySQL has a configureable limit for this, and your webserver has a configureable limit for the number of concurrent connections (each using a number of database connections) it serves. If these numbers do not match, any database server will return errors.
And just for the record, where I work, I have seen Oracle servers fall over and die. Not due to connection limits, but due to plain and simple errors inside the code. Then again, where I work we tend to exercise our machines quite a bit.
MySQL is a toy
Actually, I'd tend to call MySQL a tool. One that's has been vastly different from Postgresql and Oracle in the past (3.x versions), and one that served the target market much better than either Postgresql or Oracle could - there is simply no way to build shared hosting for webshop/weblog/guestbook/cms/ad-hoc type applications based on Oracle for a competitive price.
And even if you managed to get the licenses for free, the hardware and administration costs would have forced you out of the market. Using Oracle here would be like using the sledge hammer for motherboard maintenance.
Similar situation with Postgresql: At the time the LAMP hosting market was created, the Postgresql team did not offer their product in a packaging that was usable for the job - no neat distribution, no documentation that a hoster could have handed to the end user, no proper support for shared hosting environments.
MySQL addressed all these needs, had a matching deployment model and the price was right. Using this as a vehicle, MySQL grew with the market and created a vast number of people using MySQL as a household name.
That was possible, because this was a new market far below what the established database vendors saw as their target markets, and with much smaller requirements. There was no need at all for "enterprise level" in webhosting environments.
But consider what MySQL did to the unwashed masses: Before the advent of the LAMP combination, SQL knowledge was expert knowledge, and hard to find. MySQL, not Postgres nor Oracle - both older than MySQL! - , changed this and today every script kiddie has basic MySQL syntax knowledge and would rather chose a MySQL database than a flat file to store a high score list.
MySQL 4.0 and 4.1 are the first steps MySQL, the company, takes migrate their market upwards into "enterprise" regions. 5.0 will take them there, read the feature plan and try out the Alpha. They are arriving in their new market segment right now, and they are not alone. They are bringing masses of people that grew up on MySQL and that grew with MySQL.
That does two things: It commoditizes databases, gnawing at the market from below. MySQL does to the SQL market what Linux did to the Unix market, only that MySQL is now where Linux was in 1994 in terms of market development. It also popularizes knowledge, in this case knowledge about relational algebra and data modelling, about SQL, replication, storage management and related issues, just as the advent of Linux popularized knowledge about Unix, about TCP/IP networking and a lot of related topics.
Any yeah: Linux was not "enterprise level" in 1994 as well and got badmouthed by the established Unix vendors. Didn't help them much: It is Linux that's still around, while the rest is either vanishing, sueing themselves to death or is frantically becoming Linux compatible.
MySQL could become the Linux of the database market. If - and that's a big if - if the MySQL management avoids getting into the way of such a development.
Chances are that they fuck it up. There is to much venture capital involved - these people want to see 3-5 year returns on their money, but we are talking a 10-15 year development here.