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.'"
FOSS license Exception. Scroll down for the table.
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.
One can't really thrive without the other
In the webspace this may be true. However, MySql is far more than a backend to a web database (OK I'll admit PHP is more than access to a database as well) both projects are used independently of each other in numerous ways.
Will Debian now remove MySQL or move it to non-free?
Well, whether or not MySQL happens to allow this exception themselves, I don't see any reason why Debian couldn't simply redistribute MySQL and remove the exception.
Presumably MySQL is offering a specific non-GPL licence to select 'friends', of which PHP is one. This does not change the fact that MySQL is also distributing its product under the GPL. Thus, Debian can simply choose to only use the GPL for redistribution.
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.
The copyright holder of a product that is released under the GPL is not required to use the GPL as the only license. It's hard to attach a license more restrictive than the GPL to already GPLed software, but it's very easy to attach a less restrictive license.
:)
The copyright holder can also craft exceptions to the GPL simply by making an add-on license that promises a certain violation of their GPL rights will be tolerated, and that includes a situation under which distribution without the GPL is allowed.
As for use on your own website, if you aren't planning on selling it or seling it unmodified, you can do whatever you want to it, regardless.
But if you plan on selling it packaged, even before this add-on license, as long as you distribute the code with it, thus adhering with the GPL, you're in good shape.
Selling it with a PHP solution is fairly straightforward...you are more or less just selling the PHP code, and telling them that it needs to run on a MySQL database. That's kinda like writing a program that runs on Linux, and telling them that they need to install linux (or you'll gladly install it for them) to run this program. You aren't really "Selling" the database.
But even if you are, as long as the GPL is upheald, you're right as rain.
How could I say to men: "Speak louder, shout! For I am deaf!"? -Ludwig van Beethoven
Well, I personally had just assume that the MySQL client libraries were LGPL or BSD.
The MySQL Client Libraries 3.x are LGPL. The MySQL Client Libraries 4.x are GPL. In order to talk to a 4.x server, you need 4.x client libraries. 4.x client libraries are downward compatible and can talk to 3.x servers.
Not really...
PHP, though most commonly used in conjunction with MySQL, cerainly has many other uses, and can connect to a number of other databases, even that *other* open source db, postgre.
Sorry, but while it might hurt php to lose mysql, it wouldn't kill it.
"We don't know what we are doing, but we are doing it very carefully,..." Wherry, R.J. Personnel Psychology (1995)
Yes, read the fucking gpl.
The libraries for MySQL are GPL *NOT* LGPL. Anything linking those in must therefore be GPL compatible. I don't see the point of including MySQL if you can't say, oh, link the libraries to let your code put data in tables.
It has the same issues as QT.
Already explained this in this post.
The LGPL states that:
"When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom."
Which is pretty much what I said...
Try out fish, the friendly interactive shell.
In my opinion, the PostgreSQL documentation is much superior. If you mean there are a lot of books available for MySQL, well, that's true, but having to buy a 3rd party book is not my idea of a well-documented product. And PostgreSQL's command line client has much better help than MySQL's (which basically has none, forcing you to have a Web browser open if you forget the syntax to some query you want to run).
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.
The thing about MySQL's GPL licensing nonsense is that it cannot be used from within libgda the GNOME data access system -- and so the backend for MySQL ends up being removed. This probably applies to other systems as well.
Well for those of you that don't like MySQL's restrictive licenses and want a quick little SQL db, PHP 5 is shipping with SQLite.
An interesting little database to say the least.
How could I say to men: "Speak louder, shout! For I am deaf!"? -Ludwig van Beethoven
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
That is not what you said at all. You said distribute together, not link. These acts are worlds apart.
I'm surprised that a 5-digit UID should exhibit 2-digit IQ.
Yours Sincerely, Michael.
It is entirely within the GPL license for me to distribute a GPL program along with my propertiary application and don't open source my application, as long as I don't link with it. So how do I communicate with said GPL program? I can use TCP/IP, sockets, or even plain old text files.
But SQL is SQL and apart form the usual database specific extensions, it is standard. So applications built on top of SQL compliant database engines should port with ease.
Every RDBMS out there has their own extentions to the SQL language, and none of them implement the entire SQL-99 spec. So every system is both a subset and a superset of the standard. Robust dtatabase applications end up tailoring their SQL to the paticular database system they are using, and porting away can be a non-trivial task.
What do you know I wrote a novel
I can also quote. From the GPL, this time:
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
This quite clearly states that core operating system functionality provided by the vendor is exempt from the GPL's linking clause, provided it's a de-facto part of the vendor's operating system. So, you can use all Win32 calls and all system DLLs on Windows in GPL software. You can compile and link against Solaris's non-free libc without worry.
Does my bum look big in this?
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.
With MySQL it is a bit more then just an abstraction problem. Untill fairly recently MySQL did not support foreign keys and it still doesn't by default.
:)
So take a:
client -< order -< parts
relationship.
On deleting the client you'd have to select all orders and delete the parts involved, then delete the orders and then delete the client.
Now exchange MySQL for a real RDBMS. The RDBMS will take care of everything upon deleting the client. There is no real harm in your application trying to delete records that have already been deleted, but I hope you can see the need or at least the urge to rewrite it.
This is just a simple example. if you take into account the multitudes of 'programmers' who've never heard of transactions and were first exposed to databases with MySQL then the agony is endless
Bottom line is: when porting from MySQL, expect rewrites!
What a rotten party, have we run out of beer or something?
What are you talking about? MySQL AB changed the client libs from LGPL to GPL. That messed up a lot of things but it theoretically generates more commerical licenses for MySQL AB.
Add in the unusual gpl interpetation by MySQL AB where programs that use mysql for commericial use are required to get the commericial license and where distribution is interpeted to be copying the program between servers even within the same company and you have a company that is doing it's best to create FUD and force companies into buying commericial mysql licenses.
Oh yeah, the developers made vague noises about how people reverse engineering the client/server protocol and creating an alternate license may get sued by MySQL AB.
How's that for good company policy?
"When you sit with a nice girl for two hours, it seems like two minutes. When you sit on a hot stove for two minutes, it
POSTGRES
Founded on Ingres (not Ingre). Sorry, it's a pet peeve of mine... I've known people for years that call it that, and it drives me nuts.
On your other comment.... It'll hurt MySQL more to abandon the OSS community than the opposite.
Take a look at all the PHP apps that are tied to MySQL. I know there's (I think it's called) ADODB for PHP now, which for the uninformed is like perl's DBI for PHP, but it's PEAR and not everyone has it. DBI is pretty much the de-facto way to access databases in perl, and there's an easy way to write simple SQL that works for the 3 most popular UNIX databases (Oracle, MySQL and PostgreSQL), save sequence manipulation. OF course, when you start getting into more advanced SQL you're looking at a further abstraction. And forget stored procedures.
The reason that this could have hurt PHP is that MySQL and PHP are both fast, easy to use and have little learning curve allowing junior programmer-types to get a lot done in little time.