Re: the errors

[Bernd Kreimeier]

Godmar Back writes:
 > No, it's the GPL; what I described was Tim Wilkinson's interpretation.
 > The question revolves about what "linking" is.
 > 
 > Tim's interpretation coincides with the interpretation of other people.
 > Below, I append a mail Jules Bean sent.  Jules is involved in the Debian 
 > project.  I think it makes a lot of sense.

I am recently had a similar dispute with the Mauve folks and
Steve Robbins (author of GPL'ed JavaDeps). I am pushing for 
LGPL-only Java.org.debian.[src|lib]-x.x.deb packages for a
pure Java built environment, and asked Steve whether he'd 
allow changing from GPL to LGPL. Here's a writeup of my 
reasons - maybe I should take it up with the FSF (no enemy
but time...):



--------- snip ------- ignore drivel -----------------------



Why LGPL only?
--------------


>From the GPL:
"But when you distribute [your non-derivative work] as part of a 
 whole which is a work based on the Program, the distribution of
 the whole must be on the terms of this License, whose permissions
 for other licensees extend to the entire whole, and thus to each
 and every part regardless of who wrote it.

 Thus, it is not the intent [..] to claim rights or contest your
 rights to work written entirely by you; rather, the intent is to
 exercise the right to control the distribution of derivative or
 collective works based on the Program."

To my limited understanding that's the whole reason for having 
a LGPL plus a GPL. Using GPL'ed code "infects" non-GPL'ed work
(including LGPL'ed work). 


1. "Good" Java code is re-usable aka a toolkit aka a library

That's what OOP is about. I want to avoid a code repository
in which every tool writes it's own command line parsing,
Java source parsing, directory tree parsing etc.pp. That's
why I proposed a java/debian/[lib|bin|app] split of the
source classpath. 

If any part of the distribution was GPL'ed, any coder using 
non-GPL'ed code would have to make sure he used only LGPL'ed
components, directly or indirectly (e.g. at runtime, using
forName() and reflection). If the entire tree is GPL'ed, 
it could not be used by non-GPL'ed code, which could also
not use LPGL'ed code linking to the GPL'ed distribution. 


2. Java uses dynamic linking and reflection

It is not possible to circumvent the GPL by using libdl.so,
plugin interfaces, threading, or any other means short of
IPC. Equally, it is not possible to do so using reflection
or class loading. As these techniques are fundamental to
Java, it is impossible to ensure no violation of the GPL
happens at runtime.


3. OOP works by inheritance and delegation, both link

Are subclasses derivative works? Are composites derivative
works? In both cases, the Java code will link to our code.



JavaDeps is a good example. Steve wrote it as a standalone
package, I want to split it into a re-usable parsing and
utility package and a minimal JavaDeps frontend (1). 
Currently, JavaDeps parses the Java source, and can thus
be applied to any code. If instead it instantiated a
compiled class and used reflection to inspect its 
dependencies, a collective work is created (2). 

Steve and other argue that the GPL is not about linking, but
about distribution. I say the GPL (like any license) is about
derivative works. The question is how the GPL definition of 
a derivative work applies to a given Java code.

My objective is that the Java.org.debian-*.deb packages can
be distributed along with any (free or nonfree) work. The
greater freedom [sic!] offered by the LGPL combined with the
flexibility of Java makes proprietary use very easy. It is
up to Debian to take this policy decision. [..]

I'd like to conclude by pointing out that commercial vendors
and free software developers face the same Java specific 
problem here. It is impossible to ship statically linked
Java binaries - there is no Java runtime. You always ship
the bytecode equivalent of header+DLL, and despite limited
obfuscation, you will always ship a debug version. Accidental
and intentional violation of restrictive licenses are much 
more likely.

Java is just not well-suited for attempts to leverage your
"intellectual property" for imposing restrictions - whether
the motives are monetary or political is irrelevant.