Re: Other class libraries
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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 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.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.
cheers, dalibor topic