Anthony DeRobertis <[EMAIL PROTECTED]> writes: > On Sep 4, 2004, at 07:55, Florian Weimer wrote: > >>> That sounds quite like "plac[ing] restrictions on other software that >>> is distributed along with the licensed software." >> >> If curl-ssl is linked to GPLed programs by default, it's not mere >> aggregation. > > But it's not linked to the programs. The programs would, of course, > Build-Depend on libcurl and Build-Conflicts with libcurl-ssl. So the > programs were dynamically linked to libcurl-nossl (or libcurl-gnutls, > or whatever). > > We then distribute source under the terms of the GPL: > > The source code for a work means the preferred form of the > work for making modifications to it. For an executable work, > complete source code means all the source code for all modules > it contains, plus any associated interface definition files, > plus the scripts used to control compilation and installation > of the executable. > > The binary of FOO we redistribute contains the module FOO, of course, > and maybe the module libcurl-nossl. We distribute the source to those > under GPL 3(a). > > If libcurl-ssl happens to be installed by default, how does that > matter then? OpenSSL is not a module of FOO because /FOO was compiled > without it/.
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. Debian will still have built a contraption that distributes some program containing OpenSSL to an end user. -- Brian Sniffen [EMAIL PROTECTED]
