2007.07.14 08:15 "[Tiff] [ANNOUNCE]: Libtiff 4.0.0alpha released", by Andrey Kiselev

2007.07.16 15:23 "Re: [Tiff] [ANNOUNCE]: Libtiff 4.0.0alpha released", by Bob Friesenhahn

So what happens if someone builds a standalone piece of s/w (tiffjbigdecomp) that reads (compressed) data from stdin and writes (uncompressed) data to stdout. They can then write s/w that execs a sub-process, redirecting stdin/stdout to be a file on disk and a pipe, and then just read the decompressed data from the pipe. Does that infringe GPL? I think not (as otherwise no commercial s/w could run on Linux), in which case I think the claim that dynamic loading / linking does (infringe GPL) is not necessarily solid, as the difference between that and dynamic linking to a library is pretty thin.

To me these are completely different cases, and the filter process is not part of the "program" which runs it unless the program can not usefully run without it. It might as well be 'cat', which could be BSD 'cat' or GNU 'cat' or 'spell' which could be BSD 'spell' or GNU 'spell'. Graeme Gill clearly feels differently.

With the module case, the module becomes part of the address space of the program which invokes it, which make it part of the running "program". However, programs are an instance of something which runs on a computer and executables are not necessary the same thing as "program" so my point of view if GPL code is loaded via a generic interface (which could just as easily load non-GPL code) then the program which did the loading is not bound by GPL until it actually does the loading, and as such it can be distributed without GPL restrictions as long as the GPL-licensed module is not also distributed. The opinions of the Free Software Foundation may differ from my own (as I mentioned earlier).

Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/