dalibor topic wrote:
Andrew John Hughes wrote:
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 .
And I should point out that that bit is the only thing I can give you
from Sun's side.
Anything below that is my personal opinion as a Classpath developer -
I'm posting this so that people don't get confused between the multiple
hats I'm wearing here, when I say 'we' below. We as in 'we, the
classpath developers'.
I was posting from my Kaffe.org address, but I'm not sure a lot of
people would catch something that subtle.
cheers,
dalibor topic
* 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
