Re: Illustrating JVM bindings
On Tue, 25 Jan 2005 21:49:00 -0500, Raul Miller <moth@debian.org> wrote:
[snip]
> The cited cases were cases where copyright was held to not exist on the
> materials in question because they were functional materials instead of
> copyrightable materials.
>
> For cases where the interface definition is not protected by copyright,
> I'd agree with you. However, I doubt that this could be generalized to
> "all public interfaces".
Why not? Doesn't the chain of reasoning, from Computer Associates to
Lotus to Lexmark, apply just as well to any other published interface?
It's not that these plaintiffs weren't trying to copyright their
interfaces, it's that the courts ruled that the necessity of
duplicating them in order to interoperate warrants their exclusion
from the portion of the work that is considered copyrightable
expression.
> > 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.
>
> In lotus, the functional aspects of the interface were copied, but
> nothing else was. In lexmark, the same thing holds.
>
> Where the library itself is copyrighted under the same copyright as the
> interface, you have a different situation, with respect to copyright.
> It's not just the interface which is being copied, but the entire library.
To copy the entire library, you of course need license to do so. The
GPL spells out the terms of that license. The GPL proclaims that the
scope of the material for which license is needed is determined by
copyright law. Copyright law, as interpreted by courts, appears to
deny monopoly protection to published interfaces when they must be
used in order to interoperate successfully, even when that
interoperation is against their creator's interests. Ergo, the use by
a commercial application of the published interface of a GPL library
does not infringe copyright, does not trigger rescission of rights
under the GPL, and does not justify restrictions on the distribution
or use of the application together with the GPL library.
It is of course possible that a court won't go so far as to rule that
a given published interface isn't copyrightable. But supposing that
this generalization does hold, what grounds do you find in the GPL for
retaliating against the commercial application vendor by denying it or
its customers license to the library?
> As an aside, "industry standard practice" as far as libraries go tends
> to fall into one of two categories:
>
> [a] The libraries are freely redistributable to everyone, with no
> restrictions whatsoever, or
>
> [b] The libraries are very heavily restricted with extremely high costs
> associated with each copy.
>
> The GPL doesn't precisely fit into either of those categories, and I
> don't see any reason why either form of industry practice should take
> precedence.
I referenced "industry practice" to suggest a likely source of
consensus about what constitutes an interface definition in any given
technical context (header files for C libraries, interface definitions
extractable from class files for Java, etc.). I agree that there is
no single industry licensing practice, although I think there are many
more business models than you name. I mentioned a couple of licensing
models elsewhere to explain the apparent infrequency of
copyright-based lawsuits hinging on interoperation by usage instead of
substitution, but I agree that the commercial models have little
bearing on how the GPL should be interpreted.
> > Encouraging competitive interoperation is a valid public policy goal,
> > pursued fairly consistently by the courts in the case law that I've
> > read.
>
> If the courts hold that all libraries are purely functional, despite
> their licensing terms, that could indeed be seen to satisfy a valid
> public policy goal. I don't think that's going to happen, however.
Hopefully it is clear by now that I think that:
the bulk of a library is usually copyrightable;
its published interface is arguably uncopyrightable according to
US case law;
permission to distribute it depends on the terms of its license;
US courts are somewhat unlikely to enforce anticompetitive
constraints in standard-form licenses; and
anticompetitive constraints in the GPL are in any case limited by
its language to the scope protectable by copyright?
> > 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.
>
> And I think that for cases where that's all that's being copied,
> that it's likely that the courts would agree with you.
>
> However, I don't think that you can argue that this is a relevant
> precedent when the entire library is being copied.
It's relevant when the validity of the application vendor's license to
copy and redistribute the library under the GPL hinges on whether his
conduct in writing the application infringes copyright and therefore
justifies rescission of his rights under the GPL.
> > What's murky about this way of thinking?
>
> The implications. And, thus, the semantics.
Do you still think it's murky after clearing up the distinction
between copyrightability of libraries and of their interfaces?
[snip]
> http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html
Interesting article. I also liked his analysis of the economics of
open source (and related software trends) at
http://www.joelonsoftware.com/articles/StrategyLetterV.html -- except
that software has a way of not staying commoditized, since the skills
and attitudes that make a good programmer on the small scale are
almost completely antithetical to those needed for effective
system-wide software reuse. This helps explain Sun's strategy, I
think; business logic tends to grow hair and consume a lot of
resources, most businesses can't afford the depth of analysis required
to distribute a complex application across commodity hardware, and
both Java on Windows and Linux on desktops can serve as training
wheels for Sun's big iron.
> > 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.
>
> It's unique in its price range, but it's hardly unique in its terms.
> Have you ever looked at some of the older AT&T Unix source licenses?
OK, "unique" was an overstatement. But the FSF has an axe to grind
that discomfits many decent people who would otherwise be willing to
share in the maintenance and expansion of the commons. AT&T's
attitude back in the day is an interesting parallel, given that it
helped contribute to the decline of the original Unix commons.
> > > 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?
>
> There's a paragraph at
> http://www.free-soft.org/literature/papers/gnu/pragmatic.html
> which mentions this issue.
>
> The NeXT is pretty much ancient history, at this point, but I'm sure
> that if you search around enough you'll be able to find more specifics.
Have you read anything about it other than RMS's summary? Is there
any reason to think that NeXT or MCC didn't just decide that fighting
the GCC team wasn't prudent?
[snip]
> Or... are you trying to claim that a copyright license may not make
> non-copyright requirements? For example, would you say a license
> which requires the payment of money is invalid, since money is not
> copyrightable?
As I never seem to tire of repeating, a copyright license is a term in
a contract and may be exchanged for any other legally valid promise.
But the text of the GPL as written almost fetishizes the bounds of
copyright in an attempt to persuade the reader that it is a pure
artifact of copyright law. It's not so much that it can't attempt to
fight on other turf, it's that it doesn't choose to.
I don't think a court would be impressed by attempts to turn around
and say: "Well, maybe we can't reach across a published interface
using copyright after all. In that case, we demand that you read
'mere aggregation' more narrowly than a copyright context would
suggest in order to let us rescind the license when there is, not
copyright infringement, but an engineering relationship of which we
don't approve."
> > 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.
>
> I think you're confusing the requirements imposed by terms of the GPL
> with the issue of what is protected by those terms.
No, I'm pointing out that the "bright line" between interface and
implementation inevitably gets fuzzy when one is looking not at
libraries but at languages and toolchains, and therefore toolchain
licenses should be fairly explicit about the ground rules for the use
of their output. I don't consider this counterexample fatal to the
assertion that the bounds of a published functional interface are
usually easily established by recourse to expert witnesses.
[snip]
> > Nothing about the reasoning of Lexmark is hard to translate to a
> > purely software context, and Lotus didn't involve hardware
> > compatibility.
>
> The Lotus case only involved copying of non-copyrighted material.
> Same holds for the Lexmark case.
That material was held to be non-copyrighted only because the courts
declared it non-copyrightable in the face of the plaintiffs' protests.
[snip]
> > I'm not sure what you mean by this. Who are those few million people,
> > and what have they gained?
>
> Exceptions include:
>
> * Users of the GPLed software,
What users of GPLed software have benefited by disallowing the use of
GPLed libraries from non-GPL code? Set the Objective C and C++ cases
aside -- they aren't arm's-length uses of a stable interface, and I
suspect that NeXT and MCC capitulated more because butting heads with
the GCC maintainers was stupid than because someone said it was
illegal. Does this argument rest on the claim that some nameless
author of a nameless application couldn't be bothered to switch from
GNU readline to a similar chunk out of the Perl or Python code base?
> * Developers of GPLed software who are not involved in commercial projects
> (education and government are two significant examples).
If they are not commercially motivated, what skin is it off their nose
if there is a commercial alternative that also uses GPL components?
How do they benefit from the lack of commercial involvement in the
maintenance of the components on which they depend?
> * Developers of software who update the GPLed software either tangentially
> (they use GPLed tools, which they might enhance, but they get paid for
> something else) or complementary (superficially, the same, but increased
> distribution of the GPLed software increases the financial viability of
> their business).
Again, what do they gain from the linking ban? No one is arguing that
it's OK not to release the source code for derivative works.
> For example, many ommercial software projects use linux. In some cases
> they've gained a development platform. In other cases they've gained
> a deployment platform. In some cases (beowulf based rendering studios,
> maybe), they've might have gained access to a system qualitatively more
> powerful than what they'd be able to buy under the standard commercial
> model.
Right. But if any of these use cases ran into the GPL linking ban,
they'd be out of luck. As it is, they rely on Linus's perpetuation of
the syscall fudge and on a belief that the exemptions in the glibc,
gcc, and binutils licenses effectively protect them from the FSF.
> Or, take my brother-in-law. He's a biophysicist who uses the linux real
> time kernel in his work. I talked him into using it after he'd spent a
> couple years using microsoft device drivers in the same basic context,
> and was stymed by some of the issues of that environment. He literally
> gained the ability to do research that he was unable to perform before
> he made the switch.
What does he gain from the linking ban?
> I think you were trying to limit the universe of consideration to
> "commercial projects which make their money off the sale of software
> which would incorporate GPLed components if they could figure out how
> to make money off of it". My contention is that this is a relatively
> narrow slice of commercial projects, and of the use of GPLed software.
Not at all. I'm trying to expand the universe of consideration to
"lots of free software which would probably be licensed under the GPL
if it weren't for the FSF's attitude about linking". Just to take an
example: the main problem with OpenSSL and Gnu TLS isn't that one's
sort of GPL-incompatible and pieces of the other are under three
different licenses, it's that neither one is all that good. I don't
mean to cast aspersions on the authors or maintainers here; both
projects are a darn sight better than nothing, and I'm grateful; but
they have nightmare interfaces and annoying implementation gaps, and
doing much better would take significant investment.
Suppose one could remove the barriers to merging good bits from all
over the commons, retain the obligation to release the result under
the GPL, but permit its use from a commercial application that sells
on its other strengths. That might make it worth someone's while to
do a really good job of analysis and refactoring. And in the process
they might clean out their closet and toss lots of good bits into the
commons that they don't consider to be core competencies but might
want to reuse later.
> You might also be trying to make the point that the "keep the software
> in-house" model doesn't contribute anything to the generally available
> body of work. But in a very similar sense, the "distribute the software
> under a proprietary license" doesn't advance the generally available
> body of work. So in that respect, as well, I think you're probably
> trying for a rather insignificant benefit.
Here's a concrete counterexample. One project in which I am involved
at the day job is a network management console specialized to my
employer's hardware. It's no secret that it incorporates a bunch of
non-GPL open source components. Certain other parts of it don't
really have any proprietary value, just cumulative "sweat of the brow"
to fill out a feature set; they're overdue for refactoring, or maybe a
rip-and-replace, and it would be nice to share the burden with others
who need a similar framework. Hardware-specific bits, on the other
hand, wouldn't be of much interest except to a direct commercial
competitor, and there's no compelling reason why they belong in the
commons.
If the GPL could be relied upon to work the way that I think US case
law dictates, I would stand a chance of persuading my employer to
open-source the lot, except for the hardware-specific bits and maybe
some other portions they're not yet done amortizing off. The GPL is
basically the right answer, since most other licenses wouldn't
obligate collaborators to share with us, and innovations in our
industry don't have a good history of being built on in public in the
absence of ground rules about derivative works.
But we don't really want to set up a copyright assignment regime, so
the FSF's insistence on waving the preliminary injunction club at
unwary linkers is a red flag. It would be stupid to take the risk of
having our proprietary knowledge Trojaned by a competitor (not in a
security hole sense but via their establishment of grounds for a
copyright infringement claim). The special pleading in the LGPL just
doesn't cut it with our lawyers, and I'm inclined to agree with them.
So nobody wins; the framework doesn't get released for others to use,
and I don't get to replace the bits of it that aren't so great with
better code available under any variant of the GPL.
In the best of all possible worlds, I'd like to see the FSF's attitude
changed and the GPL amended to reflect a realistic perspective on US
case law, and on the laws of other countries to the extent that they
are similarly tractable. I'd like to see all GPL variants, and as
many other licenses as possible, discarded in favor of this amended
GPL. Then I'd like to see GPL release of all the code that people
have kept closed not because it has any special value but because
reinventing those wheels was the least of the available evils. After
that, the Grand Refactoring, the reimplementation of Perl, Python,
Java, and C# against the OCaml bytecode interpreter, and World Peace,
not necessarily in that order. ;-)
Barring that rosy scenario, I would at least like to see Debian not
roll over when someone cries "Wolf!" over Kaffe + Eclipse, which is
where this thread started.
Cheers,
- Michael
Reply to: