CORBA and the GPL (was Re: Can Java code EVER be GPLd, at all?)

[Justin Wells]

On Fri, Nov 19, 1999 at 05:39:44PM -0700, Richard Stallman wrote:

> But I should make one correction to what I wrote before.  I see now
> that "corba" was described as a method of linkage, in the message I
> responded to.  I didn't notice that when I read it before.  I don't
> think that corba is equivalent to linking; it is more like
> fork-and-exec or communication via pipes.  In other words, when corba
> is used, I would normally tend to think that two things are separate
> programs, unless there are very strong reasons to think otherwise.

OK, but consider this:

   -- take GNU readline and make a CORBA binding for it. The resulting
      CORBA enabled program would be a GPL'd program because it is 
      definately a derived work

   -- use CORBA to call the GNU readline method from another program,
      gaining ALL of the readline functionality in that other program,
      but release it under a proprietary, closed-source, anti-free 
      license and just say that it depends on the GPL'd CORBA readline

Is this legal? It obviously does an end-run around the GPL. But according
to what you wrote it is no different than viewing the CORBA object 
providing readline capability as being a separate program--and anyone
can *use* a GPL'd program however they like.

The situation is practically the same in many Java programs, which is 
why I originally wondered whether it was possible to GPL a Java 
program. Java has things like "remote method invocation" (RMI) that 
do almost exactly the same thing as CORBA. 

You might think it isn't a problem because, for efficiency purposes, 
someone wouldn't ordinarily do this--but CORBA optimizes things quite 
well when the target of a call and its caller are both inside the 
same process. 

I would like to write something into my license to effect the intended
copyleft, but I am at a loss as to exactly what to say. There is a very
thorny issue here.

Justin