2008/6/25 dalibor topic <robilad@xxxxxxxxx>: > 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 . > Well I suppose the question is more 'how much OpenJDK is needed to be substantially derived?' I suspect just having something like jaxws + cacao + classpath is not enough for example, while jaxws + hotspot + classpath would be. Is the TCK license available for general consumption yet? I'm slightly less perturbed by aph telling me that you do actually get source code. The fact that a myth to the contrary could permeate to me just shows the problems with such NDA stuff... ;) > * 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. > This was mjw's interpretation, but I think, as pointed out here and in other threads, that it's more a policy-level issue (FSF/Sun) and I didn't comprehend that we need GPLv3+exception not GPLv3 for some reason. > * 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. > Solaris should clearly just go GPLv3 and we should all switch to that, if Linux is going to stick with GPLv2 ;) > * 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. > I wasn't thinking of duplicating or trashing code. More just of plugging the vast holes that I don't think there are sufficient people working on Classpath to fill any more e.g. jaxws as mentioned above. > * 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. This is actually something I'd be interested in looking at, if only I had the time. >> >> 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. > Well this thread pretty much satisfies me. I think we just need to make these issues, that have been mentioned occasionally and vaguely, on IRC clear and out in the open. > cheers, > dalibor topic > Cheers, -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
