Stuart Ballard <[EMAIL PROTECTED]> writes:
> 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.
Embedded vendors must link statically, and they cannot handle the
requirements imposed by the LGPL when static linking is performed.
If we change licensing terms, we become usable by the embedded
community, but sacrifice the ability for someone with the technical
know how to upgrade the Java class libraries on their newly purchased
VCR. We also gain the advantage of merging the gcj and Classpath
projects into one. I, personally, see the advantages outweighing the
disadvantages.
And even so, Classpath still depends on numerous libraries that could
not be put under this new license. Such portions as java.lang.Math
(GNU mp) and AWT peers (GTK+/parts of Gnome) would of course still not
be usable by embedded vendors, since they link against LGPL'd
libraries -- but this is no real reason to keep embedded vendors from
using the parts of Classpath that we can permit them to use.
> Obviously, there are major differences in the "implementation" of
> this and the LGPL, but what are the differences in the "objective"
> that merit the change?
You can think of the proposed licensing change as having the spirit of
the LGPL, but with a spin that allows for embedded vendors to use our
libraries. We use a GPL with an exception clause, because that's less
work and cleaner than starting from the LGPL.
Please note that this change only affects linking. Any modifications
to the Classpath code base would still have to be free.
> 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.
> 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.
> Fourth (a niggle) Would the wording be changed from "compiled with
> gcc" to "compiled against the classpath libraries" (or whatever the
> combined project ended up being called) - so that it was compiler
> independent?
The libstdc++/libgcc terms are just a place to start from, that embody
the spirit of what we'd like to accomplish. Details on the specific
terms would have to be worked out.
> 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).
--
Paul Fisher
