OpenJDK and JNI -- licensing

Kevin Regan galabar at
Tue Jul 7 17:18:46 UTC 2009

Hi Volker,


Thanks for the reply.  You bring up valid concerns.  It would be great if Sun could give some specific examples in the FAQ to allay our fears.  For example, they might look at three applications:


A) Pure Java .class files

B) JNI Application

C) Application that extends the JRE functionality by linking with non-Classpath exception files in the JRE itself


Each application could be shown and explained in terms of how it interacts with the OpenJDK license.  I understand that ambiguity is great for selling more commercial licenses.  However, I doubt that it Sun's goal here, and a few example could help tremendously.


> Date: Tue, 7 Jul 2009 19:04:29 +0200
> Subject: Re: OpenJDK and JNI -- licensing
> From: volker.simonis at
> To: Dalibor.Topic at
> CC: galabar at; discuss at
> Hi,
> I've read the mentioned several times in the past and I reread them
> from time to time, just because they are like a good book - you always
> find something new in there, most of the time you even think you never
> read them before:)
> But seriously, I always found it quite strange the the HotSpot VM,
> which in the end is one monolithic shared library (libjvm.{so,dll}) is
> build from files with different licenses. And in the FAQ, linking an
> application to the VM is interpreted in the sense of the include files
> which are used in order to compile the application.
> In this special case, if I understood the thread right, Kevin builds a
> commercial application which includes "jni.h" at compile time. That's
> ok, because "jni.h" has the classpath exception. But in the end (i.e.
> at runtime) he dynamically loads the HotSpot (by calling
> JNI_CreateJavaVM) or the VM calls his application by menas of JNI and
> in my eyes, that's not ok, because the HotSpot VM (i.e.
> libjvm.{so,dll}) is mostly build from files which are pure GPL.
> It may be the case, that until now, nobody really cared about this,
> but from my point of view, that's a clear violation of the GPL,
> because the FSF is very clear about the fact that linking a dynamic
> library constitutes a "derived work" in the GPL sense (see for example
> So either
> the whole HotSpot must have the classpath exception, or linking a
> non-GPL program against will violate the GPL.
> Regards,
> Volker
> On 7/7/09, Dalibor Topic <Dalibor.Topic at> wrote:
> > Kevin Regan wrote:
> > > I'm reading the Classpath exception as meaning that a compiled java .class file that is run with the JRE would otherwise be subject to the GPL, if not for the exception. Is this correct? Does this extend to JNI libraries (that do not reference any OpenJDK code) that are actually linked into the JRE through a dynamic library at runtime?
> >
> >
> > Hi Kevin,
> >
> > I believe that your first question is answered by
> >
> >
> > and that the second question is answered by
> >
> >
> >
> >
> > If you need specific legal advice, I am afraid that I
> > can't be of much help there, not being a lawyer myself.
> >
> >
> > cheers,
> > dalibor topic
> > --
> > *******************************************************************
> > Dalibor Topic Tel: (+49 40) 23 646 738
> > Java F/OSS Ambassador AIM: robiladonaim
> > Sun Microsystems GmbH Mobile: (+49 177) 2664 192
> > Nagelsweg 55
> > D-20097 Hamburg mailto:Dalibor.Topic at
> > Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
> > Amtsgericht München: HRB 161028
> > Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
> > Vorsitzender des Aufsichtsrates: Martin Häring
> >
> >
> >

Insert movie times and more without leaving Hotmail®.

More information about the discuss mailing list