On Saturday 01 November 2003 20:08, Etienne Gagnon wrote: > E.L. Willighagen (Egon) wrote: > > The big question seems to come done to: > > > > "What part of Java is library and what part is language?" > > > > It seems to me that at least the syntax *and* java.lang *is* the > > language... Thus as long as you don't use anything else then java.lang > > classes, you can use kaffe to run *any* Java byte code, independent which > > license... > > The FSF seems to disagree with you there. See the GPL FAQ:
If only the part below makes you believe that the GPL FAQ disagrees, then I tend not to agree... Contrarily, I think this FAQ items supports my point: I think the text clearly distinguishes from language and library part of interpreters... just like my argument. The java.lang package *is* the Java language, not a library part... everything else under java.* is library... So the FAQ items actually supports my view that if you only use Kaffe to interpret java.lang classes and nothing else, then Kaffe just interprets the language, and the FAQ states that it then does not require the program run by Kaffe needs to be GPL too... Egon > http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL > > [Please note the 3rd paragraph of the answer.] > > Q)If a programming language interpreter is released under the GPL, does > that mean programs written to be interpreted by it must be under > GPL-compatible licenses? > > A)When the interpreter just interprets a language, the answer is no. The > interpreted program, to the interpreter, is just data; a free software > license like the GPL, based on copyright law, cannot limit what data you > use the interpreter on. You can run it on any data (interpreted program), > any way you like, and there are no requirements about licensing that data > to anyone. The language is the syntax + java.lang classes. (IMHO) The .lang must come from somewhere... > However, when the interpreter is extended to provide "bindings" to other > facilities (often, but not necessarily, libraries), the interpreted program > is effectively linked to the facilities it uses through these bindings. This would be packages like java.util and java.io I have to admit that it is hard to write a program that does not use classes from these packages... so most package actually do link against Kaffe... but that's not my point here... > So > if these facilities are released under the GPL, the interpreted program > that uses them must be released in a GPL-compatible way. The JNI or Java > Native Interface is an example of such a facility; libraries that are > accessed in this way are linked dynamically with the Java programs that > call them. > > Another similar and very common case is to provide libraries with the > interpreter which are themselves interpreted. For instance, Perl comes with > many Perl modules, and a Java implementation comes with many Java classes. java.util, java.io, etc, but not java.lang which is are the classes from the Java language... and not library classes, I think... > These libraries and the programs that call them are always dynamically > linked together. > > A consequence is that if you choose to use GPL'd Perl modules or Java > classes in your program, you must release the program in a GPL-compatible > way, regardless of the license used in the Perl or Java interpreter that > the combined Perl or Java program will run on. regards, Egon -- PhD Molecular Representation in Chemometrics Laboratory of Analytical Chemistry http://www-cac.sci.kun.nl/people/egonw.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
