> The case for (L)GPL is that it might be the most practical solution in
> terms of what reusable code is already available to you.
For instance, our class library is going to be LGPL because
classpath is, as least the Java portions of it.
(Which license the native parts of it come under will really
depend on if I think it'll be easier to re-write classpath to use BCNI
(e.g. remove as much as possible of their native code and write the rest
into the JVM (that is, statically link the library, since we don't have
dynamic links with jJOS quite yet) -- for both builds, where we migrate
away from classpath's native code as relevant portions of our
emulation/codebase become available) or to add JNI support to decaf. (pro:
it's a standard. con: it's a whole lot of work for something we don't
won't anyone to be doing.
IMHO, using native code in a JOS app should be
akin to using a kernel module for a linux app. This lets us say "it has
to be linked into the kernel" where 'kernel' is the jJOS+decaf
combination, and gives the right set of connotations to native code. For
effiency's sake, we may have to put graphics drivers (etc) in native code
in the kernel, and step away from the X model. If we do, we may want to
provide a relatively high-level API so the drivers can take better
advantage of the hardware acceleration available. (e.g. either Java3D or
OpenGL or 3D, and the equivalent for 2D.))
-_Quinn
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
