Re: Illustrating JVM bindings
On Thu, 27 Jan 2005 18:00:03 -0500, Raul Miller <firstname.lastname@example.org> 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
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
(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
> > 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
> > > 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?
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?