[kaffe] Build system for kjc / external jars + Jetty/JSP success

[Jim Pick]

On 26 Jun 2003 18:56:37 +0200
"Mark Wielaard" <mark at klomp.org> wrote:

> Hi,
> 
> On Thu, 2003-06-26 at 18:04, Jim Pick wrote:
> > Actually, distributing some non-GPL compatible apps along with the VM
> > sources is not a bad way to help people understand how we interpret the
> > licensing issues.
> 
> Are you sure all copyright holders of the VM and the class libraries
> interpret the GPL this way? What happened to the copyright that
> Transvirtual held on large parts of the source code? The reason I ask is
> because the SCO mess reminds me of the fact that there will always be
> people/laywers who will interpret legal language in "creative" ways.

I think all the "IP" is probably sitting in a cardboard box somewhere in
some VC's closet in Japan.  :-)

In the wrong hands (eg. lawyer's like SCO's), I think that the IP could
possibly come back to haunt somebody who incorporated Kaffe into a
commercial product, and was making lots of money, even if the legal
claims were baseless (eg. what SCO's claims appear to be).  Let's not
even start thinking about all the submarine patents out there held by
various parties...

Still, I personally think that saying the GPL contaminates the applications
running across the virtual machine boundary is a stretch legally. Of course,
I am not a lawyer, and I don't own all of the IP, so my interpretation
isn't worth that much.  :-)

> One of the reasons that the GNU Classpath and Kaffe projects worked on
> their own core library implementations in the past was precisely because
> they disagreed about this point.

I'm pretty good friends with Paul Fisher, and he's talked to me extensively
about GPL vs. GPL+Exception, and some of the "back room" deals that went
on between Transvirtual and the FSF back in the day that led to the present
situation.  It's a real mess...

I think GPL+Exception is the way to go for the class libraries - the
exception is more of a clarification than anything, and helps remove the
threat posed by crazed IP lawyers.  I see Kaffe moving towards using 
Classpath for the core libraries eventually, and dropping most of the
current class library implementation.  Still, I don't think Kaffe can
ever totally shake the GPL.  I don't think that's necessarily a bad
thing, as I don't think it poses any real barrier for using Kaffe as
a basis for free software projects -- except we may have difficulty
getting projects like Debian to distribute it.

> >   I don't believe that the GPL, when used as a license
> > on a virtual machine, is so "super viral" that it contaminates
> > applications run on top of the machine, or bundled alongside it. 
> > Granted, it's a matter of interpretation, but I've had discussions with
> > a number of free software "luminaries" that basically agree with that
> > interpretation.
> > 
> > There are limits on how much the GPL infects other software - it doesn't
> > cross all boundaries.  The FSF will tell you so.  The only people who
> > will tell you that the GPL infects absolutely everything it comes in
> > contact with is Microsoft, as part of their FUD campaign.
> 
> The FSF indeed says that it doesn't cross all boundaries (though they
> use the terms "derived work" or "work based on the program", not
> "infect" and "boundary", since those are more common when used when
> talking about copyrights), but they do also say:
> 
> http://www.gnu.org/licenses/gpl-faq.html#OOPLang
> In an object-oriented language such as Java, if I use a class that is
> GPL'ed without modifying, and subclass it, in what way does the GPL
> affect the larger program?
> 
>         Subclassing is creating a derivative work. Therefore, the terms
>         of the GPL affect the whole program where you create a subclass
>         of a GPL'ed class.

I think that point could be argued.  When I subclass java.lang.Thread,
I don't "feel" like I'm creating a derived work of the Java Class
Libraries.  Instead, I "feel" like I'm using the API.

> http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL
> If a programming language interpreter is released under the GPL, does
> that mean programs written to be interpreted by it must be under
> GPL-compatible licenses?
> 
>         When the interpreter just interprets a language, the answer is
>         no. The interpreted program, to the interpreter, is just data; a
>         free software license like the GPL, based on copyright law,
>         cannot limit what data you use the interpreter on. You can run
>         it on any data (interpreted program), any way you like, and
>         there are no requirements about licensing that data to anyone. 
>         
>         However, when the interpreter is extended to provide "bindings"
>         to other facilities (often, but not necessarily, libraries), the
>         interpreted program is effectively linked to the facilities it
>         uses through these bindings. So if these facilities are released
>         under the GPL, the interpreted program that uses them must be
>         released in a GPL-compatible way. The JNI or Java Native
>         Interface is an example of such a facility; libraries that are
>         accessed in this way are linked dynamically with the Java
>         programs that call them.
>         
>         Another similar and very common case is to provide libraries
>         with the interpreter which are themselves interpreted. For
>         instance, Perl comes with many Perl modules, and a Java
>         implementation comes with many Java classes. These libraries and
>         the programs that call them are always dynamically linked
>         together.
>         
>         A consequence is that if you choose to use GPL'd Perl modules or
>         Java classes in your program, you must release the program in a
>         GPL-compatible way, regardless of the license used in the Perl
>         or Java interpreter that the combined Perl or Java program will
>         run on.

Again, this interpretation doesn't jibe with the way I "feel" when I
program in Java, and the vague language in the GPL leaves a lot open to
interpretation.

I know there is a bit of "back story" on all of these FSF interpretations,
and they reflect certain "deals" between this free software author here,
and RMS over there.  That's all well and fine, but a court of law might
see things differently.

> Maybe we should lobby the Apache Foundation to finally add the one word
> to the Apache License that would make it compatible with the GPL as I
> pointed out somewhere in the thread of that old email that Rob
> mentioned.

That would be nice.

My feeling on this is that we should forge ahead, and just drop the jars
into the tarball, since it would greatly enhance the user experience for
the end users.  It may or may not be 100% legal, but it's really a matter
of interpretation, and it's unlikely that what's left of Transvirtual, or
any of the other contributors would confront us for a GPL violation due
to incompatibility with the Apache license or any other freeish license,
since we have no money.

If Debian and the FSF still have issues, we can produce an additional
tarball without the Apache stuff.  The additional stuff is primarily a
convenience for the end users to help satisfy build-time dependencies,
and distributing it is really optional.

Kaffe probably will never really be the ultimate free software JVM
implementation, because of the GPL licensing issue.  But I still think
it's still incredibly useful as an "integration point" where we can pull
together free software Java technologies that could eventually be used
by other free software JVM implementations with clearer licenses.

Cheers,

 - Jim