On Thu, 27 Jan 2005 18:00:03 -0500, Raul Miller <[EMAIL PROTECTED]> wrote: > On Thu, Jan 27, 2005 at 02:18:48PM -0800, Michael K. Edwards wrote: > > If the public benefit of interoperability outweighs the harm done to a > > copyright holder by permitting competitive use of the interface they > > created, how can it not outweigh the harm to him of permitting > > cooperative use? > > Why assume that interoperability is the only benefit from release under > copyleft?
I'm not assuming that. I'm saying that the public benefit of interoperability, used in a number of the decisions that I've cited to justify permitting competitive use of an interface, is even stronger when the factual situation involves cooperative use. Hence the argument against applying these cases as precedent to the closed-application/GPL-library scenario doesn't hold water. > For example, there's issues like "more eyes on the code", "easier to > make derived works", and "enabling literacy". All of which I agree with. The GPL is a good thing. I would like to see all of the code in the commons under the GPL. I would like to see lots more code gifted from commercial software vendors into that commons. I believe that the FSF's attitude on the GPL and linking boundaries is the biggest obstacle to these goals. > And then there's the whole area of increasing the market for some related > product (for example: the hardware which runs the free code, or the > training services to help people use the free code more effectively, or > the consulting services to help businesses use the free code to improve > their processes, or ...). Yes, and I've made (part of) my living for the last decade or more, on and off, doing all of the above. None of these benefits go away when the closed-application/GPL-library scenario is also permitted. > For that matter, what makes you think that competitive use of the > interface is being disallowed? Near as I can tell, the only thing being > disallowed is use of the implementation and that's only being disallowed > in circumstances where the competing use won't comply with the copyright > on that implementation. Replace "won't comply with the copyright on that implementation" with "won't comply with the FSF's interpretation, poorly supported if at all by case law in any jurisdiction, of the power of the GPL to leverage the copyright monopoly to dictate the licensing terms of software that uses that implementation" and we agree. > > You can argue that there's a completely different kind of public benefit > > that would result from giving free software a special status, but you're > > going to find limited legal precedent for that view. > > Why bring in "a special status" as an issue? Because that's what one is arguing for when one argues that a free software license ought to be able to reach across an interface boundary even if case law says that copyright itself can't. There's room to disagree with this summary of case law, and there are other legal systems in the world besides the US, but arguing the unique public benefits of copyleft is irrelevant to the question of whether the existing precedents are applicable. > Free software exists under current copyright law. > > > In any case, the argument from free speech principles > > doesn't reduce the applicability of these precedents with regard to > > the copyright holder's economic interests. > > Sure, just keep in mind that free software copyright holders also > have valid economic interests. Of course they do. And like those of Sony, Sega, Lotus, and Lexmark, they may not win out over those of the creators of interoperable software and of the public, as interpreted by a court. > > > I strongly disagree. No one is arguing that you should not be able to > > > develop a proprietary program with equivalent functionality to a GPLed > > > program. The issue concerns the ability to build upon the actual GPLed > > > program in order to provide that functionality. > > > > So Sony should have attacked Connectix, not for emulating the > > PlayStation's interface in order to compete with it, but for building > > on customers' access to Sony-authored games to make their emulator > > useful? > > The PlayStation is GPLed? Connectix is GPLed? Connectix used Sony's > copyrighted code (what was on the other side of the interface)? > Unless the answers to one of these questions is yes, you're talking > about irrelevancies. If it were appropriate to prohibit a proprietary application writer from exploiting the availability of a GPLed library, in a way contrary to the preference of its copyright holder, then Connectix's exploitation of the availability of Sony-authored PlayStation games would be equally prohibited. Do you think that the court would have ruled for Sony if they had argued along these "exploitation of availability" lines instead of direct infringement? I think not. Nor do I think Sony could have successfully sued Connectix or its customers for using Sony's copyrighted game code together with the Connectix emulator, either under a copyright theory (a program running on an emulator does not constitute a derivative work, or to the extent that it does, it is an "intermediate copy" inevitably and permissibly created in the course of use) or under contract law and a prohibitive license clause. In saying this, I'm relying on cases like Sega v. Accolade and Specht v. Netscape. > > Or perhaps Sega should have fought Accolade, not for > > copyright infringement in the course of reverse engineering to create > > games for the Sega console, but for interfering with Sega's ability to > > engage in social engineering within the Sega-game-author community? > > Irrelevant, again. If a court should allow a GPL library author to use copyright on an API to force application authors to accept terms dictating that the application be licensed under the GPL, then the Sega court should have allowed Sega to force Accolade to accept terms dictating that Sega be the exclusive manufacturer of all games produced by Accolade. That's what Accolade set out to avoid by relying only on published sources and reverse engineering to create interoperable games. I'd say that's relevant. (And before you say it, reverse engineering isn't necessary when the source code is published, as it is under the GPL. The Sega case alone doesn't prove this, since the court focused on the accusation of copyright infringement during reverse engineering, and didn't rule on whether the content of the interface specification created by Accolade (exclusive of the unlock code bit) was copyrightable. Had this content been copyrightable, it could have supported a claim by Sega that the games themselves infringed their copyright, since the "fair use" defense only covered the reverse engineering process. To be confident that Sega couldn't have prevailed on that claim either, you need the logic in Lotus and Lexmark.) > > Fortunately for us all, engineering reality tilts the playing field in > > favor of componentization; where there are interchangeable components, > > there are opportunities to find new uses for those components, some of > > which may compete with their originators' interests; and courts > > properly frown on the abuse of the copyright monopoly to block this > > competition. There's a legal device designed to control the terms, > > not merely of copying, but of use; it's called a patent, and (in > > theory) requires a much greater showing of originality. > > You present a convincing case that contributory infringement is likely > to be limited in scope. But that's not the same thing as distributing > copies of the code behind the interface. Right. That relies on the rights granted under the GPL. I am arguing that the hypothetical application author has done nothing to justify rescission of his GPL right to distribute the library. > > I am, in fact, opposed to the idea that unlimited reach for copyleft > > is desirable. I don't really care whether the software inside my > > microwave oven is Free. I do want my government and my cellphone to > > run on Free Software, and neither will happen in my lifetime if there > > isn't a commercially viable transition strategy. > > Don't expect the license to be changed to make it easier for past problems > to resurface. I don't think the license needs changing. I think that a court's interpretation of it would already permit the uses I describe. I think that the FSF could, if they chose, save us all a lot of grief by re-evaluating their stance in light of these legal precedents, without waiting for a court case, and without changing a word of the GPL. In any case, I don't know what past problems you are talking about, unless you mean NeXT and MCC -- whose outcome I am quite confident would have been the same. > > Last I checked, some people were arguing against the legitimacy of > > running Eclipse on Kaffe because this alternate implementation of the > > JVM interface happens to expose the inconsistency of the "linking > > creates a derivative work" stance. What, this would be a smaller > > problem if the first JVM implementation were GPL'd? > > As it happens, that's not the case, and probably would never have been > the case. On the other hand, it would be plausible to have released > the first JVM under LGPL. Sorry, I didn't make the connection very clear, did I? Josh claimed that no one was arguing against the ability to create alternate implementations of the interface to a GPL component. I just don't see how one can seriously argue that alternate implementations are OK because the interface isn't copyrightable, but that use of that same interface when writing an application creates grounds for GPL rescission. So Josh must think that some action outside the writing of the application has violated the GPL. All the obstacles that I have heard raised for the co-distribution of GPL and non-GPL material that are combined at run-time have come up in the JVM discussion. Does Josh think that none of the anti-Eclipse+Kaffe arguments would have been made if Kaffe had preceded Sun's JVM? If not, then he must think that one of those arguments is valid, or he must have a completely different mechanism for GPL violation in mind. I'd like to hear it. > > > Use of words like "abuse" and "tricksy" to describe copyleft sound about > > > as convincing as those who attempt to label the GPL "viral". > > > > Courts and respectable commentators do use phrases like "abuse (or > > misuse) of copyright monopoly" to describe the conduct of plaintiffs > > who knowingly push the limits of copyright protection for > > anti-competitive purposes. Hint: Google for "abuse copyright > > monopoly Lexmark". > > This is not at all the same thing as the GPL. In Lexmark, the > "copyrighted" material in question served the role of a key in a lock, > and was not a work of art or science in any other respect. Not quite true, since it was also the program that measured toner levels. But Lexmark sought to abuse copyright on that program to intervene in commerce between Static Control and owners of Lexmark printers and thereby sustain a monopoly premium on interoperable cartridges. I think that trying to use copyright on a library's API to sustain an "ideology premium" on interoperable applications is a similar abuse. > > Agreed. But as I have repeated ad nauseam elsewhere, I am not arguing > > that the body of a library is uncopyrightable; > > You've presented arguments which basically said the same thing (in the > context of the GPL). But you're correct that you did not use those > exact words. I've done nothing of the kind. The body of the library is under copyright, is released under the GPL, and is only available for copying and modification on the GPL's terms. But, in light of case law that I understand to disallow copyright protection on its functional interface, those terms don't govern applications that use the library. > > > As for the second half, license incompatibility is obnoxious, and we'd > > > be better off if all Free Software was GPL-compatible, but it isn't, so > > > we deal with it. "GPL-compatible" is not the definition of Free, for > > > ourselves or for the FSF, nor should it be. > > > > License incompatibility is more than obnoxious. It is a major > > limitation on "Free-as-in-speech". It is not something to be > > complacent about. Most other Free Software licenses are notable for > > being "not-the-GPL", and the biggest reason for this is concern for > > the continued usability of a component in exactly the > > linked-from-proprietary-application scenario we are talking about. > > I place the blame for this on the structure and character of copyright > law. See also: LGPL. What problem, exactly, do you have with the structure and character of copyright law? What obstacle to wider adoption of the GPL do you find in copyright law rather than in the conflict between the FSF's position and the application vendor's needs? The LGPL is a poor attempt at a solution for a problem that doesn't really exist, for reasons that I have already outlined. > > This [tit-for-tat license incompatibility] is freedom? > > Yes. As a contributor to any of these projects, access to the others' source code without permission to copy it gives me no freedom that I don't already have with a decent shelf of CS textbooks containing similar ideas. Perhaps I should have asked, this is a commons? Cheers, - Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]