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

[Magnus Achim Deininger]

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

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

Cheers,
-- Magnus