[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#189164: libdbd-mysql-perl uses GPL lib, may be used by GPL-incompatible apps



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


Reply to: