Ralf Corsepius wrote:
On Thu, 2006-02-16 at 13:13 -0600, Mike McCarty wrote:
Ralf Corsepius wrote:
On Thu, 2006-02-16 at 00:41 -0600, Les Mikesell wrote:
On Thu, 2006-02-16 at 00:31, Ralf Corsepius wrote:
Exactly, because it's GPL'ed. LGPL and GPL are different things.
Though they are similar, they are substantially different.
Yes, and in two ways. First, they affect the library itself
differently, and second, they affect the code linked with it
differently. GPL completely infects all code it touches.
LGPL doesn't, but one must still, in effect, provide source
to the customer.
.. if you implement a derivative works of LGPL'ed work.
That's not the case if you dynamically link against a LGPL'ed work.
That isn't the way I read it. Section 6 of the LGPL seems to address
this issue, and seems to me to treat dynamic linking in exactly the
same manner as static linking, calling both "derived works". RMS
said that if a work dynamically linked, and did not include the
header of the LGPL library then he'd have to think about it, but
he seemed to believe that if the header is included, then you have
a derivative work, even with dynamic linking. Certainly, section 6
seems to me to take the dynamic linking case into account.
Like to discuss the exact words?
To bring an example: If you port glibc to a new platform or implement a
new feature into glibc you will have to open your sources according to
the LGPL, because you implement a derivative work, having been derived
from LGPL'ed code.
Not as I read it. AIUI, so long as you don't distribute modified
versions of the library, you don't have to open it to anyone. It is
free for personal use. Perhaps you mean "port to a new platform...
and distribute".
If you write an application that uses glibc (effectively everything
under linux) you don't have to, because your work "uses glibc" and isn't
a derivative of glibc's sources or binaries.
That's also true, because (a) you haven't said anything about
distribution and (b) you haven't said anything about linking.
However, arguing from the position that the LGPL means exactly
what it seems to say, and that this meaning would hold in court,
and that you link (statically or dynamically doesn't matter, AFAICT)
with an LGPL library, and distribute, then section 6 says that
the parts of the program which are not free (IOW, the parts you
wrote yourself) would have to be provided in a form in which the
customer could rverse engineer it and possibly modify it for his own
use. This is a problem if the code contains trade secrets.
That's the way I understand it.
If you statically link your work, your work and the libraries it uses
become integral part of your application binary, i.e. your
"product" (the binary) is directly coupled to the libraries's binaries,
i.e. a derivative work of the library's binaries.
Well, if one takes the view of the LGPL, and takes the view that
it is enforceable in this respec, then yes. There is quite a bit
of debate over whether this actually makes it a derivative work.
That's exactly what the realplayer folks do: Their realplayer binary
uses glibc, gtk etc.
Then, as I read the LGPL, they must provide to their customers
their own code in a form that the customer can reverse engineer
and possibly modify for his own use. They can make the terms of that
be whatever they like, for example an NDA. (Always presuming
that LGPL means what it says, and is enforceable.)
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
