The distinction is very simple - whatever code that is a derived work from the GPLed parts (and assuming they are *GPLed* and not, LGPLed, for example) can only be distributed under the GPL license by him.
In practice what this usually boils down to in most cases is that if it's code that is linked in any way (via using a loadable library, using a static library, copy & paste from the sources etc.) to GPLed code then it too falls under the GPL. If you're using the GPLed software in some other way (sending commands from a propritery program via a pipe, executing the GPLed program and using the results, making use of normal well defined generic interfaces such as system calls) then your client code is not derived work and he has no obligation concerning his own code in this case. The GPL still applies on the GPLed parts though.
The distiction is anything but simple. The above seems in line with the stand FSF has expressed in such matters (in the relevant FAQ and various other opportunities). Alas, while the FSF's interpretation of the GPL is socially binding in some circles, its legal status is close to null. The the GPL itself is far from such concreteness, and in fact carefully avoids any technical definitions (see Section 2 paragraph 4).
As for the distinction you propose: what's the essential difference between use via loadable libraries and and use via pipe commands? Either can be easily used to simulate the other (at least in the normal case where the library and app don't share memory buffers and such), so the two cases are equivalent up to overhead. Put otherwise, if pipes block GPLness then I can just put a pipe-based RPC wrapper around the GPL library (using CORBA or RMI or custom code or whatever) and voila, it can be used in in proprietary programs. Somewhat odd.
Eran
================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
