|
From: Donald J C. <dj...@ci...> - 2002-08-23 14:41:49
|
Richard Antony Burton wrote: > > ----- Original Message ----- > From: "Andy Green" <an...@wa...> > To: <eth...@li...> > Cc: <Xbo...@li...> > Sent: Wednesday, August 21, 2002 4:47 PM > Subject: [Xbox-linux] Question on supporting nVidia .o driver ... > So, when you compile an executable and you link it > dynamically to a GPLed library, the executable must be distributed as free > software with the library. This makes perfect sense, since the executable would not function without the GPLed library. > This also means that you can not link dynamically > both to a GPLed library and a proprietary library because the licenses of > the two libraries conflict." This, on the other hand, does not make any sense at all, and I bet that it would not stand up to a legal test (but IANAL). The GPLed library is not required to make the proprietary library function. The license of the proprietary library makes no restrictions on other libraries that might also be linked to the executable. I can't see how the GPL can extend from a library up into an executable and then down into another library. In a sense, the two libraries are not being linked together, they just happen to both be linked to a common executable. As someone else said, if the GPL does try to do this, then it is broken. I suspect there are no end of examples of GPLed code that links to the proprietary C libraries of various systems. IIRC, gcc linked with the system C library for a long time before the Gnu C library was an adequate replacement. -Don -- Don Christensen Senior Software Development Engineer dj...@ci... Cisco Systems, Santa Cruz, CA "It was a new day yesterday, but it's an old day now." |
