On Wed, May 07, 2003 at 12:50:30AM -0500, Branden Robinson wrote: > On Mon, Apr 28, 2003 at 05:58:15PM -0500, Steve Langasek wrote: > > Any chance you'd care to comment on the underlying question of whether > > Debian should or should not accede to the FSF's claim that GPL > > modules for interpreted languages demand GPL scripts? I believe Anthony > > and I are at an impasse; we simply disagree on the relative weight that > > should be given to various factors involved here, so no consensus is > > likely to be forthcoming between the two of us.
> I've been away from the list for a few days, but using Mutt to limit the > message view to subjects including the string "interp" reveals no > messages I haven't already read. I recall a message from you referring > to the GPL FAQ which confusingly talks about whether people can "run" > GPL-incompatible scripts with a GPLed interpreter, which only serves to > cloud the issue since "The act of running the Program is not > restricted". Apparently, I haven't expressed myself very clearly. Yes, I'm not saying a user running such a script would be violating the GPL; the GPL doesn't speak to running the program, and the GPL is non-binding on users. I'm also not talking about any cases where a script is distributed separately from the interpreter, or where the bindings for the interpreted language are distributed separately from the GPL library that they make available to the script; these are gray areas, and not germane to the activities of Debian or its redistributors. I am specifically addressing the case where: - a library, libfoo, available under the GPL - an interpreter, pargle, available under a GPL-compatible license - a module that provides bindings for scripts written in pargle to use libfoo, also available under a GPL-compatible license from a different upstream - a script, fooadmin.prg, under a GPL-incompatible license are all distributed together in such a manner that running the script causes pargle to load libfoo for use by fooadmin.prg. The *act* of running fooadmin.prg is not a violation; but the facts of how this code is combined into a single runtime executable at the instant of running, without any conscious intent on the part of the user, show, I believe, that the distribution of such a combined work constitutes a violation on the part of the distributor. The GPL FAQ supports this interpretation, saying, If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses? When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone. However, when the interpreter is extended to provide "bindings" to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example of such a facility; libraries that are accessed in this way are linked dynamically with the Java programs that call them. Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together. A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way, regardless of the license used in the Perl or Java interpreter that the combined Perl or Java program will run on. The FSF's statement is really much farther-reaching than I believe it has any grounds to be (see the "gray areas" above), but if it has any merit at all, the case is strongest when distributing all the components together in a single product (operating system or otherwise). So my questions for debian-legal are, Do you believe the GPL FAQ presents a legally valid interpretation of the GPL, as it pertains to the case of combined distribution described above? Do you believe this interpretation is *applicable* to GPL code that is copyright FSF, to code that is copyright MySQL AB, and to GPL code in general? Why or why not? If this interpretation is applicable in some or all cases, could Debian be in violation for using GPL commandline utilities from GPL-incompatible scripts? If not, how are commandline utilities different from language bindings for an interpreted language? My own answers are: Yes, it's valid. As a proponent of copyleft, I think that if it isn't valid, there's a grave bug in the GPL to allow such circumvention. Yes, it's applicable to all GPL code, since by virtue of the FSF's prominent position among the GPL-using community, many GPL-using authors are likely to use the GPL FAQ as a guide for their own understanding of the license. It is *particularly* applicable in the case of MySQL AB, who have been involved in the most controversial GPL-related legal action I'm aware of to date. No, Debian is not in violation if the GPL component is a stand-alone executable, for two reasons: first, although arbitrary, this is where the GPL FAQ draws the line; second, the execve() interface is the interface that the authors of the GPL tools have exposed to the world, which makes this substantially different from the scenario of third-party glue code to allow integrating the GPL code into an interpreter. > Is it any help to cite the libreadline/libeditline case? Readline is a > GPLed library authored by the FSF. Editline is a BSD-licensed clone > (with a limited feature set) developed by people who weren't happy with > Readline's licensing. I think it's an interesting case to consider because of the question of whether an interface is copyrightable, but I think that discussion is best left for another thread. In any case, I believe the "generic interface" defense is only applicable when the distributor is not distributing a combination that requires selecting one specific implementation as the default. To restate: If distributing a statically-linked binary that combines a GPL library with GPL-incompatible code is a violation of the GPL, then shipping *any other combination of files* which constitute a program that, when run, result in a corresponding intermingling of GPL and GPL-incompatible code in memory is also a violation of the GPL. You cannot circumvent the GPL's requirements on source code by shipping your combined work in the form of a GPLed library and a GPL-incompatible program; nor can you circumvent them by writing (or reusing) a GPL interpreter and shipping it together with the GPLed library and your GPL-incompatible script (bytecode). (I'm going to ignore the much hairier RPC question for the moment. :) > Because the two libraries are interface-compatible, the FSF is not in a > position to forbid people from distributing code that "links" against > libreadline if that code is not licensed GPL-compatibly, because the > code could be linked against libeditline instead.[1] Yes, but they are in a position to forbid distributing such code together with readline itself. -- Steve Langasek postmodern programmer
pgpdFJCtf8mh8.pgp
Description: PGP signature