Re: Illustrating JVM bindings
On Tue, 25 Jan 2005 18:37:03 -0800, Josh Triplett <josh.trip@verizon.net> wrote:
> Michael K. Edwards wrote:
> > Encouraging competitive interoperation is a valid public policy goal,
> > pursued fairly consistently by the courts in the case law that I've
> > read. Of the theories that have been applied to disallow the use of
> > the copyright monopoly to block interoperation, I think situating
> > published interfaces firmly in the realm of the
> > functional-and-therefore-uncopyrightable is easiest to apply
> > consistently and operates at the right stage of analysis. Even the
> > Supreme Court seems to agree, judging from the transcript of oral
> > argument, although they appear to have been split on the question of
> > whether a decision of this scope ought to be left up to Congress.
> > What's murky about this way of thinking?
>
> What's murky is that you are focusing solely on "encouraging competitive
> interoperation", and ignoring the fact that it is quite possible for
> proprietary software to compete with Free Software *without* using Free
> Software in the process. When was the last time you read a case, apart
> from your frequently-cited Lexmark case (which does *not* apply if the
> code in question has any purpose other than as data that is directly
> verified for authentication purposes), in which one competitor was
> actually *distributing* another competitor's product as part of their
> own, building upon that product?
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.
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.
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.
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?
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.
[snip]
> You might keep in mind that redistribution agreements for proprietary
> software components *often* include provisions that address issues other
> than money; for example, redistribution agreements often prohibit
> reverse engineering, prohibit creation of competing products, require
> adherence to some standard, or even require limiting your product to
> only support another product by the same company that provides the
> redistributable component. (For an example of the last of these, see
> the DirectX redistribution agreement, which requires that software using
> DirectX be licensed only to run on Windows.)
This is true, but doesn't explain the dearth of "unauthorized use of a
published API" cases. Anybody can write clauses like that into a
license. Getting a court to enforce them is another matter. As with
the GPL, the mere threat of enforcement usually intimidates the
licensee, especially when she values the vendor's goodwill. Yet even
when both parties are plenty sophisticated and the contract is fully
negotiated and executed, courts take their own tack on license
interpretation (see the Sun v. Microsoft saga for examples); and when
the evidence of "meeting of the minds" is rather weak, ancillary
clauses are frequently tossed.
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?
> >>In this context, the handling of objective c and gcc is probably relevant.
> >
> > Could you expand on this comment? Is there any history of legal
> > activity or discussion there?
>
> Quoting from http://www.gnu.org/philosophy/pragmatic.html:
> > Consider GNU C++. Why do we have a free C++ compiler? Only because
> > the GNU GPL said it had to be free. GNU C++ was developed by an
> > industry consortium, MCC, starting from the GNU C compiler. MCC
> > normally makes its work as proprietary as can be. But they made the
> > C++ front end free software, because the GNU GPL said that was the
> > only way they could release it. The C++ front end included many new
> > files, but since they were meant to be linked with GCC, the GPL did
> > apply to them. The benefit to our community is evident.
> >
> > Consider GNU Objective C. NeXT initially wanted to make this front
> > end proprietary; they proposed to release it as .o files, and let
> > users link them with the rest of GCC, thinking this might be a way
> > around the GPL's requirements. But our lawyer said that this would
> > not evade the requirements, that it was not allowed. And so they made
> > the Objective C front end free software.
>
> (Potential bias of source duly noted.)
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. 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.
[snip]
> > Nothing about the reasoning of Lexmark is hard to translate to a
> > purely software context, and Lotus didn't involve hardware
> > compatibility.
>
> The reasoning of Lexmark does not translate to *any* context in which
> the software has any purpose other than as a string of bytes that must
> contain particular values in order to interoperate. The same precedent
> is well-established in Sega v. Accolade.
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.
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".
> 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.
[snip]
> See http://www.gnu.org/licenses/why-assign.html for the FSF's stated
> reason behind requiring assignment (namely, that they believe they would
> otherwise need to seek out the cooperation of all contributors before
> suing over license breaches). Whether that is legally true or not, it
> is their stated reasoning.
>
> (After the GFDL, though, I'd personally be hesitant to perform such an
> assignment on any code I cared about.)
The strictly logistical concern about there being multiple copyright
holders is a lot less important under current US copyright law, which
conforms to the Berne convention in largely dispensing with
registration-related obstacles to copyright enforcement. But the
stated reasoning is perfectly reasonable, and is one way of forcing
the issue of who gets to call the enforcement shots early in the game.
This also protects the FSF from the awkwardness that might ensue if
another copyright holder were in a position to place alternate
interpretations before the court.
> >>>Arguably, the barriers to adoption of GPL components in commercial
> >>>software projects are in the interest of programmers of limited skill
> >>>and experience, since the usual alternative is in-house Greenspunning,
> >>>which seems to be most of what novice programmers are employed to do.
> >>>They might also be in the interest of the egos of the maintainers of
> >>>some GPL components which would be overdue for a rewrite if
> >>>mission-critical projects depended on them. Everyone else loses out.
> >>
> >>Everone else, with a few million exceptions, sure.
> >
> > I'm not sure what you mean by this. Who are those few million people,
> > and what have they gained?
>
> Among others, the millions of Free Software users who benefit through
> the creation of more Free Software.
Sure, if that's what actually happens, but I consider that far from
proven. What I see is that the communities surrounding most of the
really useful Free Software components have reached a separate peace
with commercial software developers, whether that's a totally non-GPL
license or a fig leaf (a special-purpose escape clause here, an exec()
boundary there) that renders the FSF's stance moot for practical use
cases.
In a world where the FSF doesn't hold the copyright on all free
software -- and hence the unique freedom to copy a best-in-class
implementation from one project to another irrespective of
incompatible fig leaves -- this makes for an ugly mess at both
technical and logistical levels. Do I really have to tell
debian-legal participants this?
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? 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? 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?
Cheers,
- Michael
Reply to: