Re: Eclipse 3.0 Running ILLEGALY on Kaffe
[Regarding the compatibility of a GPL JVM with Java code under other
licenses; cross-posted from debian-java to debian-legal]
Grzegorz B. Prokopski wrote:
> However if nobody stands up and say clearly, that there IS a problem,
> that GPL and CPL/APL are NOT compatible, and cannot be linked together,
> then we'll still see plenty people WASTING THEIR TIME on things that
> cannot legally benefit Debian Project and Debian users.
You know, just because the FSF has claimed for many years that linking
forms a derivative work doesn't make it true. I'm of the opinion
(IANAL) that precedents in the US are clear that it does not.
External interfaces to software components are functional (vs.
expressive), hence not protectable under copyright -- and that
distinction (not specific to software) is founded in the Berne
Convention and probably has wider applicability than just the US.
Put aside the FSF's entrenched position for a moment. Consider a
magazine article which contains newly coined words that are defined in
a sidebar written by a separate author. Under any law that conforms
to the Berne Convention, the magazine itself isn't a derivative work
of either the article or the sidebar; it's a collection containing
both. The article isn't a derivative work of the sidebar either; it
makes reference to the ideas in the sidebar using the "public
interface" provided (the newly coined words). Neither the ideas nor
the coinages are copyrightable.
If the sidebar is licensed under the GPL, then it doesn't matter
whether the article and sidebar are on the same page of a magazine
(statically linked), on separate pages in a looseleaf binder
(dynamically linked), or in separate envelopes. No derivative work
has been created under copyright law, so the GPL doesn't touch the
copyright in the article or in the magazine as a whole. (Collections
aren't derivative works, and are only separately copyrightable to the
extent that creative choices are involved in the selection and
assembly of the components.)
There are other theories under which a different license on the
sidebar could attempt to disallow these uses. It could reserve the
right to include the sidebar in a collection, permitting only
publication in isolation. It could require separate permission from
the copyright holder for each published edition, so that the holder
could veto undesirable combinations. Or, in its character as an offer
of contract, it could contain contract provisions of almost any kind
allowed under applicable contract law, using definitions that are
terms of art (like "dynamic linking").
But the author(s) of the GPL claim to believe that it isn't an offer
of contract, and try to control use of GPL material entirely through
the copyright definition of "derivative work". As I have argued
elsewhere, this just doesn't work the way they seem to think it does.
Wearing the "derivative work" straitjacket doesn't stop the GPL from
being governed by contract law, but it does greatly reduce the scope
to disallow uses that a contract could reach, such as (in my opinion)
both static and dynamic linking.
Needless to say, most people in the free software world take the FSF's
claims at face value -- hey, their General Counsel is a law professor
at Columbia! He seems to be a decent guy, too, and I don't really
understand the persistence of his "non-contract license" stance in the
face of (IMO, IANAL) overwhelming evidence to the contrary. I am an
advocate of, and contributor in a small way to, free and open source
software myself, but I like to make my own judgment of the available
evidence, even when it comes to legal matters. In recent postings to
debian-legal, I've included various references to the case law that I
have been able to find. Judge for yourself.
Cheers,
- Michael
P. S. For what it's worth, I'm not advocating that Debian change its
policies about applying a "strict" interpretation of copyright
holders' intent when judging the appropriateness of package
combinations. It's not nice to distribute GPL-incompatible code
linked against FSF GPL libraries, whether it's legal or not. It's
also not smart, since the FSF might drop the "non-contract license"
fiction in a later edition of the GPL.
But if the Kaffe copyright holders interpret the relationship between
Java bytecode and GPL code to be loose enough not to create a
derivative work, I think they have at least US case law behind them.
In the context of another currently raging debate, I'm a little more
uncomfortable with non-free firmware embedded as hex dumps in GPL
drivers even if Linus and the driver authors say it's cool, but as
separate files read during module loading I think they're fine, given
a clear and irrevocable OK to redistribute from the vendor.
Reply to: