Undistributable java in main (to d-l, please state your opinion)
Hi!
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
http://lists.debian.org/debian-java/2003/debian-java-200310/msg00107.html
) 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*. [0]
>
> 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
>
> More discussion (cleaned up IRC log from #kaffe):
> http://www.gadek.homelinux.org/java-illegal/gpl-conflicts-log.txt
>
> 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...)
>
> Problems not touched: *execution* of GPL-incompatible code using
> GPLed libs and/or GPLed JVMs is beyond the scope of this message.
>
> Cheers,
>
> Grzegorz B. Prokopski
>
> [0] 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
> undistributable.
There also have been an important reply to my email from one of Kaffe
developers, Dalibor Topic which also could use some clarification from
legal.
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*. [0]
> >
> > 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 [2] 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[1]:
> 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?
>
> 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
> other
> facilities (often, but not necessarily, libraries), the interpreted
> program
> is effectively linked to the facilities it uses through these
> bindings. 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.
> 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.
>
> 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
> itself.
>
> 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[3]. 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?
>
> cheers,
> dalibor topic
>
> [1] http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
>
> [2] http://www.kaffe.org/pipermail/kaffe/2003-June/042838.html
>
> [3] http://www.go-mono.com/faq.html#licensing
Best regards
Grzegorz B. Prokopski
--
Grzegorz B. Prokopski <gadek@debian.org>
Debian GNU/Linux http://www.debian.org
SableVM - LGPLed JVM http://www.sablevm.org
Reply to: