Michael K. Edwards wrote: > On Wed, 19 Jan 2005 21:10:57 -0800, Josh Triplett <[EMAIL PROTECTED]> wrote: > [snip] > >>On the other hand, a program written againt a unique GPLed >>library, with no other implementation, is almost certainly a derivative >>work of that library: you are combining two expressive and copyrightable >>works into a new whole which is greater than either. > > When combining the two is a mechanical operation, the combination is > not separately copyrightable, and hence is not a derivative work.
Of course; I am certainly not arguing that the mechanical act of linking them is where the derivative work is created. It exists well before that. > Nor > is the program a derivative work by itself if it uses a published > functional interface to the library. That's the upshot of the case > law as I understand it, although you have to combine a number of > precedents to get there. Note that combining a set of precedents, none of which individually make your point, is quite sketchy and speculative unless you are a court of law. > Here's one from the First Circuit that I > haven't cited previously, which is pretty much a slam-dunk: Lotus v. > Borland 1995 ( http://www.law.cornell.edu/copyright/cases/49_F3d_807.htm > ). Hardly a "slam-dunk", considering that Borland neither used code from nor accessed any functionality from Lotus; that case discusses the ability to copyright menu layouts, which has no real relevance to the issue of libraries and derived works. [snip quote] > It appears to me that, after trying out "fair use" and "de minimis", > US appeals courts have settled on uncopyrightability on functionality > grounds as the appropriate theory in which to ground the conclusion > which they believe to be good public policy. I do recognize that > there are a lot of other courts in the world, but the premise that the > GPL crosses linking boundaries was invented in the US, and threats of > legal action for GPL violation are usually made with reference to US > courts. Again, "linking boundaries" are not the issue here; linking itself doesn't create a derivative work (again ignoring issues of inlines, macros, etc). It's a far jump from that to arguing that the linking boundary stops derivation. A program need not include any code from the library to be considered a derived work of that library. Consider what would happen if I were to take a novel and write a new story in the same setting, or with the same characters, or even with a strong enough resemblance to those characters. I would not be including any amount of text from the original novel, and yet the new story is quite clearly a derived work, by both common sense and legal precedent. (Yes, I'm aware that doesn't provde the point that a program can be a derived work of a library; I'm making the point that including parts of another work is *not* the only way to be derived from that work.) - Josh Triplett
signature.asc
Description: OpenPGP digital signature
