[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 Sat, 2003-04-26 at 01:17, Steve Langasek wrote:

> I am not arguing that dynamic linking creates a derivative work, and I'm
> not sure the FSF is, either.  I *am* arguing that it is within the
> purview of the GPL to impose restrictions on redistribution of dependent
> works whether or not these are derivative works; and the FSF's GPL FAQ
> asserts that they are doing so.

Considering DFSG 1, I _sincerely_ hope they are not doing that!

"In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of a
storage or distribution medium does not bring the other work under the
scope of this License."

"a 'work based on the Program' means either the Program or any
derivative work under copyright law: that is to say, a work containing
the Program or a portion of it, either verbatim or with modifications
and/or translated into another language."

So, unless the program is a derivative work, it doesn't fall under the
GPL's requirements. Any license that claimed otherwise would, I think,
fail DFSG 1.

> Are you certain that a copyright holder who subscribed to this
> interpretation would *not* have legal standing to sue someone for
> bundling their GPLed 'mygrep' with a proprietary script that invokes it?

A copyright holder has legal standing to sue anyone he damn well
pleases. IANAL, but I think said suit would be lost. The point is, of
course, that we have _hundreds_ of scripts like this, and we seem to (by
inaction, at least) judge that OK.

> There are two differences, however.  First, we know of no copyright
> holders who assert such a requirement in the case of shell scripting
> interfaces; whereas in the case of GPL modules that are loaded into
> memory by interpreters, there is at least one prominent copyright holder
> who asserts this requirement.

Sure. This does lessen lawsuit risk, but the point is anyone could get
ticked off and decide to suddenly try and enforce that. If it's illegal,
we shouldn't be doing it --- whether someone currently complains or not.

> Second, in the case of shell utilities, it
> is the original authors who have exposed a certain interface (the exec()
> interface) for use by the system; whereas in the case of a Perl module,

Hold on a sec. It's pretty clear that the authors of libmysqlclient have
exposed a certain interface (the C API) for use by other programs on the
system. The perl module is just using that documented, public interface.

> The truth is that much of this is very fuzzy; but there are some reasons
> to believe we are acting in good faith when we use GPL shell utilities
> from GPL-incompatible scripts, and there are also some reasons (such as
> the statements in the GPL FAQ) to believe this argument would not hold
> up as well when the GPL lib is incorporated into an extension to an
> interpreted language.

What, actually, is the difference? That the kernel happens to load
libraries into the same address space as programs, but separate programs
have separate address space? Does that mean that using those shell
scripts on Mac OS before 10 would be illegal because all processes share
one address space? Or that shared memory is a problem? Would that be any
different than shared disk space, in light of mmap?

Why does bash's or dpkg's use of execve(2) for a shell script form a
magic copyright barrier, while Perl's use of AutoLoader does not?

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: