Glenn Maynard wrote: > On Sun, Jul 25, 2004 at 09:15:44AM -0700, Josh Triplett wrote: > >>>More clearly (according to my understanding), the resulting binary >>>is--it pulls in pieces of readline--but the source is not. (I'm not sure >>>if this impacts your point, but it's an important distinction.) >> >>That's debatable. If your program is written against a library, and >>there is only one implementation of that library, I would argue that the >>source is a derivative of the library as well. Things get more complex >>if there are multiple implementations, of course. > > LGPL clause 5 seems to express the FSF's view on this, which seems > correct and reasonable to me: > > " 5. A program that contains no derivative of any portion of the > Library, but is designed to work with the Library by being compiled or > linked with it, is called a "work that uses the Library". Such a > work, in isolation, is not a derivative work of the Library, and > therefore falls outside the scope of this License. > > However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables."
I see. Thank you, that clarifies perfectly. I had thought from previous GPL discussions that "distribute the source and let users link it" was not a reasonable way to sidestep license compatibility issues, because the source was still a derived work. Does this mean that one can distribute the source (or object files, even) of a program that links to a GPLed library, and just let users link it? That seems like a rather large loophole. - Josh Triplett
signature.asc
Description: OpenPGP digital signature
