A side note, based on all your quoting of (dubiously relevant) legal cases: Hundreds of lawyers have looked at the GPL, both those attempting to get around it, those defending it for ideological reasons, and those defending it because their businesses rely on it. Do you really belive you alone have somehow "seen the light", and found out that the GPL is toothless where these lawyers have not, simply because you have been able to read a few legal cases? Michael K. Edwards wrote: > On Thu, 27 Jan 2005 18:00:03 -0500, Raul Miller <moth@debian.org> wrote: >>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. No, you'd like to see all the code in the commons under your GPL-but-really-LGPL license/interpretation. > 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. I, on the other hand, *like* that some proprietary software companies are hesitant to touch GPLed code with a ten-foot pole; this means that GPLed code has an advantage, which is good. There are certainly a number of businesses that have no problem working with GPLed code, and those business can take advantage of the huge body of GPLed works, giving themselves an advantage while giving us more GPLed code. >>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. That's an incredibly laughable remark; of course if you replace your opponent's argument entirely with your own, you agree with it. >>>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. In my opinion, you have yet to provide an applicable precedent, based solely on a question of "interface boundary". In all the cases you mentioned, "published interfaces" did not affect the verdicts. >>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. s/creators of interoperable software/& that takes advantage of their competitors software (copying it and distributing it in the process)/ Here's the *major* problem I have with your argument. You keep talking about "interoperable software". However, in most cases, the issue isn't that proprietary applications desire to "interoperate" with some library; they want to use the functionality of that library to achieve some other goal. You *might* have a leg to stand on if you were talking about an entire system for which GPLed interfaces were required in order to operate (though I would still hope that was enforceable as well). However, I don't think you can say "interoperability" if some proprietary software company wants to link to a GPLed library for talking some network protocol, given that they could just implement the network protocol themselves to interoperate with that protocol. >>>>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 s/preference of/explicit license given by/ > 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. A particular GPLed library does not equate to a large body of separate works with the same interface. If there were many implementations of a particular library interface, an application is not necessarily derived from any of them. > 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. I do agree with this part, since use is not within the scope of copyright. >>>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. Certainly: if Accolade took some (copyrightable) code from Sega, linked it into their games, and shipped them, Sega *should* be able to dictate the terms under which Accolade may ship their games, as a condition of being permitted to ship that code. And if Accolade decides instead to duplicate the functionality of that code without using the code itself (in this case through a reverse-engineering process), they are no longer subject to Sega's whims. > (And before you say it, reverse engineering isn't necessary when the > source code is published, as it is under the GPL. Reverse-engineering isn't; cleanroom engineering is, if you want to be certain you are only copying the ideas and not the specific expression. If I go study the code for something for a while, and then sit down and write a compatible replacement, it's going to be hard to argue that my replacement isn't a derived work. >>>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. Past experience has demonstrated that it is dangerous to speculate about limits on the success of Free Software. We *will* win, the only question is how long it will take. :) >>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 I certainly hope not; that would be a sad day for Free Software. But regardless, speculating on the outcome of that case is not particularly useful, because until that case occurs, the GPL's copyleft applies. Feel free to be the one to test it. > 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 You have argued plenty of times that the FSF's interpretation is not law and does not apply to other copyright holders who use the GPL; why here do you suddenly believe that their interpretation is relevant? >>>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. I didn't argue that, at all. If you make an alternative compatible implementation *without using anything from the GPLed implementation* (which implies some manner of cleanroom analysis and documenation), that's fine. > 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. I don't believe a word of the anti-Eclipse+Kaffe arguments, no matter which JVM came first. There are only two relevant factors in that particular case, both of which argue in favor of Eclipse+Kaffe being OK: that Eclipse runs on a variety of JVMs, all of which provide the same bytecode interface, and that Eclipse is just data being interpreted by an interpreter. As others have stated on this list previously, the status of being a derived work isn't something that changes over time unless the works themselves change; if Eclipse were somehow a derived work of the first JVM (which it isn't), then it would continue to be a derived work of that JVM, even if new JVMs are created. Similarly, an application written based on readline does not magically stop being a derived work of readline when editline is written. > 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. And I think that if Lexmark hadn't tried to use the precise numeric value of the program as a lockout key, they would have won (and rightfully so). >>>>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. Being "not-the-GPL" is certainly notable when an overwhelming majority of Free Software is GPLed. (Justification for that statement: "Make Your Software GPL-Compatible or Else", by David A. Wheeler.) Regardless, even if you don't like the copyleft provisions of the GPL, I see no reason to be *GPL-incompatible* because of that. The LGPL exists for the "weak copyleft" purpose you describe, of protecting the program itself but not things that link to it. Use the 2-clause BSD or the MIT license if you want a complete lack of copyleft and want to allow people to do whatever they want with your code. Use the GPL with an exception clause if you want the copyleft of the GPL but want to permit usage over a particular interface, or otherwise provide a wider set of allowable actions for proprietary software (or GPL-incompatible software). All of these are GPL-compatible. > 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? No one has said that a sea of incompatible licenses is a commons. The intent of the GPL is to create a *GPLed/GPL-compatible* commons. Admittedly, this does not include GPL-incompatible software (which to the GPL, is no different from proprietary software). I see no easy way to avoid this, and all copyleft licenses have basically the same problem. - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature