[kaffe] Re: kaffe's license

Dalibor Topic robilad at kaffe.org
Fri Jun 17 11:48:19 PDT 2005

Jim Pick wrote:

> I mention it because that was Transvirtual's old position.  Yes, I
> believe it to be FUD too.  :-)

Transvirtual had a valid claim regarding ahead of time compiled code, as
the resulting ahead of time compiled binaries would have incorporated
copies of GPLd classes.

Compiling the class library down to native code made a lot of sense for
some embedded targets, I guess, which were Transvirtuals main market,
and they probably wanted to keep competition (i.e. internal forks of
gcj) out of those markets by requiring them to write their own class
libraries with GPL+linking exception rather than reusing Transvirtual's
GPLd code directly.

Back in the days, Transvirtual's product was the only one to offer AWT
support on many platforms, while gcj didn't have an AWT implementation,
and licensing Transvirtual's code under the GPL prevented proprietary
software developers from creating non-GPLd binaries from Transvirtual's
GPLd AWT code using gcj rather than using Transvirtual's KaffePro products.

> I didn't even mention the messy situation with software patents,
> particularly in the U.S., and possibly Europe, soon...  Who knows what
> patents companies like Sun, IBM, Microsoft and others are holding that
> might apply to our implementation?

Again, I suggest doing as Linus does, and ignoring software patents as
long as noone is there making such claims. In some jurisdictions (like
USA), patent infringement damages can be higher if you knowingly violate
patents, so the best advice, afaik, is *not* to go out there looking for
patents one may violate.

> The same page also says that subclassing a GPL'd java class is creating
> a derivative work.  Kaffe's class libraries were GPL'd.  We've almost
> completely moved over to using the Classpath projects class libraries,
> which are GPL+Exception, so hopefully that will provide some more
> license "insulation".  :-)

In general, subclassing a GPLd Java class is creating a derivative work.

For example, if Kaffe had a GPLd, Kaffe-specific Java class for jitters
to plug in, than all jitter implementations for Kaffe extending that
class would necessarily be GPLd.

With respect to programs using standard APIs with multiple
implementations, though, those programs are written to the API specs,
rather than to a particular implementation of it.

So a HelloWorld source code that uses System.out.println("HelloWorld");
is an independant work from any VM it can be executed in, and therefore
can be licensed independently of the license of the GPLd VM. The
resulting binary class file looks exactly the same no matter which class
library it was compiled against, and works in the same way, VM
independantly, so whatever interface names end up being in there from
the GPLd implementation of java.lang.System, are there because of the
requirements of the bytecode format, and are not copyrightable in
themselves (don't meet requirement for originality, as one would always
come after the JCP, and for the sake of compatibility have to have
exactly the same strings). As the bytecode is exactly the same with
either class library, and there is nothing specific to GPLd code and
copyrightable that ends up in the resulting binary, the resulting
bytecode is an independant work that can be licensed as one wishes, as
long as no other constraints on its licensing exist, of course.

That's the difference between using a GPLd, unique class library: in
that case, the bytecode and the source code both contain strings that
are copyrightable (since original) by the authors of the unique GPLd
class library, and the resulting work directly depends on incorporating
the unique GPLd library: it is clearly not an independant work.

That being said, the final switch to GNU Classpath will also make the
licensing situation a bit clearer, making such long elaborations
hopefully unnecessary. :)

Nevertheless, I'd like to encourage people to publish their code under
the GPL or GPL-compatible licenses, even if they are not required to, as
David A Wheeler's article[1] shows that the benefits of participating in
the GPL pool are huge.

dalibor topic

[1] http://www.dwheeler.com/essays/gpl-compatible.html

More information about the kaffe mailing list