[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
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
- Re: [Chicken-hackers] Re: Backdoor GPL in message-digest, (continued)
- Re: [Chicken-hackers] Re: Backdoor GPL in message-digest, Felix, 2010/08/24
- Re: [Chicken-hackers] Re: Backdoor GPL in message-digest, John Cowan, 2010/08/24
- Re: [Chicken-hackers] Re: Backdoor GPL in message-digest, Peter Bex, 2010/08/24
- Re: [Chicken-hackers] Re: Backdoor GPL in message-digest, John Cowan, 2010/08/24
- Re: [Chicken-hackers] Re: Backdoor GPL in message-digest, Magnus Achim Deininger, 2010/08/25
- Re: [Chicken-hackers] Re: Backdoor GPL in message-digest, John Cowan, 2010/08/25
- Re: [Chicken-hackers] Re: Backdoor GPL in message-digest,
Magnus Achim Deininger <=
- Re: [Chicken-hackers] Re: Backdoor GPL in message-digest, Thomas Bushnell, BSG, 2010/08/25
- Re: [Chicken-hackers] Re: Backdoor GPL in message-digest, Magnus Achim Deininger, 2010/08/26
- Message not available
- Re: [Chicken-hackers] Re: Backdoor GPL in message-digest, Magnus Achim Deininger, 2010/08/26
- Re: [Chicken-hackers] Re: Backdoor GPL in message-digest, Thomas Bushnell, BSG, 2010/08/26
- Re: [Chicken-hackers] Re: Backdoor GPL in message-digest, Thomas Bushnell, BSG, 2010/08/26
- Re: [Chicken-hackers] Re: Backdoor GPL in message-digest, Felix, 2010/08/24
- Message not available
- Re: [Chicken-hackers] Re: Backdoor GPL in message-digest, Felix, 2010/08/24
- Re: [Chicken-hackers] Re: Backdoor GPL in message-digest, Jim Ursetto, 2010/08/23
- Re: [Chicken-hackers] Re: Backdoor GPL in message-digest, Jim Ursetto, 2010/08/23
[Chicken-hackers] Re: Backdoor GPL in message-digest, Jim Ursetto, 2010/08/23