Re: Illustrating JVM bindings
On Fri, 21 Jan 2005 14:02:28 -0500, Raul Miller <email@example.com> wrote:
> On Thu, Jan 20, 2005 at 08:51:46PM -0800, Michael K. Edwards wrote:
> > ... So I'll use "program exclusive of
> > the library", or PEOTL, instead.
> Except I'm holding that this kind of distinction is meaningless in the
> general case. To meaningfully dicuss this kind of things, you'll have
> to nail down other details. Intent matters, other activities matter, etc.
I'm focusing on a simple case. Pre-existing GPL library, shipped
unaltered, or with any bug fixes and enhancements contributed
upstream. New application ("PEOTL") written to use the library.
Tested and shipped together, with no tricksy business to pretend that
the application isn't dependent in an engineering sense on the
library. Intent: to exploit the market for the application, and to
save on engineering cost by not reinventing the wheel contained in the
Simple legal question: can a GPL library author use the copyright
monopoly to ban the vendor from writing, or the end user from running,
a closed-source application that uses the library through its
published interface? Equally simple ethical question: does releasing
code under the GPL create a commons or a commune? Can one choose to
share of and share in a pool of competent solutions to well-understood
programming problems, without abandoning conventional mechanisms for
recouping capital investment in novel creations?
> > 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.
> I think this falls under fair use. The program in the printer cartridge
> was tiny, and if Lexmark really wanted copyright protection on that
> program, they shot themselves in the foot by making its checksum a
> functional issue.
The interesting part of the ruling, to me, was that the court didn't
use a "fair use" theory to reach the conclusion they did. The problem
with "fair use" is precisely that it depends on the circumstances and
intention of the use; it's an affirmative defense of the behavior, not
a property of the material being used. So it's pretty easy for a
copyright holder to get a fresh hearing in court based on a new
incident of use of the same material.
The Lexmark court, like the Lotus court, ruled instead that, when
prima facie copyrightable material is actually necessary for
functional interoperability, it loses eligibility for copyright
protection. If this precedent holds, we can stop counting the angels
dancing atop an exec() boundary.
Irrespective of language details, the published, documented interface
to a software component invites both application usage and alternate
implementation. To deny the exercise of copyright monopoly to block
these uses is good public policy and the sort of "bright line"
distinction that courts like to find when they can. Copyright isn't
the ideal form of property right in software, but it is suitable for
protecting the body of expression in a program, as with any other work
of authorship. Other mechanisms are available to protect truly
original (patentable) or truly proprietary (unpublished and held as
trade secret) interfaces.
> > 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?
> I think that the court will be looking at who is being harmed, as well as
> how and why. They will attempt to distinguish between "working around the
> license" and "working within the license" based on questions of intent,
> and consequences.
Not if they follow the Lexmark precedent, which denies copyright to
details that are required for technical interoperability, irrespective
of the defendant's intent. Although not all legal regimes place such
a premium on enabling competition, I would expect most European
jurisdictions to err on the side of discouraging software monopolies
where this is justifiable.
> In other words, in each area of conflict, the court will be looking at
> questions like "what would likely happen if this were different"? And,
> in doing so, will try to find a way of looking at the conflict which
> minimizes confusion and in some way maximizes each party's control over
> their own domain.
I agree with all of this except for the last assertion. Courts do not
look to maximize a rights holder's control over territory that he
claims for himself. They try to apply statute and precedent
consistently to find the limits of a legally defined exclusive right,
and then assess the other party's claim that this right was not
> > 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.
> I read your last sentence there as saying, among other things: If someone
> holds an opinion of the GPL that they dislike, that's not good for anyone.
That's not what I meant; I wasn't talking about opinions about the
GPL. Correctly or not, I understood you to have said that having
studied a GPL library's internals weakens one's case for being
justified in writing a non-GPL application that uses it. Copyright
doesn't and shouldn't work that way. I feel strongly that the ideas
and techniques embodied in published code are available for anyone to
study, learn from, and apply anywhere. The idea that clean-room
techniques of reverse engineering are appropriate when dealing with
code offered under the GPL, in order to protect oneself from an
accusation of "infringement through understanding", is repulsive to
Clean-room techniqes defend against accusations of theft of trade
secrets, and nothing offered under the GPL can possibly be a trade
secret, since it is openly published. And whatever you may think of
software patents, at least the test of infringement is whether the
patented technique is being used, not how it was learned.
> Personally, I don't think that opinions are that big of a deal. If
> those opinions are opinions which make sense to me about something
> I think matters, that's a different story. But in the general case
> opinions aren't the issue.
Right. Nor do I think that opinion should be the only guide for
policy. The reasoning behind people's opinions often says more about
the basis for consensus than the opinion statistics themselves.