On Sun, Jul 25, 2004 at 10:46:32PM -0400, Brian Thomas Sniffen wrote: > I don't think you mean "derivative" in the same way the USC 17 means > "derivative", and I *really* don't think you mean it in the same way > Berne does. The idea that influence grants copyright is not common -- > indeed, it's not in any legal system I know of. That would mean that > everybody who decided to write a magic-school book after reading Harry > Potter would be infringing Rowling's copyright.
There are issues there with similarity "rip-offs" and so forth, but I can't recall if they get litigated as copyright infringement or something else (see the "Barry Trotter" books for examples, to continue the theme -- "Barry Trotter and the Shameless Parody" is supposedly very funny). What changes the playing field a bit, too, is that typically the only part of the copyrighted library that you see is the API and documentation, and (from memory) APIs aren't copyrightable. However, that may be irrelevant because you're not attempting to reproduce the library, but rather to "extend" it by building an application or other library on top of it. But if you stick to the published API, that's really use of the work in the manner it was intended to be used. It's all a very grey area of law, and unlike a lot of other things we debate, I can't think of any case that has been heard on the subject of libraries and derivative works. > Most seriously, of course, your scheme is not time-invariant. "It > *was* a derivative, but it isn't now," is not something we should ever > be hearing. Agreed. Or even the other way around. Imagine if you coded against OpenSSL, and you use that subset of functionality that is implemented by the GNUTLS compatibility layer. Suddenly your program is a derived work of GNUTLS... - Matt
