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 :)
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.
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.
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.
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
- 5. No Discrimination Against Persons or Groups
Debian Free Software Guidelines (DFSG) FAQ:The license must not discriminate against any person or group of persons.
6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
- Q: What about licenses that grant different rights to different groups? Isn't that discrimination, banned by DFSG#5/6?
Makes a whole lot of sense to me.A: For Debian's purposes, if all the different groups can exercise their DFSG rights, it's OK if there are other people who can do more. For example, if a work were distributed to everyone under the GPL, but elementary school teachers were given the extra right to distribute binaries without distributing the corresponding source code, it would still be DFSG-Free.
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.
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.
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.