On Thu, Feb 10, 2000 at 12:22:47PM -0500, Raul Miller wrote:
> > > 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.
>
> Either the program uses readline or it doesn't. If it does use readline,
> and it's distributed with readline, then, strictly-speaking, it contains
> readline.
I disagree.. If it was not built using one piece of readline (ie, none of
readline's headers) it does not contain readline until it is run. The GPL
can't control usage, only distribution. This is different than the KDE
and Qt situation in which Qt's headers are included and compiled in the
traditional manner. I am of the opinion that static vs dynamic linking is
irrelivant because in Qt's case the inclusion of Qt happens before
linking.
> > There is a BSDish readline clode whose interface matches readline's.. If
> > you wrote your dl*() access of libreadline using that non-GPL'd interface
> > definition, you would have succeeded in circumventing the GPL.
>
> Here, the biggest issue is: what's being distributed?
>
> If the program is being distributed with the BSDish readline, and not the
> GPLed readline, then there's no issue. But if the program is distributed
> with the GPLed readline, and not the BSDish readline, then it's pretty
> obvious that there's an issue. If the program is being distributed with
> both, then it comes down to which the program is configured to use.
The hypothetical program above is one which was built using unformation
from (but not source code for) a BSDish readline replacement, but would at
run time (not link time) find GNU readline and bind do it using the dl*
functions. The GPL doesn't even consider such a thing possible. There is
almost no difference in what is done here between dlopen() of GNU readline
and Corel's package front in forking a dpkg binary controlled through its
command line interface---something we have agreed (I hope) is beyond the
GPL's scope.
The fact that this can be used as a convoluted way to circumvent the GPL's
control over readline's linking does not automatically mean that a judge
would find this a GPL violation. In fact, I think a judge would determine
this to be outside the scope of the GPL since there is no logical way in
this example for one to conclude that the program was derived from
readline before the user ran it and the program took steps at runtime to
bind readline's functions.
This is part of the reason it is possible to create a GPL'd netscape
plugin, for example. If you do this, netscape does not suddenly become a
derived work of that plugin which AOL must suddenly release full GPL'd
source code for. The fact that in this example's program the author would
have specifically intended for their program to use GNU readline is almost
irrelivant because the license just doesn't say anything about it. I
could be wrong, but I don't think a Copyright license could---you'd have
to go to a shrinkwrap style license. I consider those immoral and
possibly illegal if you ever got a judge with a fraction of a clue...
--
Joseph Carter <knghtbrd@debian.org> Debian Linux developer
http://tank.debian.net GnuPG key pub 1024D/DCF9DAB3 sub 2048g/3F9C2A43
http://www.debian.org 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3
2.3.1 has been released. Folks new to this game should remember that
2.3.* releases are development kernels, with no guarantees that they
will not cause your system to do horrible things like corrupt its
disks, catch fire, or start running Mindcraft benchmarks.
-- Slashdot
Attachment:
pgpCKngv_l43H.pgp
Description: PGP signature