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.