> On Thu, 20 Jan 2005 11:53:37 -0500, Raul Miller <[EMAIL PROTECTED]> wrote: > [snip] > > I'd say this differently. The program is not a derivative work of > > the library if it was written without any of the relevant copyrighted > > material of that library.
On Thu, Jan 20, 2005 at 04:26:18PM -0800, Michael K. Edwards wrote: > No, it's not a derivative work if it was written without _copying_ any > of the relevant copyrighted material _into_ the program source code. Didn't we just get done discussing that while technical details are informative they don't tell the entire story? While there are copyrighted programs which consist of only a single file, it's fairly typical for a program to be composed of many files. > It's OK to inspect the library source code, comprehend it, experiment > with it, work out what undocumented call sequence actually works > instead of something equally plausible but wrong, and generally to > write a program that wouldn't work without the library and couldn't > have been written without reference to its internals. You just can't > cut-and-paste, or even plagiarize in another language, expressive > content that could equally well have been written differently without > losing interoperability. There are different kinds of cases to consider here. If you're talking about being in compliance with the copyright on the library, and you're talking about a case where you don't need copyright privileges on the library itself, then you are essentially correct -- you're not violating its copyright by writing something that uses it. However, if you need copyright privileges for that library, that's a different story. If you need to provide copies of that library to other people, you still need to comply with its copyright. If you need to distribute modified copies of the library you need to make sure you're doing so under the terms of its license. And, the same thing goes for the code which uses the library -- if you need to distribute it, or modified forms of it, you still need to comply with the terms of its license. For example, if the precedent of lotus v. bourland were relevant in a context where you were distributing the library as a whole, that would be tantamount to saying that the library as a whole was not copyrightable because it was purely functional in nature. While that would be a rather interesting and perhaps exciting development for computer software professionals, I don't believe that's a likely ruling in a copyright infringement case. > > "A published functional interface" is a easily recongizable and legit > > way for a program to be written so that the program uses the library > > even though the program was written without using the library. Here, > > there's other material under a different copyright (the spec [obviously], > > but also the library headers and a library implementation). > > I think you and I are using "published" differently. You're assuming > that it's a standalone specification, probably with multiple > independent implementations, with fairly explicit permission to code > against it. I just mean "published" in a copyright sense, so that one > doesn't have to deal with trade secrets, "fair use" reverse > engineering, and "clean-room" standards. The notion of having to get > the job done without peeking at the internals just doesn't apply to > published source code. I think you're missing or ignoring the issues I'm trying to bring up. I rather intentionally did not go into the technical details of what distinguishes "published" and "not published". > > It's probably worth noting that Borland did this without using any > > lotus library (or headers, and probably without reference to any formal > > specification), and they certainly weren't being sued for using any such > > library inappropriately. > > Actually, they were being sued primarily because copying the menu > interface went along with copying the macro language, and both helped > users migrate from 1-2-3 to Quattro Pro. So they were being sued for > reimplementing a functional interface, part of whose function was very > much like a library API. I think I understand that. > > Since the GPL restricts distribution of itself at violation time, this > > idea of "function isn't copyrightable" isn't going to solve all the > > problems faced by someone violating the GPL. > > I don't understand this sentence. Perhaps you are trying to say that > for A to study a GPL library to understand how it works, and then > write non-plagiarized, non-GPL code that uses it correctly, causes A's > GPL rights to self-destruct, even if it is not true that under > copyright law the non-GPL code is a derivative work. That's not in > the GPL that I've read, and if it were -- this is freedom? That's hypothetical situation is rather narrowly focussed away from the typical cases I was trying to address. You don't seem to be asking me about what I meant to say -- instead you seem to be asking me about philosophy or something. If you have a question about what I meant to say, could you try again? Also, I don't think your hypothetical example is all that meaningful. Unanswered questions: [1] Is A distributing this program? [2] How can A rely on the GPLed content being there for this program? [3] How can A ensure that the GPLed content is the proper version of the GPLed content? [4] Why did A bother doing this in the first place? [5] Why is A not releasing this new code under GPL compatible terms? The GPL intentionally removes the freedom to collaborators freedoms on collaborative works. So, yes -- to answer your philosophical question -- there is an observable loss of freedom there, if you specifically look for it. This sort of boundary issue is a common problem when talking about ethics, rights, and similar concepts. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
