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).