Hi,
Because some people feel unsure about how a JVM, its classpath and java
compiler interact together, below I tried to strip the situation down
to a simple and clean non-java case.
Assume we have the following packages, providing a shared library:
Package: propr-line
License: non-free, free to use (section: nonfree)
Provides: line-lib
Conflicts: line-lib
Package: gpl-line (think: readline)
License: GPL (section main)
Provides: line-lib
Conflicts: line-lib
There exist big "standarized" parts of "line-lib" library inteface, that
is documented and published. These two implementations of this
interface are fully interchangable, provide the same .so file (thus the
packages conflict).
Package: question
License: ie. APL (GPL-incompatible, but DFSG-compatible)
Technically the 'question' package now has two options:
1. Build-depend: propr-line
The licenses cause no problems, other that that 'propr-line' is in
non-free, so 'question' will have to stay in 'contrib'.
2. Build-depend: gpl-line
=>>>>>> I. This is indeed THE question: Is this allowed?
=>>>>>> II. Another question is Depend. Can it have the following form?
Depend: gpl-line | line-lib
=>>>>>> III. And can it have have such a depend?
Depend: gpl-line
You should assume that the 'question' package uses only the documented
interface of the library, can be compiled with any of the two libs, than
used with any of them.
About runtime - you can assume that it is not only 'question' program
that calls the library, but portions of the program itself can also be
called from within the library, like a callback hook in C. (I think ie.
about class loaders).
Please also note that the Build-depends and Depends define strict
bindings between the packages (and thus source or binary code) that is
distributed by Debian (so it does not look like a mere aggregation
anymore).
---------------- java talk starts here ---------------
The analogy above comes from the following. The 'question' package is
any GPL-incompatible java program, that is linked to a java library.
We have two java libraries - one in non-free (think Sun's JDK), second
in main, but containing GPLed pieces. Ie. Kaffe's Runtime.class, which
is an indespensible part of its class library .jar file is GPLed. It
implements java.lang.Runtime part of the "standard interface" that a
java library is expected to have. (It contains more GPLed files, but
one is enough).
There are of course other issues possible to discuss, ie.
a) if we had a JVM that is GPLed, but its pure java (non-native) library
is whole available under a more permissive license.
b) what if during the compilation process large parts of
GPL-incompatible code are executed on a GPLed JVM, and this binding is
quite strong, as it comes directly from Build-depends.
I do NOT want to get into these (possibly more complicated) questions
before getting answers to the above 3 basic questions.
Thank you for your throughful consideration and answers,
Cheers,
Grzegorz B. Prokopski
--
Grzegorz B. Prokopski <[EMAIL PROTECTED]>
SableVM - Free, LGPL'ed Java VM http://sablevm.org
Why SableVM ?!? http://sablevm.org/wiki/Features
Debian GNU/Linux - the Free OS http://www.debian.org
