Can Java code EVER be GPLd, at all?

[Alex Nicolaou]

Richard Stallman wrote:

>     If an application 'A' uses a library 'B' in what might be described as an
>     'essential' way, then, irrespective of the physical mechanism of linkage
>     (static/dynamic/run-time/compile-time/corba) I would expect 'A' to be
>     considered as a derived work of 'A'.  Especially if 'A' is distributed
>     together with 'B', and especially if 'A' won't function without 'B'.
> 
> That's the FSF's position.

This is a very difficult position to defend, because it is so gray and
so devoid of hard lines that it is impossible to say where the FSF
really stands. This puts the FSF in a position to sue all comers, which
may stop people from using GPL code.

Let's consider a hypothetical GPL WWW server named ehcapa. For this
hypothetical situation we shall assume that due to the intense efforts
of thousands of excellent GPL programmers, the ehcapa WWW server
acquires a near monopoly, and is run on 90% of the world's WWW servers.
The WWW server is effectively a program that responds to remote
procedure calls that request results, where the linking mechanism for
the procedure call is a protocol called http which is built on top of
some network layer.

Now, suppose I buy a commercial WWW browser. The browser uses the echapa
library in an 'essential' way, since it cannot display much worthwhile
content without connecting to the WWW (not to mention all the poor
content I wish to have access to). However, the FSF is in a position to
sue the browser authors, and potentially also its users, since the
browser relies on a GPL program in an 'essential' way.

The technically oriented observer is perhaps inclined to argue that the
network protocol isn't really "linking". But isn't it? Would the
situation really be different if echapa served WWW pages via CORBA or
DCOM, which are clearly "linking" technologies? I don't think so, and it
certainly wouldn't be hard to convince a judge that there is no
difference. Thus, it follows that any network protocol used to serve
data in response to requests is really a linking mechanism, and that all
servers which exist solely for the purpose of delivering data are pure
libraries.

To choose an example a bit closer to home, what about shell tools? Shell
tools, in my everyday usage, are small C programs of which the lion's
share are GPL and some small number are under various licenses, some of
them proprietary. They are the function calls of programs that I write
called 'bash shell scripts'. The Bash interpreter acts as a link-loader,
which takes care of loading the procedures, executing them, and
delivering their results to other procedures in the pipeline that forms
my computation. Not really linking you say? Excellent - I'll compile
your library into little programs, and write commercial shellscripts
instead of C code. A small linux kernel module will serve to permanently
cache these programs in memory so that performance won't suffer too
much...

Now we're finally getting to the meat of it. You write a GPL component
for the GNOME system, and I have a commercial container ... can I put
your GPL component in my container, or is that linking? What if the
container is totally useless except that it provides an excellent an
novel way to connect the components? That makes the components essential
to the container's operation ... the same argument applies to Java beans
and their containers.

So, you see, simply talking about programs that are essential to other
program's function is not really a very clear position for the FSF to
have. This lack of clarity makes it difficult to use the FSF's code in
production environments where the players are deeply concerned about
legal liability, and simultaneously rely on commercial code.

alex