Re: Implied exceptions to GPL?
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 debian-legal-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: