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.
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".
FOSS license Exception. Scroll down for the table.
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.
- 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.
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).
RTF license exception page. It doesn't only apply to PHP:
Academic Free License 2.0
Apache Software License 1.0/1.1/2.0
Apple Public Source License 2.0
Artistic license From Perl 5.0.8
BSD license "July 22 1999"
Common Public License 1.0
GNU General Public License (GPL) 2.0
GNU Library or "Lesser" General Public License (LGPL) 2.1
Jabber Open Source License 1.0
MIT license -
Mozilla Public License (MPL) 1.0/1.1
PHP License 3.0
Python license (CNRI Python License) -
Python Software Foundation License 2.1.1
Sleepycat License "1999"
W3C License "2001"
Zlib/libpng License -
Zope Public License 2.0
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.