Paul Fisher wrote:
>
> Please note that this change only affects linking. Any modifications
> to the Classpath code base would still have to be free.
Good.
> Stuart Ballard <[EMAIL PROTECTED]> writes:
>
> > Secondly, how would this license affect embedding of classpath in eg
> > Mozilla, which is Free but not GPL-compatible?
>
> Licensing for Java in Mozilla is a non-issue. Mozilla runs the JVM in
> a separate process, and therefore the JVM+libraries can be covered by
> any license.
Cool! I didn't know that.
(This next one taken out of order so that I can reply to both your
points together)
> > Firstly, isn't the objective of this license very similar to the
> > objective of the LGPL?
>
> Yes; however, with either of the proposed license changes, there would
> be no restrictions on software that links against Classpath. That is,
> vendors would be free to link dynamically or statically to Classpath,
> even if they were linking Classpath to proprietary software.
>
> > Thirdly, would this have any impact on Japhar, and if so, how do the
> > Japhar authors feel about this?
>
> This shouldn't affect Japhar, nor any other VMs, since we'd be granting
> more privileges when you link against Classpath.
This sounds good, but I'm a little confused - I seem to have some
fundamental misconception somewhere here. I was under the impression
that the primary difference between the GPL and the LGPL was that the
GPL required software linked with it to be under the GPL, but the LGPL
did not (the oft-mentioned "viral" property of the GPL). I appreciate
that there is a technicality involved here for embedded users, but
leaving that aside for now...
Does the proposed exception to the GPL really have the effect of
completely wiping out this "viral" effect? That seems to be what you're
saying, and I hope it is - just clarifying. At first glance, I didn't
realise that it was nearly so far-reaching.
> > Fifth... what would be the approach to the JNI vs CNI issue?
>
> The JNI/CNI issue could be solved post agreeing to cooperate. I don't
> see the JNI/CNI issue to be terribly important. gcj aims to support
> JNI, but that code needs to be completed. I personally find CNI to be
> extremely elegant (about 10 lines of JNI code correspond to one line
> of CNI).
Regardless of how cool CNI is, and I'm sure it is, it's not supported by
most VMs, and probably won't be, so Classpath can't rely on it (unless
we can somehow implement CNI *in* JNI? That would be nice.)
It sounds like this license doesn't impose any problems that I can see.
If my interpretation above is right, then I have no objections, FWIW.
Stuart.
