Michael D Schleif <[EMAIL PROTECTED]> writes: > Matthew Palmer <[EMAIL PROTECTED]> [2003:10:10:22:25:34+1000] scribed: >> On Thu, Oct 09, 2003 at 08:10:24PM -0500, Michael D Schleif wrote: >> > As I commented in response to David, I had always assumed that, so long >> > as we do not modify source code, GPL allows distribution of this sort. >> > Once I read the MySQL licensing page, I have doubts. >> >> Eh? Whether you've modified the code or not, the GPL requires you to >> fulfill all of it's requirements. One of those is that people you >> distribute to can get the source (either from you or via some other >> offer). >> >> If your application links to a GPL'd library (and the new MySQL client >> library is GPL'd, so you're stuck) you are required (by the FSF's >> interpretation of the GPL, at any rate) to GPL your program, which means >> handing over the source.
Well, that's not strictly true -- your intent is accurate, but there are some side cases: for example, if you don't distribute your program, you don't have to put it under any license, not even the GPL. If you do distribute it, you have to do so under a GPL-compatible license: for example, the MIT/X11 license, or the GNU GPL itself. >> > We want to do the right thing. This is *NOT* a matter of whether or not >> > we can get away without paying for software! That's so nice to hear, compared to the masses who complain that GPL'd source is not free enough for them to make proprietary products. >> Whelp, then, in that case, just buy a MySQL licence, get a licence for >> whatever other GPL'd software you link to (not much in the PHP/Apache/MySQL >> combo), and live happily in the night... > > Just what is meant by `link(s) to'? What's actually meant is creation of a derivative work. For example, the message I'm sending now is a derivative work of yours, because it embeds a bunch of your message. I'm making fair use of your message, so this isn't an infringement of your copyright, but this is certainly a derivative work. The FSF claims, quite reasonably, that whether I create a derivative work by hand or by building a machine to do it for me, it's still a derivative work. For example, using a computer program to replace some macro in my code with code I can distribute only under the GPL clearly creates a derivative work of that GPL'd work. The FSF then claims, somewhat reasonably, that static linking performs the same functions and in the same way as the process I just described. So if I distribute a program which statically links to GNU readline, then GPL'd readline code ends up in my binary and I have to distribute that binary under the terms of the GPL. The FSF further claims, with much yelping and rapid waving of hands, that dynamic linking performs the same function, and that it does it in a different way shouldn't make a difference. So if I distribute a program which dynamically links against GNU readline, then despite the fact that I'm distributing no GPL'd code at all, but merely instructions to the user saying "run some GPL'd code here", I must distribute my code under the terms of the GPL. There's an excellent discussion of this matter in, of all places, the Debian clisp package: Stallman's argument is that if he doesn't view things this way, then dynamic linking will provide a way around the GPL, which he doesn't want. > In the programming sense, whereby our code directly calls library > objects, such as in dynamically/statically linked binaries? > > Or, as in our case, where said libraries are called indirectly, and > referentially, via SQL calls made by PHP code? I believe these are the same: your code links to the PHP MySQL glue code, which links toe MySQL, which is GPL'd. For example, from the FSF's FAQ on the GNU GPL: When the interpreter is extended to provide "bindings" to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a facility; libraries that are accessed in this way are linked dynamically with the Java programs that call them. Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together. A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on. "PHP" substitutes into that last paragraph just fine. What does this mean for you? Well, not something you're going to like: if you want to distribute code which uses the contributes generously made available to you by the MySQL developers, you have to comply with their licensing terms by making your source code available to whom you give a binary. You may wish to consider using a different database. Even if you do use PostgreSQL, which is under a BSD-like license, you'll have to include source for all of the GPL'd software -- if you're not making any changes to GPL'd software, a Debian source CD set will cover this. -Brian > Please, bear with me, because I am in unfamiliar water, and I want to do > what is right. Nevertheless, I do want to understand the rules, and not > pay by extortion, as per other popular licensing models ;> > > -- > Best Regards, > > mds > mds resource > 877.596.8237 > - > Dare to fix things before they break . . . > - > Our capacity for understanding is inversely proportional to how much > we think we know. The more I know, the more I know I don't know . . . -- Brian T. Sniffen [EMAIL PROTECTED] http://www.evenmere.org/~bts/