Can Java code EVER be GPLd, at all?

[Angelo Schneider]

Hi Alex,

I think you go to far ...

Even when you are right in principle :-)

Please see my comments below.

Regards,
	Angelo

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.

> 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!

> 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!

> 
> 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.

Again the running server objects are dynamicly linked to the later
comming
clients.

The clients do not depend on a particular server (implementation), the 
in your case GNU server objects could easy be replaced by different one.

> 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.

> 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...

Don't want to argue about performance :-) But you should read something
about that.

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.

> 
> 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

You can put it into it. 

> 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.

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.

> 
> alex

Regards,
	Angelo

P.S. however you could restrict usage of your stuff to static linking
and/or forbit usage in a distributed environment.
---------------------------------------------------------------------
Angelo Schneider           OOAD/UML           Angelo.Schneider at xcc.de
Putlitzstr. 24         Patterns/FrameWorks       Fon: +49 721 9812465
76137 Karlsruhe             C++/JAVA             Fax: +49 721 9812467