[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: Magnus Achim Deininger
Subject: Re: [Chicken-hackers] Re: Backdoor GPL in message-digest
Date: Wed, 25 Aug 2010 18:19:20 +0200
User-agent: Opera Mail/10.61 (Win32)

On Wed, 25 Aug 2010 17:19:42 +0200, John Cowan <address@hidden> wrote:

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.

What I meant there was, that there is considerable confusion as to what is meant with "linking" in the GPL and LGPL, as opposed to what is "derivative work". The confusion becomes even worse in languages where there is no clear distinction between different compilation and linkage states.

Which of the two questions is more important tends to depend on the context. For most of the things me and my colleagues do at work which involve open source software combined with proprietary code, the definition of "derivative work" is directly related to the definition of "linking" that is used.

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

If "linking" in the LGPL sense refers to dynamic linking, you could use your favourite archiver to create a self-extracting archive of your programme and the used shared libraries, and then instruct it to run your programme after extraction, transparently. Since you'd end up with a single binary that does not do any external linking, you might argue that would be same as linking your programme statically against the library right away (it's not the same, technically, but the effect is quite similar). Of course, you could argue that this method involves recreating the shared library and the original programme as physical files on your filesystem somewhere, but what if you did it all in memory, maybe threw in a special linker to work around having to have the physical files? If you follow that line of thought, sooner or later you arrive at some point where, even though you never did any static linking, the effect is virtually indistinguishable, but you can't really draw a line when the dynamically linked executable turned into the equivalent of a statically linked one, which might then count as derivative work.

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.)

Interesting point... but again, it's hard to draw a line when obfuscated code turns obfuscated enough to not count as "source" anymore. A similar problem arises when your proprietary programme is actually written in assembly and you're using a GPL'd library. You might keep your documentation and comments in separate files from the actual assembly code (maybe even for a valid reason instead of a constructed one, like you'd like keep it all documented in LaTeX or something). I'm not sure if the GPL requires you to release internal documentation, but IIRC it does not, so then even if you do release the source and thus comply with the GPL, it's virtually identical to a disassembly of the generated object file, which would violate the GPL's requirements (as merely releasing object files to link against only works with the LGPL).

[ All this is just my 2c. I'm not a lawyer either, and my non-proprietary projects tend to end up as MIT/X as it is. I do however think that both the GPL and LGPL are terribly vague in their requirements, which is kind of weird considering how long the licences are compared to BSD-2 and MIT/X, which IMHO are terribly clear in what they require. ]

-- Magnus

reply via email to

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