Re: Re: PHP 5.0.0 Beta 1

I still feel eerie, it'll be more of a hastle for me, and I'm not big on that. Part of the problem I am going to be facing is developing in PHP on Windows. Since I am essentially = to poor, the SQL servers (for Windows) which cost money (ehem, mostly everything but mySQL), will be unavailable to me. The bigger problem will be when I drop stuff onto my web host where I, more then likely, won't find the same SQL db. I may have to resort to the old fashion way of doing things, like my buddy still does in Perl... arg... parsing text files. :-( - Stan Rasmus Lerdorf wrote:

What's the confusion here? Most non-GPL licenses are not compatible with the GPL when it comes to combining a GPL'ed and the non-GPL'ed component in the same package. This has nothing speficially to do with PHP. You also cannot link a GPL'ed libmysqlclient library into Apache in any way and redistribute that. So, something like mod_auth_mysql has that problem. This presents less of a problem to the end users. If you are not planning on redistribution you can pretty much do whatever you want. As software providers we are more inconvenienced by this. We cannot, for example, distribute code whose only purpose is to link against a GPL'ed library. I personally think potential linking restriction is beyond what the GPL can cover since we aren't including any GPL'ed code, but RMS disagrees and loves to beat on us for it. RMS's view is that if we distribute software which is only useful if it is linked against a GPL'ed library then we are indirectly violating the GPL by encouraging people to violate the license. Our ext/readline extension was a sore point for a while until we made it clear that the extension was aimed at the BSD-licensed libedit library which happens to share the same API as the GPL'ed libreadline. In the MySQL case we need to make sure that our MySQL extension can be linked against a non-GPL'ed library so as to not encourage people to violate the GPL. And MySQL AB will have some specific terms for open-source projects like PHP that will make this easier for us. You really shouldn't worry very much about this. Neither the PHP developers nor the MySQL developers want to make life difficult on PHP-MySQL users. We may not bundle libmysqlclient anymore, but that doesn't mean that we will drop MySQL support. The bundled library did cause some problems over the years with mismatched libraries and in the end you are better off having a single libmysqlclient library on your system that you link everything against instead of having some stuff linked against one version of the library and other stuff linked against another. -Rasmus On Sun, 29 Jun 2003, Stan Lemon wrote:

Could be. All I'm saying is I have a feeling that's the part of the license they are having a conflict with. Regardless... This brings a *serious* issue up for PHP, especially since mySQL is so common amongst open source developers. Unless there is some change it makes me hesitant to PHP5. - Stan Eric "e-dawg" Johnston wrote:

But PHP is Open Source. Might it be due to Zend? On Sun, 2003-06-29 at 18:56, Stan Lemon wrote:

I am assuming the following: 3. Commercial use for everyone else b) If you include one of the MySQL drivers in your non Open Source application (so that your application can run with MySQL), you need a commercial licence for the driver(s) in question. The MySQL drivers currently include an ODBC driver, a JDBC driver and the C language library. Robert Cummings wrote:

I read the licensing information in the above link, but I'm curious what exactly in it necessitated the need to unbundle MySQL? Anyone have a quick answer? Cheers, Rob.

-- PEAR General Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php