Paul wrote:
> Yes; however, with either of the proposed license changes, there would
> be no restrictions on software that links against Classpath. That is,
...
..
[I agree with everything Paul wrote here]
> 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.
We would also like to provide alternative implementations - like a
100% java BigInteger, using Per's Java MP code.
> 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.
Exactly. But let's try that now. I propose that we simply use:
/* As a special exception, if you link this library with other files
to produce an executable, this library does not by itself cause the
resulting executable to be covered by the GNU General Public
License. This exception does not however invalidate any other
reasons why the executable file might be covered by the GNU General
Public License. */
It's very simple.
> The JNI/CNI issue could be solved post agreeing to cooperate. I don't
> see the JNI/CNI issue to be terribly important.
I agree. We want to continue to implement lots of code using CNI,
and, of course, JNI bindings are important for other reasons. Someone
will have to architect a solution where we can support both JNI and
CNI bindings (we plan on eventually supporting JNI and CNI
simultaneously, but CNI is often preferable - especially for the core
library code).
AG
--
Anthony Green Cygnus Solutions
Sunnyvale, California
