Um, to get back to the question: > If a programming language interpreter has a license that is incompatible > with the GPL, can I run GPL-covered programs on it?
> When the interpreter just interprets a language, the answer is yes. The > interpreted program, to the interpreter, is just data; the GPL doesn't > restrict what tools you process the program with. 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. 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. So if these facilities are released under a > GPL-incompatible license, the situation is like linking in any other > way with a GPL-incompatible library. Which implies that: Far be it from me to disagree with the FSF over GPL interpretation, but I think there are some points being overlooked here. One is that this is in the "user does the link" territory. The executing image may be undistributable, but nobody wants to distribute that anyway. Unless there's enough contamination of the library caller that the library vendor can claim an interest in the binary, the calling software is not a derivative work. The FSF has claimed that writing against a particular single-sourced library interface does create a derivative work (libgmp), but that wasn't widely accepted. And if there are multiple library implementations (say, Postgresql and Oracle), it kind of evaporates. What if I claim to have an alternate library implementation which I have just chosen not to release? After all, one of the points of the GPL is that I don't have to release. Even if it *is* considered a derivative work, there's a provision in the GPL to allow linking with "standard" binary-only libraries like a vendor libc: # However, as a # special exception, the source code distributed need not include # anything that is normally distributed (in either source or binary # form) with the major components (compiler, kernel, and so on) of the # operating system on which the executable runs, unless that component # itself accompanies the executable. I believe that interpreter run-time libraries *that normally come with the interpreter*, including a lot of Java libraries, clearly fall into this category. The interpreter is the (virtual) machine and operating system on which the executable runs, and the run-time is obviously a major component normally distributed with it. This is recognizing the existing conventions on linking user binaries with things like static libc.a. Anyone else who can compile on that platform at all probably has the necessary library. However, you don't want to use this in Debian, because of the uncertainty surrounding the word "accompanies". This is obviously a more inclusive term than "derivative work", and we need a definition that is consistent with the earlier use in the same section for "accompanying" the binary with the machine-readable source code. Unfortunately, the GNU GPL doesn't define it, so we have to look to the dictionary and common practice for guidelines. Certainly, "mere aggregation on a volume of a storage or distribution medium" *does* count as "accompanying", because that's usually how the obligation to provide "accompanying" source is usually met. Indeed, putting it on a separate CD in the same bundle, or on the same FTP server is standard practice for "accompanying". But then there are interesting issues. What about separate directories on the same FTP or web server? What if the proprietary code is in http://www.miskatonic.edu/~billg and the GPL-ed software is in http://www.miskatonic.edu/~rms? What about separate virtual servers sharing the same physical hard drive? What if they're separately sold CDs sold in the same store? What if a customer buys them both and puts them in the same plastic bag? What if he copies them to the same hard drive? What if the store has a combo discount offer? What if the clerks helpfully rubber-band the combo together for the convenience of the customers? The general idea appears to be to prevent a proprietary "major component" vendor abusing the exception, but it leads to a lot of problems for large distributions such as Debian or even a typical shovelware CD. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
