Andrew John Hughes wrote:
Unfortunately, such suppositions aren't worth much in legal terms (and
let's get the obvious IANAL disclaimer in here before I say any more).
As we discussed a little on IRC earlier today, it's actually quite a
ridiculous situation that GNU Classpath and OpenJDK are just about
under the same license, but because of that 'or later' clause, they
are incompatible. Ideally, we would have imported a lot of OpenJDK
code into GNU Classpath when it was released. Filling the holes in
GCJ, for example, with Sun code would probably be a faster method of
getting a TCK-passing implementation on non-x86/x86_64 platforms,
assuming that such a combination counts as 'sufficiently derived'. In
an ideal world, both would be under GPLv3 and we'd share code between
the two as intended. On the other side, I've not seen as much code as
I'd expect (like the AWT peers) move into OpenJDK either, but I think
this is less legal and more process related.
Dalibor, could you give us something from Sun's side on this issue?
I'm not sure on which one:
* whether combining a GPLd VM with OpenJDK class library would be
sufficiently derived
as far ar the OCTLA goes?
Yes, please see the GB minutes
http://openjdk.java.net/groups/gb/2007-08-23.html#license-eligibility .
* whether GPLv2 + Classpath exception and GPLv2 or later + Classpath
exception are incompatible?
IANAL, but I'd say quite clearly no, they are compatible as you can pick
v2 regardless of what later later versions say in classpath's case.
* whether classpath or openjdk will be under GPLv3?
It's always hard to predict the future, but I guess a lot of that will
depend on the ongoing work the FSF is doing to unify the exception
language around gcc, when it is ready for public review, and how it
turns out - don't understimate the scope of that work, it's been going
on for a long time, as readers of the autoconf lists know. It will also
depend on what the actual effects of the v3 version of the exceptions
would be on v2 only users, or VMs that have v2-only dependencies. Think
VM-as-Linux-kernel-module scenarios, or Kaffe.
* whether FSF will accept GPLv2+Classpath exception code from openjdk
into classpath?
Hard to say. I'm not quite sure what we'd gain from duplicating the same
code in several places though - if we want to turn classpath into an
icedtea like wrapper around bits and pieces from openjdk, we can do that
without copying and pasting openjdk code over into another repository
(we've got enough third party code in classpath as it is, imho). if
there are bits from openjdk that make sense to depend on as a 'source
plug' for classpath, then we could go the icepick route, for example,
and wrap them up accordingly.
* whether gcj will lose its own copy of classpath and be able to use an
installed one or an alternative class library?
Hard to say. But it's basically the pragmatic reason why openjdk code
hasn't flown into classpath: it wouldn't look very good to have gplv2
only code in a gplv3 gcc/gcj. That's a policy decision forced by the
current architecture of gcj - if the tight coupling between the class
library and gcj was removed (see JamVM, Cacao, etc.), that particular
dilemma would not present itself as such.
I hope we can come to a decent resolution on this, but I think the
issue does need to be discussed openly and as soon as possible.
I don't really see a pressing need to discuss classpath's licensing
while the FSF is working on an update of the license, which will
hopefully be available for (public) review soon.
cheers,
dalibor topic
