[Top][All Lists]

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

Re: [Chicken-hackers] Re: Backdoor GPL in message-digest

From: John Cowan
Subject: Re: [Chicken-hackers] Re: Backdoor GPL in message-digest
Date: Wed, 25 Aug 2010 11:19:42 -0400

On Wed, Aug 25, 2010 at 8:38 AM, Magnus Achim Deininger
<address@hidden> wrote:

> Incidentally, this is precisely the major problem with both GPL and LGPL:
> defining what actually counts as linking and what does not.

That's widely believed but untrue. The important question is not "What
is linking?" but "What is a derivative work?", which is a legal rather
than technical issue.  It is settled, for example, that an object file
is not a derivative of its source -- it is the same as the source for
copyright purposes, just as a microfilmed book is the same as the
book.  A statically linked executable is probably a derivative work,
though there is a respected minority opinion saying that an executable
is just a collective work like a tarball (which would undermine the
GPL completely).  Dynamically linked collections of executables and
libraries are a complete gray area: the FSF's guidelines are very

> Basically in languages like [Pascal], the LGPL becomes identical to the GPL
> since there is no distinct linking stage that could be performed separately.

Even in languages that don't have object files, like Perl or
Javascript (as normally implemented), it is still possible to have
obfuscated source, which does not count as "source" under the GPL.  An
LGPL Perl library, then, could be delivered in plain source form along
with obfuscated proprietary code, whereas a GPL Perl library could
not.  (In practice, proprietary Perl programs are delivered in plain
source, and the recipient is bound by explicit contract not to
redistribute them.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]