On Tue, May 20, 2003 at 01:49:03PM -0500, Steve Langasek wrote: > > > I think it's an interesting case to consider because of the question of > > > whether an interface is copyrightable, but I think that discussion is > > > best left for another thread. In any case, I believe the "generic > > > interface" defense is only applicable when the distributor is not > > > distributing a combination that requires selecting one specific > > > implementation as the default. > > > I am not sure the U.S. courts agree.[1][2] > > I don't see how the cases you cite conflict with what I said. In both > of the cases, IIRC, the courts found in favor of someone who duplicated > a competitor's interface. This seems to support (API vs. user interface > question aside) the notion that the generic interface defense *is* > applicable when you aren't distributing someone else's copyrighted > implementation of the generic interface. However, it does not establish > a precedent for the case where you *are* distributing the plaintiff's > copyrighted work which provides a given interface. Apple v. Microsoft > doesn't mean Microsoft could claim MacOS no longer enjoys copyright > protection just because someone cloned the UI. Uh, I see I rebutted the very point you wanted to leave to another thread. Sorry. :) I am not sure I agree that a generic interface defense suddenly becomes unavailable simply due to what a distributor fails to distribute. In my view, either an interface is generic or it is not. It seems wrong to me that we can take a free, but GPL-incompatible application out of Debian main and hand it to two software distributors. Each distributor grabs a different ABI-compatible implementation of a shared library (upon which this app depends) out of Debian main. One of those happens to be GPLed and the other does not (it's, say, under the MIT/X11 license), but the distributors just flip a coin to decide which one they ship. Under your analysis, one of these guys is in deep shit with the copyright holder of the GPLed implementation of the shared library, and the other guy is not. It's just a bellyfeel, but it's a strong one. What the Debian Project distributes should not be subjecting people to this sort of risk. I think one should be able to distribute arbitrary subsets of the Debian OS in pretty much total ignorance of the licensing on the software within. If they modify stuff, that's a different story. > > > > Because the two libraries are interface-compatible, the FSF is not in a > > > > position to forbid people from distributing code that "links" against > > > > libreadline if that code is not licensed GPL-compatibly, because the > > > > code could be linked against libeditline instead.[1] > > > > Yes, but they are in a position to forbid distributing such code > > > together with readline itself. > > > I hate to say this because I love my bright-line tests, but I think > > intent matters here. Shipping "such code together with readline > > itself", and nothing else, should be distinguishable from what Debian > > does, which is ship "such code", "readline itself", a clone or two of > > readline, and a whole boatload of other stuff that has nothing to do > > with any of the above. > > I think references to the file name of the GPL'ed library in an > application's ELF header constitute pretty damning evidence of the real > intent. "Your honor, the plaintiff's license is non-binding because I > could have used editline instead" doesn't sound like much of a defense > to me. If that's the case with readline vs. editline -- I can't be assed to check, then you're right. But does your analysis change at all if libeditline ships, say, its own /lib/libreadline.so.4? I mean, this is exactly the point of ABI compatibility. Just look at the LessTif project. -- G. Branden Robinson | If God had intended for man to go Debian GNU/Linux | about naked, we would have been branden@debian.org | born that way. http://people.debian.org/~branden/ |
Attachment:
pgpDVTWkPtpS5.pgp
Description: PGP signature