On Sat, 2003-04-26 at 01:17, Steve Langasek wrote: > I am not arguing that dynamic linking creates a derivative work, and I'm > not sure the FSF is, either. I *am* arguing that it is within the > purview of the GPL to impose restrictions on redistribution of dependent > works whether or not these are derivative works; and the FSF's GPL FAQ > asserts that they are doing so. Considering DFSG 1, I _sincerely_ hope they are not doing that! "In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." "a 'work based on the Program' means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language." So, unless the program is a derivative work, it doesn't fall under the GPL's requirements. Any license that claimed otherwise would, I think, fail DFSG 1. > Are you certain that a copyright holder who subscribed to this > interpretation would *not* have legal standing to sue someone for > bundling their GPLed 'mygrep' with a proprietary script that invokes it? A copyright holder has legal standing to sue anyone he damn well pleases. IANAL, but I think said suit would be lost. The point is, of course, that we have _hundreds_ of scripts like this, and we seem to (by inaction, at least) judge that OK. > There are two differences, however. First, we know of no copyright > holders who assert such a requirement in the case of shell scripting > interfaces; whereas in the case of GPL modules that are loaded into > memory by interpreters, there is at least one prominent copyright holder > who asserts this requirement. Sure. This does lessen lawsuit risk, but the point is anyone could get ticked off and decide to suddenly try and enforce that. If it's illegal, we shouldn't be doing it --- whether someone currently complains or not. > Second, in the case of shell utilities, it > is the original authors who have exposed a certain interface (the exec() > interface) for use by the system; whereas in the case of a Perl module, Hold on a sec. It's pretty clear that the authors of libmysqlclient have exposed a certain interface (the C API) for use by other programs on the system. The perl module is just using that documented, public interface. > The truth is that much of this is very fuzzy; but there are some reasons > to believe we are acting in good faith when we use GPL shell utilities > from GPL-incompatible scripts, and there are also some reasons (such as > the statements in the GPL FAQ) to believe this argument would not hold > up as well when the GPL lib is incorporated into an extension to an > interpreted language. What, actually, is the difference? That the kernel happens to load libraries into the same address space as programs, but separate programs have separate address space? Does that mean that using those shell scripts on Mac OS before 10 would be illegal because all processes share one address space? Or that shared memory is a problem? Would that be any different than shared disk space, in light of mmap? Why does bash's or dpkg's use of execve(2) for a shell script form a magic copyright barrier, while Perl's use of AutoLoader does not?
Attachment:
signature.asc
Description: This is a digitally signed message part