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 :)
Or, in this case no quids were involved (a quid is UK slang for a British pound...)
:-))
It restores my faith in people when something like this happens - MySQL and PHP are the joint foundations on which a huge number of OS projects depend. Way to go MySQL
Simon
Physicists get Hadrons!
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 moral of the story is clear: don't contribute to dual licensed projects, or any project where there is a clear single copyright owner. They have the ability to re-license at will, profiting from your work as you please and not having to offer in return what the original distribution license intended (e.g. GPL).
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
Postgresql is too complicated to administer. Unless you want to hire a full time DBA then just stick with MySQL for your small projects. Much easier to setup and learn.
- 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.
If your intent is to foster contributions to your project, then aren't you in danger of losing that by allowing more liberal (and potentially, more closed) licenses to be used with your project?
Umm... no. For example, if the client libs were LGPL, any improvements to them would need to be public, but any program using those libs wouldn't need to be. Obviously, even with the new clause, improvements to client libs would need to be public.
Licensing a library as GPL is motivated purely by the prospect of profiting from dual-licensing the library to companies that can't release their code under GPL.
Save your wrists today - switch to Dvorak
Because Postgresql cannot compete with MySQL in terms of features that count for the target scenarios.
Postgresql is underdocumented, the MySQL online documentation simply excels.
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.
Postgresql does not support shared scenarios as good as MySQL. That's sharing the same machine with a web server, and that's sharing multiple logical databases as in a hosting environment (including putting the actual data files into each customers chrooted environment). MySQL does this very well.
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.
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.
Still, this is a large window of opportunity for Postgresql, if Postgresql plays this correctly. So where are the MySQL migration guides, the "Hosting with Postgresql" Setup-Howtos, and where is the "Using replication in Postgresql" tutorial?
As much as there are some FSF fans wish that the GPL was the only software license, it's not the one-size-fits-all solution for everybody. That's why the LGPL exists. That's why Creative Commons exists. That's why many common open-source programs have forked the GPL to make it their own.
We can debate the finer points of whether such changes should be made or not, but let's not treat the GPL like it's a religion. It's not perfect.
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.
MySQL changed the license of the client libraries to GPL from LGPL.
Then how come nobody forked the libraries? You could take the new server (where it doesn't matter if the license is GPL or LGPL as you are not going to link it against anything) and the old libraries that were released under LGPL. Then modify those libraries as much as necesarry to work better with the new version of the server. And release the modified libraries under LGPL.
Do you care about the security of your wireless mouse?
Writing good HTML -especially XHTML & CSS- is entirely different from writing code. HTML is a markup language, not a programming language, and excelling in it requires an entirely different skillset -it's more akin to designing a database than coding.
Being able to write a hashing algorithm doesn't make you suitable for all coding jobs.. in my experience, there are high-level coders and low-level coders and both are necessary.
This is not to say there aren't a lot of completely useless people out there -probably more doing ASP, VB and such than anything else, but a lot of PHP users, too. However, many if not most of the incompetent PHP coders are not making a career of it, unlike the ASP/MCSE people, but rather making their hobby/personal sites.
Marxist evolution is just N generations away!
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.
So, MySQL is distributed under the GPL, and PHP is distributed under a license incompatible with the GPL.
How is this MySQL's problem?
Slashdot is jumping the shark. I'm just driving the boat.
Bullshit! If your scenario is 'having an RDBMS' then it's MySQL who cannot live up to the task, Transactions, subqueries and data constraints are more then just 'nifty features' you know.
I know. Even MySQL knows, or otherwise they wouldn't build them into their current versions.
Still their importance is overestimated - the bottom 80% of all applications are just fine with MySQLs MYISAM "autocommit style nontransactions" and deal without subqueries just fine. MySQL just totally owns that market because a) it serves up these 80% of customers blindingly fast, b) it implements stuff that does not have to do with databases in the first place, but with management issues such as being drop dead easy to administer and fit into a hosted environment just nicely.
Sorry if this came out as a bit of a troll, I've just seen to many Perl|PHP|WhatHaveYou 'hackers' poor their awful code on an unsuspecting world *shudder* and MySQL, even though not at fault, has been a major catalyst in this. Certainly not your fault though, so sorry
I know databases, and I know the past and current limitations of MySQL. They do not concern me in the vast majority of cases where I do need a database. By using MySQL for such projects, I can be sure that just about everybody will be able to maintain the end result, which again, is not a database, but a management issue.
And this is probably the main gripe I have with the Postgresql people. The almost certainly are the better database people, but they are completely lacking vision regarding analysis of target market requirements (MySQL excels here!) and their marketing/community communication department is next to nonexisting.
So they do have the better database, but nobody cares. That's a shame, and it should be changed. Remebering last years Linuxtag, I just don't know how. These people are hopeless geeks.
Would you care to give some examples as to how PostgreSQL is harder to administer than MySQL? Having used both, I would say they are both fairly easy to administer.
If you want something that can be really nasty to administer, use Oracle or DB2
As far as I am concerned, it's all about selecting the right tool for the job. My last project needed subqueries and enforced relational integrity and at the time MySQL couldn't handle this, PostgreSQL could!
Unfortunately for MySQL that means that I'm unlikely to consider it for another project, unless it can offer something that I need that PostgreSQL can't (Hasn't happened yet)
For people who like peace and quiet. A phoneless cord!
Comparing anything to perfection is unproductive; it serves to reinforce our biases by presenting us with a false dichotomy (you can have whatever argument is being proposed or you can have perfection, which is never available). Let's look at specific claims.
Please name who these people are and cite the evidence that gives you this impression.
That explanation barely gets into why the LGPL exists. The Creative Commons doesn't recommend their licenses for software. The GNU project started over a decade before the open source movement began and the GNU project was founded to talk about software freedom, not a development methodology. I'd also be interested to learn who, besides the Affero General Public License has "forked" the GNU GPL. The Creative Commons has listed the GNU GPL, not forked it.
Who, exactly, is doing this and what, exactly, are they saying?
Digital Citizen
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.
Why do so many MySQL zealots keep claiming that 4.1 and 5.0 are ready for production? Even MySQL AB doesn't make such a claim. Their web site clearly states:
Production 4.0.18
Development 4.1.1
Preview 5.0.0
So saying that "new installations should use 4.1.x" is like saying that everyone should have run Linux 2.5.x, or the latest CVS version of Apache.
This seems a little confused:
I can't imagine what you're talking about, really. When web apps were adopting MySQL Postgresql had a number of genuine technical problems that turned people off, but these don't sound like them. For example, there was an 18K limit on row size.(And also during that period, MySQL had the market cornered on bullshit. Like "Transactions??? Aww, you don't need that shit." And MySQL boosters than -- and now -- seem to regard mysql.org as the fountain of truth... for example, "MySQL is *fast*" appears to be an article of faith, but the people who say that rarely do their own benchmarks, never worry about what happens under heavy load, etc.)
And they all laughed at Christopher Columbus, but many people who seem crazy genuinely are crazy, and some things that experts sneer at as toys may in fact really be toys. Yup. Usually venture capital is the death of anything worthwhile (it's amazing google has held on for so long).Anyway, I should explain that I don't keep up with the state of MySQL's code. For all I know the MySQL defenders are right when they say they're got all the features you could want now... I gave up on following MySQL a long time ago, but I did it as much for social reasons as for technical ones.
MySQL has always been a little too cute in the way they pose like one of the guys to keep their mindshare in the free/open world. Remember the old not-exactly-free license that penalized people for running on Microsoft? It's sounds like they're trying to play the same kind of games with their sort-of-GPL'ed libraries.
I am a strong advocate of PostgreSQL. However, to say that Postgres' docs are perfect is false. This has been discussed on the advocacy mailing lists before. PostgreSQL has great docs for people who need a reference and pretty much know where to look, and what they're looking for.
In my opinion, PostgreSQL docs could be improved by:
(1) Better search functionality
(2) More tutorial-oriented material throughout the docs, like more examples at the end of sections, and more descriptions about why you'd find that particlar feature useful.
(3) The website needs to be more portal-like, introducing you to all the postgresql resources available, and helping you get going.
MySQL has paid maintainers to take care of all of that. PostgreSQL doesn't. PostgreSQL only really has coders, and if I'm not mistaken, only one major advocacy coordinator, Josh Berkus, who I met at Linuxworld in SF, who does a great job, but is only one person.
It just takes some more people that know the database well and have some basic web experience to put together some great things.
PostgreSQL is, in my opinion, the best database for most RDBMS tasks. However, I know how I feel when I go to a software site and i just want to check something out. I don't know whether it's the best or not, so I want to try it. It can be imtimidating when nothing has context. Lots of context is what makes docs easy to understand for a beginner.
That takes people that PostgreSQL doesn't currently have yet. Public relations and marketing are expensive, but MySQL can pay those guys.
Of course PostgreSQL is doing just fine by attracting users away from Oracle and SQL Server, and the people that have serious enough database requirements to actually look. The code quality, and the quality of the coders and the steering, and the project management is amazing. And it attracts more coders because they retain copyright on their work, unlike MySQL coders.
Social scientists are inspired by theories; scientists are humbled by facts.
I think part of the trouble there is that if you're half-way serious you want to set up your own boxes anyway... the small fry that want to run web apps on someone else's box are either (a) unlikely to need a real RDBMS like postgresql or (b) unlikely to know why they need it, take your pick.