Re: Illustrating JVM bindings
On Tue, 25 Jan 2005 19:11:27 -0500, Raul Miller <moth@debian.org> wrote:
[snip]
> You think the "bright line" which has yet to be drawn is not far from
> the theory articulated in lotus an lexmark? That's... a fairly murky
> way of thinking...
I think that a "bright line" could be drawn substantially at the
boundary between public interface and implementation internals, as the
cited cases did in the case of menus and macro languages (Lotus) and
pluggable hardware components (Lexmark). The definition of
"interface" is going to vary from language to language, but that's
what expert witnesses are for. In many cases, industry practice is so
well understood that there isn't much room for those expert witnesses
to disagree anyway.
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?
> > There doesn't seem to be much case law in which a court has been asked
> > to apply sanctions against "unauthorized use of a published API" under
> > a copyright theory.
>
> Right, because people generally pay attention to the license on the
> components they'll be building on and don't bother to make an investment
> in any area where they're likely to have problems.
There's some truth to this; but I think it's a bigger factor that most
software component business models fall squarely into either the
unpublished camp (with access only granted by negotiated contract) or
the no-fee-to-redistribute camp (with revenues based on toolchain
sales, technical support, and sometimes end-user purchase of hardware
and/or software platforms). Both models provide more practical ways
of pursuing freeloaders than prosecution for copyright infringement.
The GPL, as interpreted by the FSF, is unique in going after
commercial users' intellectual property rather than their cash.
> 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?
> > The various cases I have cited are mostly competitive situations
> > (creation of interoperable substitutes), and older precedents on
> > interface usage from the telecom industry usually hinge on contract
> > terms and trade secret status rather than on copyrightability.
>
> Agreed.
>
> > Personally, I think that the FSF is swimming upriver when it claims
> > that any of the steps involved in implementing and linking against a
> > library creates a derivative work.
>
> You're swimming up the same river when you claim that a binary is a
> derivative work of the source.
I don't think so. Courts have ruled that the expressive content in
the binary is substantially the same as that in (the non-comment
portions of) the source code. The fact that the translation can be
somewhat lossy doesn't bother them. There's nothing in the
source/binary scenario equivalent to the separation between library
and PEOTL that can be achieved by denying copyright protection to
their interface. Unless, that is, you're concerned that a binary may
be a derivative work of the compiler as well; the bright line may be
harder to draw there (consider the continuum from an x86 assembler to
a C compiler to a Python bytecode compiler + runtime to a compiler for
a "little language" implemented entirely in Lisp). That's a job for
explicit language in the compiler license.
> > As far as I can see, this attitude goes against the legal trend in
> > the US and in any other jurisdiction which looks to the US judiciary
> > for reasoned analysis of the public policy issues.
>
> For contexts where the treatment of copyrighted material is an obstruction
> to hardware compatability, sure.
Nothing about the reasoning of Lexmark is hard to translate to a
purely software context, and Lotus didn't involve hardware
compatibility.
> > Moreover, together with the FSF's bizarre insistence on a "non-contract
> > license" interpretation of the legal basis for the GPL, it discourages
> > established software players from publishing mature software components
> > under the GPL, since they fear that allowing a patch from a competitor
> > to leak into the GPL component will provide a lever with which to open
> > up their entire code base or to obtain crippling injunctions under
> > the generous copyright standard.
>
> The FSF apparently has some analogous fear. Last time I checked, they
> insisted that they be given copyright on code before they accept it into
> their code base.
I think that has more to do with freedom to tweak the licensing terms
without relying on the dubious "version 2 or later" clause than with
fear of competitive leverage.
> > 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?
Cheers,
- Michael
Reply to: