Undistributable java in main (to d-l, please state your opinion)
Below is the mail that I sent yesterday to debian-java NOT putting Cc:
to d-legal as I thought the issue was really clear to me. After some
duscussion that began after my email (see
) it was requested to bring it on to debian-legal.
There were some more voices w/ important matters - *please see* the d-j
ML archive link given above to see what was said after my initial mail
(I don't think copying them all here would make sense).
It's mainly about - how far can we go w/ using GPLed java libs and on
practical side - how far can we go using Kaffe or similar ones.
W liście z śro, 29-10-2003, godz. 17:55, Grzegorz B. Prokopski pisze:
> Hi all!
> Summary: Usage of GPLed libs to compile GPL-incompatible code makes
> the result *undistributable*. 
> Affected java packages: Every package that contains GPL-incompatible
> software which was *compiled* using GPLed libs.
> Examples: current Ant package apparently(!) has been compiled w/ Kaffe
> libs which are GPLed. See for ex. unpacked current libant1.5-java:
> More discussion (cleaned up IRC log from #kaffe):
> Possible actions (no special order):
> * Review what java packages (especially the ones that are in "main"
> and contain GPL incompatible software) have been compiled with
> * Filling RC bugs for packages that seem to be indistributable
> * Finding a good way to check/assure what's the license of libs
> a package has been compiled with
> * Finding a good way to avoid such problems in the future (ex. by
> putting some tests into packages' build scripts or by using
> an improved version of findjava-like tool that understands
> Problems not touched: *execution* of GPL-incompatible code using
> GPLed libs and/or GPLed JVMs is beyond the scope of this message.
> Grzegorz B. Prokopski
>  AFAIK for the same reason KDE was once removed from Debian
> completly as linking GPLed code w/ GPL-incompatible license
> made it not only violate the license but also made the result
There also have been an important reply to my email from one of Kaffe
developers, Dalibor Topic which also could use some clarification from
W liście z czw, 30-10-2003, godz. 01:51, Dalibor Topic pisze:
> Grzegorz B. Prokopski wrote:
> > Hi all!
> Hi Grzegorz,
> > Summary: Usage of GPLed libs to compile GPL-incompatible code makes
> > the result *undistributable*. 
> > Affected java packages: Every package that contains GPL-incompatible
> > software which was *compiled* using GPLed libs.
> > Examples: current Ant package apparently(!) has been compiled w/ Kaffe
> > libs which are GPLed. See for ex. unpacked current libant1.5-java:
> > http://www.gadek.homelinux.org/java-illegal/ant/META-INF/MANIFEST.MF
> Well, I'd assume it only means it has been jar-ed with kaffe, but I
> don't have deeper knowledge of ant's MANIFEST.MF contents.
> > More discussion (cleaned up IRC log from #kaffe):
> > http://www.gadek.homelinux.org/java-illegal/gpl-conflicts-log.txt
> Since I'm one of the guys (dalibor) discussing this with Grzegorz
> (gadek) on irc, I guess I should chip in with a comment or two.
> Since kaffe is a) GPLd and b) somewhat useable, people try to do many
> things with it. One of them is running programs licensed under a GPL
> incompatible license. I do it all the time myself, for example. That's
> all fine and well under the scope of the GPL, as GPL doesn't bother
> itself with execution, but only poses restrictions on distribution,
> modification and copying of works.
> For whatever reason, we get one big 'How does Kaffe's GPL apply to Java
> programs' IANAL-thread every 3 months. See for example  for the last
> discussion (the time between those discussions decreases as kaffe
> improves and becomes capable of running more apps). As debian is a
> distribution, you have to interpret the GPL in one way or the other.
> (And you usually have debian-legal for that ;))
> There are basically two viewpoints on how GPL affects interpreters:
> A) The FSF:
> 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
> 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.
> However, when the interpreter is extended to provide "bindings" to
> facilities (often, but not necessarily, libraries), the interpreted
> is effectively linked to the facilities it uses through these
> bindings. So
> if these facilities are released under the GPL, the interpreted
> that uses them must be released in a GPL-compatible way. The JNI or
> Native Interface is an example of such a facility; libraries that are
> accessed in this way are linked dynamically with the Java programs
> 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
> 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
> way, regardless of the license used in the Perl or Java interpreter
> the combined Perl or Java program will run on.
> B) me (and I guess a few others who are not lawyers, either):
> As GPL only really talks about derived works, in order to decide if the
> GPL applies to a work we must try to see if the new work is derived from
> a GPLd work, or not.
> In my opinion a program that's using widely available APIs to accomplish
> its goals is not bound by the license of the interpreter, as it does not
> necessarily depend on the GPLd interpreter to run. The GPLd interpreter
> is not necessary for the creation of a derived work. Many
> GPL-incompatible java programs run just as fine (and sadly, still quite
> often somewhat better) on non-free VMs like Sun's VM as on kaffe.
> The case is even weaker, in my opinion, for the point you're trying to
> make: for compiling against GPLd widely available runtime APIs (i.e.
> JRE). AFAIK, the compiled bytecode is equally well (if you're using the
> JRE APIs) capable of running under a non-GPLd VM, whose runtime classes
> implement that API.
> As a small test I wrote a 'Hello' test program and compiled it using
> jikes against kaffe's rt.jar as the bootclasspath and against JDK
> 1.4.2's rt.jar. There is *no* difference in the generated bytecode,
> according to GNU diff. I think that an argument which uses copyright law
> to allow the same sequence of bits to be licensed under contradictory
> licenses depending on the components involved (note that I'm not saying
> contained) in the creation of those bit sequences is contradictory in
> Beside, you have no means to differentiate between a bit-pattern
> potentially violating the GPL in this way and the same bit-pattern not
> violating the GPL. Is the (let's say ASL 1.1 licensed for the sake of
> argument) Hello.class that I have attached to my mail volating the GPL
> or not, i.e. has it been compiled against kaffe or not?
> > Possible actions (no special order):
> > * Review what java packages (especially the ones that are in "main"
> > and contain GPL incompatible software) have been compiled with
> > * Filling RC bugs for packages that seem to be indistributable
> > * Finding a good way to check/assure what's the license of libs
> > a package has been compiled with
> > * Finding a good way to avoid such problems in the future (ex. by
> > putting some tests into packages' build scripts or by using
> > an improved version of findjava-like tool that understands
> > licenses...)
> * figure out how you want to interpret the GPL in this case. The rest
> follows from that.
> > Problems not touched: *execution* of GPL-incompatible code using
> > GPLed libs and/or GPLed JVMs is beyond the scope of this message.
> Here some more food for licensing flamewars bezound the scope of GPL:
> There is an interesting symmetrical case to be tried: provide a 'dummy'
> GPLd libc, that does nothing. It would go to main, and you could compile
> applications against it, though not run them. Then debian would have to
> kick Apache's web server out of main, since it'd be a) incompatible with
> the new alternative pure-gpl libc, but b) could be linked to it/would be
> implicitely liked to it through a Depends: libc line.
> As another remark, if you think Kaffe's licensing implications are
> complicated, take a look at mono: GPL interpreter and LGPLd runtime, X
> licensed class library. If the X licensed class library is linked
> during runtime to the GPLd interpreter via LGPLd libraries, how come
> Ximian is allowed to ship it under the weaker-thank-GPL X license,
> thereby apprently violating FSFs position on GPLd interpreters?
> dalibor topic
>  http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
>  http://www.kaffe.org/pipermail/kaffe/2003-June/042838.html
>  http://www.go-mono.com/faq.html#licensing
Grzegorz B. Prokopski
Grzegorz B. Prokopski <email@example.com>
Debian GNU/Linux http://www.debian.org
SableVM - LGPLed JVM http://www.sablevm.org