Can Java code EVER be GPLd, at all?
Alex Nicolaou
anicolao at cgl.uwaterloo.ca
Wed Nov 17 23:41:27 UTC 1999
Angelo Schneider wrote:
> Alex Nicolaou wrote:
> >
> > 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.
> >
>
> Once I read form a company which uses GNU programms but provides a GUI
> for them, that gnu.org considers this legal because they ran in
> different
> processes.
However, the original mail was talking about how there are no hard lines
on this issue, and technical criteria such as how the linking is
accomplished are not as important as whether the work 'A' won't function
without 'B' ... suddenly the basis for argument is shifted away from
technical judgements about address spaces/process boundaries.
> > 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.
> >
> This is not linking :-)
> Because you attach the program, your browser below, to an already
> running
> WWWW Server. If at all, the server is linked to the browser!
I can easily write a Java class library loader that will load a GPL
class library into the Java virtual machine, so that it is "already
running". This loader could be GPL'ed and then my program comes in and
is a client to the class library ... (more below)
> > 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.
>
> Nope, the browser relies on a server and a protocol, and the protocol is
> not copyright able.
> The server can be exchanged without any serious difference for the
> browser.
> You could even do it during a session!
Indeed, my GPL'ed class library loader can (via the wonders of
interfaces) unload the first GPL library and replace it with another,
even during a session - the protocol (in this case the API) is probably
difficult to copyright, or even more likely is already published under a
very liberal license ...
> > 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
>
> Nope this is also not to be considered as linking (from a technical
> view).
> The CORBA or DCOM objects are running in a Server environment regardless
> wether a cleint wants to attach to them or not.
So have I done linking? I've created an exactly parallel situation, the
only difference being that all the code is in a single virtual machine
instead of across the network. The class library is loaded wehther or
not a client needs them to be present or not. The programs loaded after
the class library do not depend on a particular implementation, only on
the implementation of a standard interface.
> > 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.
>
> Linking means IMHO: a object(module, process, program, scrip) lacks
> something during startup. Before you startup, the missing stuff is
> provided by a linker, either static or dynamic.
I think that even by this definition the WWW server is an example of
linking. There is nothing in your definition to distinguish the fact
that the "missing stuff" (methods that retrieve html content) is coming
from an already running server. It is possible that I didn't follow the
definition properly, but I can't distinguish between the Java class
library case and the WWW case using this definition.
> > 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.
> Your argument is right and wrong :-) If my library is GPLed you will
> take MY SOURCE
> and derive little programs from them. If you read my license carefully,
> you will
> see that derived work is supposed to be published under GPL.
> So your little programs are as well.
Clearly the little programs are GPL. The question is, what about the
shellscripts? Bash acts as the link-loader; are my scripts forced to be
GPL or not? And if they are I am sure I violate the license daily since
I mix my GPL shell tools with non-gpl shell tools in little shellscripts
which I distribute to others.
> > 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.
>
> I think the final definition to essential is:
> a) the client program does nothing (usefull?) without the used server
> component
> b) the server component can't be replaced
> c) client and server run in the same address space (same process)
>
> The problem with JAVA and CORBA/DCOM is finaly that you can circumvent
> the
> static linking etc. by wrapping GNU stuff into RMI/CORBA/DCOM wrappers.
> The derived work is than clearly the server side RMI/CORBA/DCOM
> module which is linked to the GNU stuff.
>
> So you have to apply the appropriated license to that derived work.
> However, IMHO, a cleint is a independet work. Having the seperation via
> a protocol done, you can replace either side without notice for the
> other side.
I think you've just made the case that any GPL Java class library which
implements a standard interface can be turned into a server and thus
free everyone from the need to follow the GPL terms. However, I don't
see the need to introduce RMI into the picture, since the interpreter
already allows you to do the "linking" in the same way: it is a
technical line you are drawing and not a conceptual one.
alex
More information about the License-discuss
mailing list