Re: Licensing requirements ???
Michael D Schleif <mds@helices.org> writes:
> Matthew Palmer <mpalmer@debian.org> [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 bts@alum.mit.edu
http://www.evenmere.org/~bts/
Reply to: