Re: On interpreting licences (was: KDE not in Debian?)
On Feb 08, Andreas Pour wrote:
> Now, please explain how the "executable work" which I am
> distributing (kghostview which is dynamically linked to Qt) "has in
> it", "holds", "encloses or includes", "has the capacity for
> holding", or is "equal or equivalent to", the Qt library. Sure, the
> Qt library can later be added to it -- like sugar to the gallon of
> water -- but is not contained in it.
A dynamically-linked kghostview is completely non-functional without
the Qt library. Qt is irrevocably bound up in that executable,
whether or not any of Qt's code is actually contained in kghostview.
(Besides which, some of Qt's code will be contained in the executable,
due to Qt's slot concept which [IIRC] requires preprocessing of the
source.)
Hypothetical: I build something under a proprietary license, and then
use the dl*() calls to access a GPLed library (let's use Readline for
example). Even though my software doesn't strictly-speaking contain
Readline, it doesn't function without it being present. I'm clearly
going beyond "mere aggregation" or using a fork-exec.
> That's why when you distribute a dynamically-linked kghostview you
> don't have to distribute Qt source code. Now of course this
> executable work no more contains Qt if it is distributed on the same
> CD. (However, in case it is on the same CD, the "special exception"
> would not apply.)
Qt is normally distributed in the same "kit" as KDE in a Linux
distribution; whether or not it physically resides on the same disk is
irrelevant. You're distributing the one with the other.
The only way around this is to require people to pick up Qt from
someone else and/or at a different time.
> If you don't like that result, I suggest you talk to FSF about changing the
> language of the GPL.
The result doesn't follow logically from your premises.
> Two flaws in this analysis. First, you don't have to distribute a
> working copy of kghostscript; in fact it would defeat the idea of
> dynamic linking to do so. Kghostscript will not work w/out libc,
> libstdc++, libX and a bunch of other libs which generally are
> distributed separately, unless of course you are the OS vendor. In
> case you are the OS vendor, of course, you are subject to the
> exception.
Any Linux distributor is, by definition, the OS vendor; this means you
can't distribute the infringing component and the GPLed software
together.
> Second, insofar as you do not distribute a "working copy", you don't
> have to distribute the source code to the working copy. The source
> code, as I quoted above, is only to the executable work you are
> distributing. That's why if you distribute just, say, The Gimp, you
> are under no obligation to make the X and libc source code available
> (in case you want to argue that you are, then I will point out then
> that virtually *everybody* violates the GPL, w/out protest from the
> FSF, and that's been going on since the GPL was first released, so
> its a pretty untenable argument).
If you distribute the Gimp in binary form, you are obligated (by the
GPL) to provide the source for the Gimp if anyone asks for it. Since
X and libc6 are covered by the XFree86 license and LGPL respectively,
they do not "contaminate" the Gimp binary in any meaningful way.
However, if someone specifically asks for the source to GNU libc, you
have to give it to them (since it's LGPLed). You are under no such
obligation with XFree86, though it's probably on the same source CD
you're using to fulfill the GPL and LGPL requirement anyway.
Now, if you linked the Gimp against Readline (a GPLed library), and
distributed that modified Gimp, you would have to provide the source
for both the Gimp and Readline.
> Actually, all it says is that you don't have to distribute the
> "source code". It doesn't say anything about not having to be
> licensed under the GPL. If in fact Section 2(b) requires you to
> license the full source code under the GPL, this would apply to the
> "component" as well -- the "special exception" only relieves you of
> the obligation to distribute the source code, not of any other
> obligation the GPL has with respect to that component.
Section 2(b) requires the combined work to be usable under the terms
of the GPL. It does not require the individual components to be
licensed under the GPL, but it does require that the aggregation (end
product) be subject to the terms of the GPL (and no terms that
contradict the GPL). By aggregation, I refer to the common sense
definition of aggregation (sticking things together to create a bigger
thing; linking, if you will), not the GPL's "mere aggregation" (which
is being distributed on the same media).
For example, I have written some software that is licensed under an
extremely liberal license (the Python license). I have created a
front-end to it that uses Readline (GPLed). Since I have permitted
people to modify and/or use the software for any purpose, with or
without modification, the front end satisfies the requirements of
2(b), even though the front end ITSELF is not licensed under the GPL.
To put it another way, the end-user has all the rights provided by the
GPL (actually, he has more, since he can incorporate it into
proprietary software, provided he only uses my code and not Readline).
Where this gets you in trouble is where you don't fulfil the
requirements of section 2(b) in your original license. For example,
if I distributed the same software under a M$-style EULA, I would be
violating section 2(b) because the end-user would not have the same
rights as those provided by the GPL.
Whether or not the actual components are licensed under the GPL is
irrelevant. What is relevant is that no permissions granted by the
GPL are abridged by any of the components. The (regex) Qt. licenses
abridge those permissions (in the case of the QPL, ever so slightly.
Same deal with the BSD Advertising Clause).
Chris
--
=============================================================================
| Chris Lawrence | The Linux/m68k FAQ |
| <quango@watervalley.net> | http://www.linux-m68k.org/faq/faq.html |
| | |
| Open Directory Editor | Are you tired of politics as usual? |
| http://dmoz.org/ | http://www.lp.org/ |
=============================================================================
Reply to: