From: Edmund G. E. <ed...@ra...> - 2001-07-03 13:00:51
|
NB: I'm not a lawyer, so don't take anything I write too seriously. Ben Burton <be...@ac...>: > Hi; me again. Question this time regards packaging Jython (www.jython.org), > a pure Java implementation of python. > > Jython is currently subject to a DFSG-compilant but possibly GPL-incompatible > license similar to that of python 2.0. Now that Python is GPL-compatible again, can you make Jython GPL-compatible? > Jython also includes a class (ReadlineConsole.class) that links with the > LGPLed lib-readline-java Java classes (uploaded to debian today) that in turn > links to the GPLed libreadline.so using JNI (the Java-C interface). There's also a similar library called Editline which has a less restrictive licence than Readline, so maybe that can be used instead. > Under default operation the ReadlineConsole class will not be used. If a > particular option is set in the jython configuration file, Jython will use > ReadlineConsole which in turn links with libreadline.so. > > Given that neither libreadline.so nor the LGPLed lib-readline-java classes > are packaged as a part of Jython, and given the nature of java linking which > is somewhat different from C linking, which of the following scenarios > applies: > > 1) A binary distribution of Jython may include ReadlineConsole.class - it is > up to the user to not violate the GPL. > 2) A binary distribution of Jython may not include ReadlineConsole.class, but > the corresponding source file ReadlineConsole.java may still be included in > the sourceball. > 3) The source file ReadlineConsole.java should be removed before anything is > distributed. Probably no one knows for sure. My conclusion from a recent discussion in debian-legal (other participants drew other conclusions, of course) is that you musn't encourage people to link GPL code with GPL-incompatible code because that would be as if you were distributing the derived work yourself. Therefore, probably I would go for your scenario 2, but make sure there's nothing in the .diff.gz which might encourage people to link that source file. So a comment like "Uncomment the following line to include Readline" would be bad. Instead, explain why Readline has been excluded from the binary and tell people not to include it. If the source file ReadlineConsole.java might be useful later, with Editline, or if Jython's licence is changed, then that seems reason enough for not suppressing it entirely. > Furthermore, would it be legal to use reflection to see if functions > Readline.readline() and Readline.initReadline() exist and if so call them? It's not possible to answer that in isolation; it depends on your overall intention. If those functions happen to be there, I wouldn't have thought it necessary to strip them out. If you're thinking about adding them specially, then why? If it's to encourage people to link Readline with a GPL-incompatible Jython, then that's bad; don't do it. If you have another, legitimate reason for it, then maybe it's all right. Edmund |