GPL with the Classpath exception - clarification needed

[Philippe Verdy]

John Cowan [mailto:cowan at ccil.org] wrote:
> In Java, or any language normally delivered either in source 
> form or in component-by-component binary form with run-time 
> linkage, this is very easy, meaning that the LGPL and the 
> GPL+CP are essentially equivalent.  The GPL+CP matters only 
> for a library written in a language where delivery by way of 
> static executables is the norm, and replacement would require 
> the proprietary part of the application to be delivered as .o 
> files or something similar.

You're right here, but .o files are not part of the distrobution of almost
all Java applications.

What really exists is 

(1) a set of shared libaries or DLLs that are used to implement the native
part of a Java class using the "native" declarator. Such appalication do
exist but are disqualifies as 100% pure java, and are not deployable
transparently to all platform. The Java written application will then need
to not only provide the Java part (classes whose some methods are using the
"native" declarator), but also the source of the binary library that is
required to make this class functional, and that should be located in the
class path so that they can be accessed through JNI), and specially
installed and authorized on the VM.

(2) a binary delivered as an executable or shared library, that is creating
the environment needed to setup a Java VM in which the Java written code can
work successfully: if this VM envoironment has capabilities that are not
those described in the public definition of the standard VM, such as how to
set the environment, or how the Java application must be traced (possibly
through JNDI or similar) by this specialized VM in order to have this
application behave as documented, then the sources of the program used to
setup this VM must be provided.

(3) if the binary or java application is installed in a VM but can only work
successfully only if the VM environment (accessible through the OS
integration API such as filesystem I/O or environment requests, or use of
RPCs) contains some data or services, those data or servics must be
described so that they can be replaced or emulated. If this required data is
restricted by a licence that does not allow emulation or copying (for
example if it contains some authorizations that allow deciphering the data
defining the expected behavior of the application), then it will block the
functionality of this application. If this data is not accessible, the
functions normally descibed in the open-sourced Java program must still be
separatable and manageable through another scheduling mechanism to provide
simialr services that will work according to the public documented API
specifications of the open sourced program (it's like in the case of the
GPL: you can have a private environment that can cntain the parameters
needed to draw a pixel correctly on the screen instead of just crashing or
blocking the application, if you have a program that calls or uses a
putpixel() API do draw a circle at precise coordinates on the screen and in
a specified color, the GPL'ed program cannot be modified to use instead a
mandatory system service that requires some authorization in order to be
able to draw on screen, and at the same time restrict the right to get
similar authorizations on other systems, or change this right so that the
application will be blocked or will exit abruptly or will display "sorry,
you need a licence to perform this", or that will a square instead or will
rempa all specified colors to white or will drawx nothing at all.)
System-integration features that may effectively become needed in order to
keep the functionality of the program derived from the LGPLed program, must
also accompany the sources for the modified java program or library, or must
provide at least a functional implementation conform to the initial
description in the original program (i.e. not contradicting it completely,
as it may provide additioonal distinct services or features).

The native environment software in category (3) that are coupled to pieces
of softwares in Java will generally not be in Java itself (there's the
possibility that the native environment is in Java itself, acting as an
hypervisor, but this is still extremely rare today). Some of these programs
may not be restricted to drive only a simple Java VM but can be any
arbitrary software written in arbitrary languages and linked with varioius
libraries. That's where the GPL+CP may be more a nuisance than a help. The
LGPL will be more general and will allow further posisibilities of
integration of the GPLed code with an exclusion, and its possible future
replacement by any alternate GPL or LGPL program or compatible.

Native programs of type (2) above are more frequent, they are applications
that are installed like traditional executables containing parts written in
C with common libraries and notably the Java VM SDK library for C/C++
programmers that allow them to instantiate a new VM using the default JRE
installed on the system host, or using their own copy of the JRE; these
programs typically install like traditional programs, with an installer,
icons in the local file system browser, shell integration features or
contextual menus, autostart feature at boot time, management and integration
in local system user profiles (including the user registry on Windows)...

The installers and programs of type (2) and (3) may download some other
installer for a JRE, but if the program is GPLed itself, it should not
absolutely require a specific JRE protected by copyright and should allow
users to indicate to use the JRE of their choice according to the JVM API.
The installer will also install in the classpath several shared libraries or
DLLs or resource files outside of the typical JARs where the JNI interface
is declared in the Java-written classes. This case is very frequent. However
there should exist a separate implementation of these DLLs or rshard
libraries with their fully functional sources.

The installer program (being not necessary to the functionality of the GPLed
program) need not be provided with its sources, as long as the manual
installation procedure is documented. It is generally admitted to use
non-open-sourced commercial installer tools, as long as there's a way to
install and uninstall the program without it, and it becomes possible to
create alternate installers or porting a similar functionality to other
environments. (But, frequently, programs licenced under GPL (or under GPL
with exclusion clauses like the LGPL or GPL+CP) choose to use open-sourced
installers or those that are available for free to anyone; they include in
their sources the setup files and makefiles or building batches needed to
make the installer fully functional.

For programs of type (1), generally there's no installer program, or there's
just a envelop format that allows them to be delivered on application
servers (for example by adding declarative evidence metadata within JARs, or
binary signatures and version info for the management of the installed
software on the server and their maintenance, updates or cleanup) or
directly to desktops from a web page (using a small JavaWeb Start file
containing the parameters needed to setup a VM, and preinstall the program
on disk and assigning some icon to the program more easily.

In this group of type (1) programs, applets were quite common (the VM setup
parameters are specified in the web page itself, and it is the browser that
will instanciate the VM itself,generally in a reusable cached instance,
passing it these setup parameters, and that will prepare a channel of
ommunication for interaction with the user and compatibility with the web
navigation).

Given the broad ranges of system integration services that today's versions
of the standard JRE can provide (or some common frameworks like initially
built for Eclipse or Oracle and IBM servers, but now largely reused without
them), and given the effective excellent performance and ease of deployment
of 100% Pure Java programs, it is now becomes more rare to find a lot of
sources needing any native JNI interface, so the category (1) concerns many
more programs than ever before (and not just applets).

This is in this category (1) that most J2EE developments for web services
and enterprise applications are made. In this category, you don't need the
GPL+CP and don't even need the LGPL or even any exclusion clause, because
the most widely used frameworks are profiting from other open-sourced or
free frameworks (like Hibernates, Struts, Eclipse, ...) and one of the many
supported database systems and web servers or application servers with lots
of similarities between each other, supported by a common API (i.e. with
publicly disclosed interfaces and interoperability protocols not needing a
prior agreement to get them or to implement and them and dsitribute a
product using these protocols) that commercial application servers are also
supporting.