Re: GPL-licensed packages with depend-chain to OpenSSL
On Mon, Sep 06, 2004 at 02:38:30PM -0400, Brian Thomas Sniffen wrote:
> But it'll link against lubcurl-ssl, which we also put on the user's
> machine. It doesn't matter how complicated the contraption for
> getting some program with libcurl-ssl and openssl into a shared memory
> space on an end user's machine is -- it's still a contraption for
> distributing that final work.
(a) Being in the same shared memory space is not a sane criterion for
being a module contained in a program. For example, _everything_
runs in a shared address space on, e.g., Mac OS 9.x and earlier. The
same applies to various embedded platforms (does it apply to
uClinux, I wonder?)
I propose that a requisite of BAR being a module contained in FOO is
that FOO in some way use BAR. If we use this test, it has been stated
that in this particular case the program does not ever make use of
OpenSSL. Thus FOO in no way uses BAR.
(b) The method is what must be analyzed, not the end result. As a
trivial example, take the end result of having Microsoft Windows
installed on a PC. A legal contraption to do that would be to go to
your local computer store and buy a copy. An illegal contraption to
do that would be Kazaa.
As an example, I think distributing a package which downloaded FOO
source code and compiles it --- on the user's machine --- with OpenSSL
might be fine, as we'd be distributing under GPL 2 (or even GPL 1), and
GPL 2 doesn't require source to all modules contained in the program
(only to the program and works based on it, which OpenSSL clearly
isn't).
Reply to: