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".
On Wed, Jan 26, 2005 at 05:34:00AM -0800, Michael K. Edwards wrote:
> Why not?
Because "all public interfaces" is too general a concept.
> 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.
When I see MS Word or Powerpoint being distributed for free, because
they constitute functional implementations of publc interfaces, I'll
agree with you.
> > 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.
The GPL coverse both derivative and collective works. I don't think
that a claim that <<in A+B, A is not a derivative of B>> is sufficient
in all cases.
Of course, there are cases where A+B is a collective work, or a part
of a collective work, and the GPL's terms allow its distribution.
But equally obvious, that's something the GPL specifically allows, and
it doesn't provide a basis for generalizing this permission to other
cases which the GPL disallows.
> 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?
It seems to me that you'd be engaged in activities where you need the
permissions described in the first sentence of section 2, but that you
would not be satisfying the associated conditions.
And I don't see the GPL denying its customers license. I do see grounds
to have the commercial vendor cease and desist from distributing the
library (whatever "distributing the library" means in that context).
> > [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.).
Note that these are very different cases.
The interface definitions from class files for the system libraries
for Java are (if copyright applies) owned by Sun, and distributed under
their license. Authors of GPL'd java systems can't claim ownership of
that specific content.
In the C universe, no such guarantee applies to system header files --
they're system specific.
> > 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?
As stated, I agree with these statements.
You also appear to think that where a GPLed work has functional
components, the license protecting the rest of the work no longer engages
when it the work is incorporated in a program which only modifies the
functional components.
> > 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.
Only for cases where the combined work is not a copyrighted work under
copyright law.
The GPL doesn't say "if the modifications are allowed because they're only
modifications to functional parts of the Program, then no restrictions
apply to the work based on the Program."
Copyright law is used as a metric for whether or not the GPL applies to
the work as a whole. But beyond that, it's not a metric for whether
a specific restriction within the GPL is relevant. If the work as a
whole is copyright protected, and it contains GPL protected code, then
the terms of the GPL determine whether or not any restrictions apply.
> > > 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?
I think I've focussed our point of disagreement to one
specific implication (that of scope).
> 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.
And the FSF's attitude has helped contribute to the subsequent growth
of the Unix commons.
> > 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?
Yes, quite a bit, many years ago. Unfortunately, I didn't save the
material for this conversation.
> Is there
> any reason to think that NeXT or MCC didn't just decide that fighting
> the GCC team wasn't prudent?
Yeah: we're talking about Steve Jobs.
Take a look at some of the legal actions Steve Jobs has instigated.
As a general rule, he'll take things to court if that would mean gaining
control of something, and would only avoid taking things to court if he
thought he'd lose control.
> > 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.
The FSF might make such expressions in philosophical articles, but
I don't see this in the GPL itself.
> It's not so much that it can't attempt to
> fight on other turf, it's that it doesn't choose to.
The only thing in the GPL which I see that might justify this statement is
the scope of protection thing -- where combined works are not restricted by
the GPL if they're not copyrighted works.
But I don't see the sort of fine-grained "copyright law is the only issue"
logic which you seem to be arguing is present.
> > 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 have no disagreement here. But I think those rules need to be specified
on a per-tool basis (estoppel seems to be a frequently used mechanism
for dealing with this on a per-tool basis), and sometimes even a per-case
bases (section 10).
> > > 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.
I agree with you on this point.
I'm disagreeing with you on the implications of this point.
> > > 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?
What software has been released under the GPL which combines with
other, pre-existing code which was only available under the GPL?
> > * 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?
If they're the authors of that GPLed code, they might care. For instance.
> How do they benefit from the lack of commercial involvement in the
> maintenance of the components on which they depend?
It's commercial involvement that they likely benefit from -- more
specifically, commercial contributions to the GPLed code base.
Commercial decisions are made on economic terms, not philosophical terms.
The GPL plays a part in shaping those terms.
This isn't "hostage taking" any more than [or any less than] charging
for distribution is "hostage taking".
> > * 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.
They don't have to study the programs which use the GPLed code to
determine which parts they're allowed to use and which parts are off
limits.
For complementary developers, they don't have to worry about some other
company snapping up their code and taking it off the market through some
kind of embrace and extend.
> > 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.
So?
> > 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?
To the degree that the tools are available in a useful form from the
linking ban, he gained those tools. Other than that, nothing that I'm
aware of.
> > 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.
If you want to argue that specific case, I don't have any immediate
problems with it. I've not looked at the non-GPL copyrights any time
recently, and I need to get off the computer soon, so I'm not in a
position to say anything more in depth on this right now.
But please don't try to overgeneralize this one case into something
that tries to apply to "everything".
> > 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. ;-)
If I understand you correctly, you could address all your company's
concerns by licensing the headers and build files needed to compile your
libraries under BSD (or maybe LGPL) and license the rest of your content
under GPL.
Or is there some other concern?
--
Raul
Reply to: