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
Attachment:
pgppZTcLqX_JC.pgp
Description: PGP signature