Re: Java, Python and GPL
NB: I'm not a lawyer, so don't take anything I write too seriously.
Ben Burton <benb@acm.org>:
> 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
Reply to: