Re: Illustrating JVM bindings
On Wed, Jan 26, 2005 at 01:14:05AM -0800, Michael K. Edwards wrote:
> 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.
And many more users have invested invested in learning how to use windows
and microsoft office.
But that's largely irrelevant to the case you're citing here. At least,
the way I read it, the progress softare v. mysql case didn't get a
preliminary injunction because the two parties had largely settled their
differences by the time the case had arrived in court.
> 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.
I can see that this could limit the scope of contributory infringement.
I think it's unlikely that this could limit the scope of direct
infringement.
> This is true, but doesn't explain the dearth of "unauthorized use of a
> published API" cases.
It's probably worth noting that there aren't many "unauthorized use of
an unpublished API" cases, either. This is despite anti-reverse
engineering clauses in the licences.
Of course, those cases which do exist tend not to involve distributing
copies of the licensed materials behind the API.
Also, the DMCA has somewhat changed the focus of these kinds of court
actions.
> 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
> 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?
That's not really the question for us, here.
As a general rule, we try to not have an adversarial relationship with
software authors, if they're upstream of us. It's just not worth it.
If someone asks us to not distribute software, even if we're technically
licensed to distribute it and even if it seems the license is DFSG
compatible, we're likely (though not guaranteed) to stop distributing it.
We don't always have working relationships of this quality with authors
of works we don't distribute, but that's probably less important.
And, for the most part, we don't try to exert control over what other
distributors do. We make our choices, not their choices.
[objective c and gcc]
> Note also the absence of actual legal proceedings.
I noted that when I introduced the issue.
> 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.
Yeah, I think intent matters, too.
> 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.
I can think of many other examples. Software tends to get rather complex,
rather quickly.
In any event, NeXT shippd the specific gcc version they needed, so
version drift wasn't a practical concern at the time.
> 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.
Yeah, if you buy a book you're allowed to read it, too. In general, once
you have legally obtained a copy of a program you're allowed to use it,
[In other words: I have no disagreement with your reasoning, here.]
> 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.
But none of these cases involve copying of the original and copyrighted
material which came with that purely functional content.
You keep ignoring this issue, which is why I keep bringing it up.
> > 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.
Intent matters, the specifics of the case matter.
> 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?
This ugly mess is the primary design goal of copyright law. At least,
in the U.S.
--
Raul
Reply to: