Re: Other class libraries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux