On Thu, 20 Jan 2005 20:55:12 -0500, Raul Miller <[EMAIL PROTECTED]> wrote: > > 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.
We seem to be talking past one another. Maybe it's just that I'm implicitly assuming a separation between "library source code" and "program source code", and saying that the latter is only a derivative work of the former if it contains copyrightable material, which API calls are not. I don't think either of us means to get into a semantic debate about whether the phrase "program source code" ought to refer to the whole ball of wax. So I'll use "program exclusive of the library", or PEOTL, instead. My previous interpretation was that your "written without" phrasing meant to imply that clean-room practices are necessary for the PEOTL not to be a derivative work, and that's what I was arguing against. Clean-room practices, in a project to clone proprietary functionality, help minimize the risk of being prosecuted for misappropriation of trade secrets. With published source code, there are no trade secrets in play. Clean-room practices might also reduce the likelihood that a similarity genuinely dictated by functional requirements would be taken by a court as evidence of copying. However, that's usually not a problem when you're implementing the opposite side of the interface. > > 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. Am I correct in reading this as agreement that the PEOTL is not a derivative work of the library? > 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. ACK. > 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. Let's assume that I wrote the PEOTL and intend to distribute it under the following license: "You have the copyright holder's permission to use, copy, modify, and distributed modified copies of this code, in source code or binary form, and to relicense the result to others under terms of your choice, as long as everyone pets a cat." This is GPL-incompatible in the sense that a derivative work of both GPL and "pet-a-cat" code is undistributable. > 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. That's actually very nearly the substance of the Lexmark ruling, given the additional fact that an SHA-1 checksum of the program in the printer cartridge was used by the printer as a "lock-out code" to reject non-Lexmark cartridges. Lexmark was trying to use the copyright monopoly to criminalize the creation of interoperable cartridges; instead, the appeals court ruled that they gave their entire program a functional aspect and rendered it uncopyrightable. That's not where I was going, though; I was saying that the PEOTL doesn't infringe the library's copyright. But the PEOTL+library combination, like any collection of things containing the library, does constitute "copying" in the legal sense. If I don't have a license to copy the library, or if I had one and it was rescinded, then I'm infringing its copyright. So far so good? > > > "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 was misinterpreting the thrust of your argument, I think. > I rather intentionally did not go into the technical details of what > distinguishes "published" and "not published". OK. > > > 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? OK. I still don't understand the sentence: "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." Specifically, I don't understand "the GPL restricts distribution of itself at violation time". Could you please rephrase it? > Also, I don't think your hypothetical example is all that meaningful. > > Unanswered questions: > > [1] Is A distributing this program? Yes. > [2] How can A rely on the GPLed content being there for this program? A is distributing the library as well, on the same CD. > [3] How can A ensure that the GPLed content is the proper version of > the GPLed content? A distributes both. > [4] Why did A bother doing this in the first place? To write a useful program, for which the library is a useful component, under a reading of the GPL that permits this usage. > [5] Why is A not releasing this new code under GPL compatible terms? Any legitimate purpose for which A didn't think the GPL was the best choice. To make a buck. To encourage people to pet cats. Let's take, for a moment, a myopic view of the stipulated facts. The conditions under which the GPL undertakes to self-destruct, as I read them, apply to the copying of the original work, the creation and distribution of derivative works, and possibly also to copyrightable collections that are not formed by "mere aggregation". The library is a copy of the original work, but I'm following the GPL prescription with regard to its source code. The PEOTL is not a derivative work of the library, and the GPL doesn't apply to it. The PEOTL+library combination, formed by a routine mechanical means such as linking, is not a derivative work of the library, nor is it a copyrightable collection, so the question of whether I've done something other than "mere aggregation" to create it is moot. A CD containing the PEOTL, the library, and various other carefully selected components is a copyrightable collection, but it is certainly formed by "mere aggregation". So I've done nothing contrary to the library's GPL, and I can distribute the lot, separately or together. There's a weak point in the myopic argument. "Mere aggregation" isn't quite a term of copyright law, and some people are willing to argue that other activities that have nothing to do with copyright (like understanding the library well enough to use it properly, or using the library through its published API, or perhaps noting that the PEOTL has been thoroughly tested with version N of the library) go beyond "mere aggregation" and cause rescission of my license to distribute the library. Now let's take a broader view, in light of the judgments about public benefit that are also part of a judge's job. The monopoly right granted by copyright law is supposed to be for the public benefit. It encourages the creation, expression, and publication of knowledge and ideas by penalizing unauthorized copying and plagiarism of published works, since without constraints on publishers there would be no incentive to pay authors to create works that the others could copy for free. (Now that everyone has the means to be a publisher, the maintenance of those constraints is a fraught issue.) The "expressive vs. functional" distinction that limits the scope of copyright, and the recognized, protected "fair uses" of copyrighted material, exist largely to moderate the effect of the copyright monopoly on other people's legitimate commercial interests. Essentially the entire history of software copyright litigation is about striking the balance between rewarding creativity and hampering competition in a new kind of subject matter. US courts have permitted aggressive competitive tactics to replicate various kinds of functional interfaces in the absence of any license from the copyright holder, largely in the declared interest of interoperability for the public's benefit and convenience. Imagine one of those same courts faced with published source code, offered at no charge by its authors for others to build on. Imagine a commercially motivated developer that has proceeded to build on that code, respecting its terms with regard to derivative works, using the same development techniques routinely used to manage boundaries between related but separately maintained code projects. She appreciates that the published material has been placed in the commons, and she does her bit to keep the commons well groomed. She just doesn't want to have to give away her own, arm's length, interoperable work. Faced with a license that loudly claims it is founded in copyright law, which the developer can only be held to have violated if the court interprets "mere aggregation" in a way that has nothing to do with copyright law, what do you think that court will do? Where do you really think the balance of harms lies? > 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. I can't quite parse this, but I shall assume you are saying, "The GPL intentionally removes the freedom to take a derivative work proprietary, in the interest of strengthening collaborators' freedoms to create collaborative works in an environment of trust." I agree, and I think it's well written for the purpose (although I have some quibbles). But an interpretation of the GPL in which one's mind is tainted by reading and learning from GPL material is not good for anyone's freedom. Reasonable people may differ about whether it would be good to attempt to extend a "monopoly of the commons" across boundaries which commercial monopolies are obligated to respect. I am persuaded that, whether or not it would be good, it isn't in the GPL and wouldn't be honored by a US court if it were. Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
