Re: Illustrating JVM bindings
On Wed, 26 Jan 2005 12:33:35 -0800, Josh Triplett <josh.trip@verizon.net> wrote:
> Michael K. Edwards wrote:
[snip]
> > Of course it is possible for proprietary software to compete with free
> > software without employing GPL components. It's also possible for one
> > commercial spreadsheet to compete with another without providing a
> > compatible menu and macro interface. And it's possible for a software
> > game engine to compete with a hardware game console without providing
> > an emulation capacity for existing games.
>
> The latter two cases are in no way related to the first. In neither of
> the latter two cases did the new competitor's software utilize the old
> software in any way, and no one here is arguing that you cannot write a
> proprietary replacement for GPLed functionality.
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? 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. 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.
> > But just as Lotus customers had already invested in learning menus and
> > creating macros, and Sony PlayStation users had already invested in
> > game titles, many MySQL users (for instance) have invested in
> > developing MySQL-bound applications and the knowledge required to use
> > MySQL well. Had the Progress Software v. MySQL litigation proceeded
> > far enough, I think it is no stretch to argue that MySQL's attempt to
> > use the copyright monopoly to obstruct Progress's efforts to reach
> > their customers would and should have foundered on the rocks of
> > precedent and equity.
>
> 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? 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?
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.
> > The same goes for libraries used in desktop applications. Suppose I
> > trust, say, Intuit to do a competent job on a small business
> > accounting application, and would prefer to run it on GNU/Linux rather
> > than one of those other operating systems. If disallowing them from
> > linking to GPL libraries shared with free applications makes their
> > software needlessly expensive in development cost and memory
> > footprint, then I have a legitimate interest in restrictions on the
> > GPL's reach.
>
> That's the *point* of the GPL: to create a set of software available for
> use by GPLed applications, giving those applications an advantage. If
> GPLed components make it easier to develop Free Software applications
> (which you inaccurately describe above as making it more difficult to
> develop proprietary applications), then that's a good thing for Free
> Software.
<rant>
That may be the point of the GPL in some people's eyes, but it ain't
there in the text, unless you're relying on the afterthought about the
LGPL. The major point of the GPL is to keep free software free. A
Balkanized licensing landscape, with most reusable components under
temporarily neutered version of the GPL or totally unrelated and
sometimes incompatible licenses, doesn't serve that goal. Nor does it
make it easier to develop Free Software applications that work well.
And it certainly does make it more difficult to develop proprietary
applications that can coexist with free software applications on a
GNU/Linux system without massive bloat. I can't even run KMail,
OpenOffice, and Firefox on the same system without getting nailed for
triple the memory footprint (and triple the bugs) in code that
provides 95% identical functionality -- let alone, say, Komodo or
Acrobat Reader.
Sure would be nice to run Nikon Capture (or DXO Raw Engine) on my
Linux box to get a free-as-in-beer (or cheap-for-its-value)
implementation of photo importing, correctly calibrated for my camera
and lens. But it ain't gonna happen, largely because tying to GPL
components is just as big a problem for people who are protecting
sweat-of-the-brow in which none of us really has a legitimate "free
speech" interest as for those who are trying to perpetuate their grasp
on a spreadsheet that doesn't suck.
I used to be pretty damn good at image processing, and would be at
complete liberty to contribute to the GIMP now that I'm out of that
line of business. But I'm not going to get around to it as long as I
can't get the damn thing to build on MacOS and can't get good enough
import results on GNU/Linux. How's that for collateral damage?
</rant>
> I find it difficult to separate your arguments regarding the extent of
> the GPL's copyleft from your apparent opposition to the idea that it is
> desirable for this scope to be as broad as possible.
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. My opinion doesn't
underly my legal analysis, though; it is a consequence of having read
some case law and found that the FSF's attitude stands between us and
a legally defensible modus vivendi that would get the job done.
> I believe this thread has become strongly sidetracked, from a simple
> discussion regarding one of many interpreters for a relatively standard
> language and a program written in that language, into a general attack
> upon the foundations of the GPL. I would suggest that while it is
> beneficial to argue that Eclipse is in no way a derivative work of Kaffe
> (and therefore not subject to the GPL on Kaffe), it is harmful to
> attempt to do so by arguing that the entire foundation of the GPL is
> invalid. There are enough opponents of Free Software who are more than
> willing to attempt such arguments; let us not assist them.
I hate to break it to you, but "opponents of Free Software" don't need
my help to read US case law. I used to think that proponents didn't
either, but my confidence in that belief isn't what it used to be.
Happily, legal precedent supports the validity of 99% of the text of
the GPL and 99% of the ways that people are using it today. It just
doesn't support the FSF's anti-linking stance or their threat of
preliminary injunction under copyright standards without going through
contract analysis first.
If you're suggesting that I'm a stalking-horse for the Forces of
Darkness, you're late to the conversation. ;-)
> If you believe the copyleft in the GPL is weaker than expected, perhaps
> you could provide some constructive suggestions on how to strengthen it.
Sure. Want a pool of code that no one can legally exploit through a
published interface? Don't publish any interfaces. Make sure that
everything is both code and data, that all component boundaries are
mere social conventions, and that no one can tell which bit of code
came from where. The result will look a lot like a Symbolics Lisp
machine, and will be a lot of fun to play with. It will be both a
superior learning environment for the clever but inexperienced and a
superior working environment for those who understand it intimately.
There will be the occasional philistine who just wants a text editor,
but they can always use vi.
Seriously though, "coopetition" across documented interfaces is the
norm these days. The exceptions are on the very low end (embedded OS
+ proprietary application without much need for, or skill at, code
reuse) and the very high end (supercomputer OS + application tuned
over decades to push its performance limits). Why should anyone be
surprised that courts notice and foster this norm in a commercial
setting? Why should Free Software advocates fight it, when it allow
students to learn commercially useful skills on a platform that is
good for their souls, while more and more older pros can combine
contributing at least some of their energy to Free Software with
putting bread on their children's table?
> > I don't think the "distributing a competitor's product" argument
> > should apply either, even if the GPL were to use some non-copyright
> > mechanism to disallow distribution of commercial and free software
> > together. Suppose Connectix had bundled legitimately acquired
> > binaries and licenses to PlayStation games with their emulator. Would
> > that change the logic of Sony v. Connectix? Would a clause in every
> > PlayStation game's license forbidding the use of the game with any
> > non-Sony console do the job?
>
> Connectix created an alternate implementation of the PlayStation
> interface; no one is arguing against that ability.
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?
> > My impression is that the same court system that discourages direct
> > abuse of copyright monopoly frowns on tricksy indirect mechanisms as
> > well. Although I don't have precedents handy, I would expect that
> > rules that clauses forbidding competitive interoperation in licenses
> > are unenforceable, especially in a "standard form" contract with
> > little or no opportunity to assess the consequences and negotiate.
>
> 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". Or check out a case of real copyright misuse;
here's one from the Seventh Circuit: Assessment Technology v. WIREdata
( http://caselaw.findlaw.com/data2/circs/7th/032061p.pdf ). Watch for
a decision in Blizzard v. BnetD (Eighth Circuit), too; there are
several good amici briefs linked from
http://www.eff.org/IP/Emulation/Blizzard_v_bnetd/ .
"Tricksy", however, is not a legal term; it's a Tolkien-ism ("tricksy
hobbitses!") and was meant humorously.
> I see no reason why one should have the right to ignore terms they don't
> like, nor do I see why this should become the case if they did not have
> the opportunity to negotiate alternative terms that they would prefer.
> If you don't like the license, find another piece of software.
It's not "terms they don't like", it's "terms that try to use contract
law to abuse the copyright monopoly in a way that would not be
permitted under copyright law alone."
[snip]
> Back to your message:
> > As for the DirectX example, when was the last time Microsoft resorted
> > to mere lawsuits to obtain compliance with its strategic imperatives?
> > Those clauses get the message across: accept lock-in or we will
> > destroy you. Do you really approve of similar tactics in the name of
> > software freedom?
>
> Free Software (as a whole) is not equivalent to Microsoft (a single
> organization). Free Software "winning" would not create a monopoly or
> establish control over users and developers. And Free Software is not a
> lock-in, as you are quite capable of using and/or developing competing
> software. Regardless, I was not equating the terms in question, only
> stating that there exist other cases where in order to distribute the
> software to which API you are writing, you must follow certain conditions.
This is not about Free Software "winning", and it doesn't have to be a
zero-sum game. Think of the professional / amateur distinction in
other fields, such as athletics and photography. "Amateur" in this
sense isn't a term of disrespect; it means that one does it because
one loves it. Amateurs benefit from the existence of professionals in
their field, but they also have to live by rules that are designed so
that the pros can make a living.
Like most Free Software contributors over 30, I have an "amateur"
software developer hat and a "professional" developer hat. Wearing my
amateur hat, I want to do novel things in novel ways whether there's a
market for them or not. Wearing my professional hat, I want there to
be a reasonably secure mechanism for a business I run, or an employer
who hires me, to recoup their investment in my beer and skittles.
Like a pro basketballer who's an amateur baseballer, or a pro portrait
photographer who's an amateur at landscapes, I don't want to have to
change my operating system, my camera, or my jockey shorts depending
on which hat I'm wearing at the time.
Let's continue the parallel to DirectX. You're capable of developing
a competing, non-interoperable gaming framework. There won't be any
games for it on initial release, and all of the commercial game
publishers will be bound by contracts and extortion not to create any,
and you won't have a prayer of getting it to run on an X-box, but
these considerations only affect your prospects of filthy lucre, and
who cares about that? Courts do. I would look to a court for relief
if Microsoft came down on me for cloning DirectX, and I'd cite all the
same precedents. The court's overriding priority is to interpret the
rules so that no one who plays fairly is forced out of the game by
unjust legal means. Hence it is, if anything, less likely to ratify
an interface monopoly on communitarian principle than on commercial
grounds.
[snip]
> > Note also the absence of actual legal proceedings. It is also worth
> > noting that the GCC front end / back end interface is somewhat fluid,
> > unusually complex, and not intended for arm's length use.
>
> You seem to be acknowledging here that there exist interfaces for which
> your rejection of the GPL's copyleft does not apply. That seems promising.
I'm saying that conceptual boundaries, like "front end / back end",
within an integral work like the GCC suite, don't automatically
constitute published functional interfaces. Ever tried to make last
year's front end work with this year's back end? The separation
between, say, the C preprocessor and the compiler is a different
story, even if its "interface" is equally complex.
> To be honest, my primary objection to your logic regarding APIs is that
> I see no real difference from a copyright perspective between a
> "published" API and the functions provided by the guts of a program, the
> latter of which could just as easily be considered an API. There are
> library APIs which are fluid and complex, and there are program
> internals which are rock-solid and rarely change. I don't believe
> "published API" can be used as an automatic boundary for the GPL's
> copyleft, any more than linking can be used as an automatic extension of
> the GPL's copyleft, or than exec() can be used as a boundary.
Automatic? No. Coders, and courts, still have to make judgment
calls. But courts do not shrink from tests that take a lot more work
to apply, such as the Altai "abstraction-filtration-comparison" test,
which is now the law of the land in the US and Canada. Even "I know
it when I see it" can be good law at times.
> > And
> > irrespective of legalities, there are few factual settings in which
> > proceeding in the face of hostility from the maintainers of the
> > interlocked component would be greater folly than in the case of an
> > optimizing compiler.
>
> Granted; in this respect, the GPL seems to have done its job, whether it
> was enforcable or not.
The GPL doesn't appear to me to have had anything to do with the
outcome, except as an agreement among the GCC contributors about what
they were willing to support and tolerate. That usage, however, is
very important; and I think it's good to check in from time to time
about its interpretation. More and more projects seem to want the
"linking-friendly GPL" model, and the GPL text and case law seem to me
to support that model without the need for special exemptions. I'm
willing to stand up and be counted among those who think the GCC case
is the exception rather than the rule and it would be wiser for the
FSF to acknowledge this and move on.
[snip]
> > Similar conclusion, mostly different logic. Sega v. Accolade ruled
> > that the reverse engineering process was permitted as "fair use"
> > although the activities it entailed would otherwise have constituted
> > infringement. This is a sensible mechanism by which to limit abuse of
> > the copyright monopoly to block access to the ideas contained in a
> > work that is distributed in a form ordinarily interpreted only by a
> > machine, and is the main legal idea for which Sega is cited as
> > authority in later cases.
>
> Of course; ideas are not copyrightable, and this case would be
> reasonable precedent for arguing that you should be able to create a
> proprietary reimplementation of the ideas in a GPLed work, even through
> cleanroom analysis of that GPLed work. Accolade did not distribute any
> of Sega's copyrightable material.
Cleanroom, shmeanroom. That's for unpublished material. Read, learn,
use, just don't plagiarize.
> > To the extent that Sega also applies a theory of uncopyrightability of
> > purely functional elements to legitimize copying of the Genesis
> > "unlock code", it cites Computer Associates v. Altai as authority for
> > doing so. The Sega court's paraphrase of Altai states that functional
> > elements may be dictated "by external factors such as compatibility
> > requirements and industry demands." Lotus and Lexmark go well beyond
> > Sega in stating the public policy rationale and the beginnings of a
> > litmus test for finding the elements dictated by compatibility
> > requirements and declaring them to be uncopyrightable. These criteria
> > translate quite well to contexts other than hardware "unlock codes".
>
> In the Sega v. Accolade case, it was decided that there was no method
> for interfacing with the Sega hardware other than copying that exact
> sequence of code, though Sega tried to argue otherwise by using their
> internal knowledge to work around it. Furthermore, the code segment in
> question was short, and would need to be (AFAICT) identical in order to
> pass the check. As with the Lexmark case, you just can't say "if you
> don't provide '42' to our system it will lock you out, and you can't
> provide '42' without our permission", because you have no exclusive
> rights to '42'. You might note that there have been other such systems,
> such as Nintendo's 10NES system, in which the code required to
> circumvent the lockout was considered expressive because it need not
> have been identical.
Agreed. But as I have repeated ad nauseam elsewhere, I am not arguing
that the body of a library is uncopyrightable; I am arguing that
distributing the library under GPL terms alongside a closed-source
application that uses it is perfectly legitimate.
> >>Now, if you wanted to use Lexmark v. Static Control or Sega v. Accolade
> >>in the context of AIM servers previously requiring authentication in the
> >>form of pieces of the AIM binary, then it applies perfectly there.
> >
> > To argue that, I think you'd need more than a footnote in Sega. You
> > need the more sweeping rationale in Lotus and Lexmark, and a court
> > that is willing to proceed on that rationale without the "de minimis"
> > crutch. It would also take you off in the direction of punishing
> > deliberate attempts to abuse the copyright monopoly -- alluded to in
> > Lexmark, but not essential to its logic -- which is somewhat different
> > from clarifying the ground rules for building atop software
> > components.
>
> The issue of the functional nature of the TMSS initialization code was
> far more than a footnote. Furthermore, I wish you'd stop using terms
> like "abuse the copyright monopoly"; the issue at hand is the current
> extent of copyright and of the GPL, not whether we approve of any
> particular use of it. Terms like you are using are perfectly
> appropriate when arguing to reduce the scope of copyright, and I would
> gladly support most such efforts. However, the point of this discussion
> is simply to discuss the current scope of the GPL. If you want to
> *change* that scope, this is not the appropriate forum.
The bulk of the Sega decision is about claims of copyright
infringement during the reverse engineering process. The bit about
unlock codes is in a footnote, which begins: "We therefore reject
Sega's belated suggestion that Accolade's incorporation of the code
which 'unlocks' the Genesis III console is not a fair use." It only
briefly addresses Atari v. Nintendo to forestall a claim of
inconsistency and leans heavily on "de minimis".
As for the appropriateness of the forum, I am talking about the
current scope of the GPL under applicable law. My analysis differs
from the FSF's assertions on a couple of major points. This bears on
topics that I didn't start, including the origins of this thread.
Perhaps the Subject: line is no longer quite accurate; feel free to
change it. I don't mean to be anyone's spam, though; "follow-up to
private e-mail" is always a reasonable thing to request. Is that what
you're requesting?
> > What is so great about having nineteen different debugging mallocs,
> > and having to puzzle over their licenses before risking copying a
> > technique from one to another?
>
> I certainly hope you aren't complaining about the first half of that;
> the wide variety of available software is highly desirable, as well as
> unavoidable in the sense that you don't dictate what people work on.
You're quite right, tool diversity is a good thing. Nor should any
developer of a new tool feel obliged to build a superset of existing
tools before doing their new thing. That's one reason why license
compatibility at the code fragment level is extremely important, even
under an interpretation where linking is OK; someone who cares about
having the superset in one tool can do the work of riffle shuffling.
> 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.
> > What is so great about the FSF and ASF
> > both insisting on copyright assignment before code can be contributed,
> > so the only way to share code between GNU and Apache projects is to
> > put it in the public domain?
>
> That's not a licensing issue, just a policy decision of two different
> organizations; take it up with the FSF and/or ASF.
It most certainly is a licensing issue. The ASF requires this not
least because they can't reuse any code that has appeared previously
in a GPL context without a serious audit trail back to explicit
release into the public domain by the original copyright holder.
Anything previously assigned to the FSF isn't available to them.
They're willing to bend over backwards to make their license
compatible with the GPL anyway. Other license authors are not so
generous, and retaliate with GPL-incompatible clauses in order to make
their work unavailable for inclusion in GPL projects. This is
freedom?
> > And what is so great about raising the
> > barriers to porting commercial applications onto GNU/Linux so that we
> > get nine different half-assed free-software Excel clones instead of a
> > Lotus 1-2-3 port that actually works well enough to fill out and send
> > in an expense report?
>
> As a -legal participant and as someone generally concerned with nitpicky
> details (I don't mean that as a bad thing), you should know not to
> equate "commercial" with "proprietary".
Generally I don't. In this context I really do mean "commercial"; it
may well not stay proprietary in the process of porting, or the
proprietary portion may be minimized (as in the network management
example I gave). But if it overlaps with something else that isn't
ready to be open-sourced in its entirety (think of SGI's XFS port to
Linux, which had to be very carefully separated from encumbered code),
then the GPL isn't going to be a prudent choice as long as the
agent-provocateur scenario is plausible.
> Furthermore, nothing stops proprietary software vendors from building
> their software on top of glibc, the kernel, or other required pieces of
> software, so porting is certainly possible; is it so monumentally hard
> to avoid building upon GPLed components?
No, it's just monumentally stupid for all of the required components
to contain latent booby-traps. If some distro's glibc maintainer
copies in a bit of code from GNU readline, or if some major kernel
contributor decides that the syscall boundary isn't GPL-proof after
all, then either the FSF backs down in public or most of us can kiss
the use of GNU/Linux in our day jobs goodbye. Maybe that would suit
you just fine, but if so, I fervently hope that you are in a minority.
> I would also point out that there are many (myself included) who
> couldn't care less about proprietary applications on GNU/Linux, but
> benefit from any Free Software generated as a result of the GPL. From
> my perspective, if the GPL somehow stopped a thousand proprietary
> applications from supporting GNU/Linux (which seems highly unlikely),
> and caused a single application or other component become Free Software,
> I would generally consider that a net win.
>
> (Note, of course, that it is theoretically possible to fill in the
> blanks to make that statement not true; for example, if one of the
> proprietary applications would lead to millions of additional users of
> Free Software, then there could be a non-zero benefit to Free Software
> of having that application available.)
On the planet on which I live, Free Software has millions of users
because it can be used with free but non-GPL components such as the
OpenSSL transport, the Apache webserver, the Netscape/Mozilla family
of browsers, and implementations (free and otherwise) of the Java
language. These components can in turn be used for commercial --
sometimes even proprietary -- purposes. None of these things would
exist in their current form without seed contributions by, and ongoing
support from, government and commercial users for whom the GPL is only
tolerable in a "weakened-virus" form. Despise them if you like, but
it is the merest decency to acknowledge your debt to them.
Cheers,
- Michael
Reply to: