OpenJDK and JNI -- licensing

[Florian Weimer-2]

* Andrew Haley:

> Volker Simonis wrote:
>> Yes, I understand that conflict. But the HotSpot library libjvm.so
>> itself is build mostly from files which are pure GPL and some files
>> (in particular "jni.h") which are GPL + class path exception).
>>
>> So how can "jni.cpp" (which is GPL only) include "jni.h" (which is GPL
>> + class path) and finally be statically linked with other GPL only
>> files into a GPL-only "libjvm.so"???
>
> Why not?  GPL'd code can use GPL+exception code.  What makes you
> think otherwise?

It fails the common sense check.  If GPL+exception code relies on
GPL-only code for execution, the code isn't GPL+exception, really, but
rather GPL-only.

(IIRC, OpenJDK also contains some Apache 2.0 code, so there is a
licensing inconsistency there.  It's not just that the end result
isn't GPL-only instead of GPL+exception.)

--
Florian Weimer                <fweimer@...>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: [phone]
D-76133 Karlsruhe             fax: [phone]

[Volker Simonis]

I thought, GPL'd code can only use GPL'd code. Otherwise I could
always write a wrapper which is GPL+exception in order to use any kind
of code together with GPL'd code by means of that wrapper.

On 7/8/09, Andrew Haley <aph@...> wrote:

> Volker Simonis wrote:
>  > Yes, I understand that conflict. But the HotSpot library libjvm.so
>  > itself is build mostly from files which are pure GPL and some files
>  > (in particular "jni.h") which are GPL + class path exception).
>  >
>  > So how can "jni.cpp" (which is GPL only) include "jni.h" (which is GPL
>  > + class path) and finally be statically linked with other GPL only
>  > files into a GPL-only "libjvm.so"???
>
>
> Why not?  GPL'd code can use GPL+exception code.  What makes you
>  think otherwise?
>
>
>  Andrew.
>

[Kevin Regan]

Yes, this would most certainly be very helpful.

 

Sun, what do you think?

 

--Kevin
 

> CC: dalibor.topic@...; discuss@...
> From: geir@...
> To: galabar@...
> Subject: Re: OpenJDK and JNI -- licensing
> Date: Wed, 8 Jul 2009 05:34:39 -0400
>
> I strikes me that the best thing for everyone is a FAQ entry from Sun :
>
> "Q: Does the classpath exception apply to JNI applications running on
> OpenJDK?"
>
> with the answer
>
> "A: Yes"
>
> or
>
> "A: No"
>
> depending on Sun's official stance on the matter.
>
> Seems like an easy thing for Sun to provide.
>
> geir
>
>
> On Jul 7, 2009, at 8:08 PM, Kevin Regan wrote:
>
> >
> >
> > So, let me get this straight. I need to first understand the
> > Classpath exception, then find this entry in the FAQ about alternate
> > licenses (that I otherwise would not be looking for), track down
> > these demo applications, notice that at least one of them is JNI,
> > and then assume from the wording of "Because these components are
> > not part of the JDK but rather are
> > application programs, they need not be under the GPL license because
> > of
> > the Classpath exception" that my JNI applications are also not
> > encumbered by the GPL?
> >
> > You are absolutely serious in putting forth that this is sufficient
> > for most developers to answer this question (are JNI applications
> > subject to the GPL)? You are stating that most developers will come
> > to the FAQ and easily track down this information?
> >
> > So, clearly, from following this procedure, we've surmised JNI
> > applications are not subject to the GPL, correct?
> >
> > --Kevin
> >
> >> Date: Wed, 8 Jul 2009 01:58:03 +0200
> >> From: Dalibor.Topic@...
> >> Subject: Re: OpenJDK and JNI -- licensing
> >> To: galabar@...
> >> CC: discuss@...
> >>
> >> Kevin Regan wrote:
> >>> I'm asking for samples explaining how the license applies to JNI
> >>> and pure Java applications.
> >>
> >> Let me quote from the FAQ I referred to in the mail you're just
> >> replying to:
> >>
> >> "Q:
> >> Are there any other licenses used in the OpenJDK code base besides
> >> the ones you've already described?
> >> A:
> >> Yes. The demo and sample code modules are released under the BSD
> >> license. These code elements are intended to be very widely
> >> distributed, freely modified and used. Accordingly, we've chosen
> >> the BSD license as most appropriate for these uses. *Because these
> >> components are not part of the JDK but rather are application
> >> programs, they need not be under the GPL license because of the
> >> Classpath exception.*"[emphasis mine]
> >>
> >> You can find the samples you're looking for (both pure Java
> >> applications, and those using JNI) in the folders containing BSD
> >> licensed demo and sample application programs.
> >>
> >> I can only assume that the issues you're having with the FAQ are
> >> based on an assumption that using or not using JNI makes a major
> >> difference in terms of the effect of the license, so I'd kindly
> >> suggest reading the license terms, and/or the FAQ and/or asking a
> >> legal professional for advice.
> >>
> >> cheers,
> >> dalibor topic
> >> --
> >> *******************************************************************
> >> Dalibor Topic Tel: [phone]
> >> Java F/OSS Ambassador AIM: robiladonaim
> >> Sun Microsystems GmbH Mobile: [phone]
> >> Nagelsweg 55 http://openjdk.java.net
> >> D-20097 Hamburg mailto:Dalibor.Topic@...
> >> 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
> >>
> >>
> >
> > _________________________________________________________________
> > Windows Live™: Keep your life in sync.
> > http://windowslive.com/explore?ocid=TXT_TAGLM_WL_BR_life_in_synch_062009
>

_________________________________________________________________
Lauren found her dream laptop. Find the PC that’s right for you.
http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290

[Kevin Regan]

I think the bottom line is that there is some confusion as to exactly what the OpenJDK license means.  This would definitely point to the need for Sun to add some clarifications and examples to the FAQ.  The previously suggested FAQ item on JNI would be a good start.

 

--Kevin
 

> Date: Wed, 8 Jul 2009 12:53:45 +0200
> Subject: Re: OpenJDK and JNI -- licensing
> From: volker.simonis@...
> To: aph@...
> CC: discuss@...; dalibor.topic@...
>
> I thought, GPL'd code can only use GPL'd code. Otherwise I could
> always write a wrapper which is GPL+exception in order to use any kind
> of code together with GPL'd code by means of that wrapper.
>
> On 7/8/09, Andrew Haley <aph@...> wrote:
> > Volker Simonis wrote:
> > > Yes, I understand that conflict. But the HotSpot library libjvm.so
> > > itself is build mostly from files which are pure GPL and some files
> > > (in particular "jni.h") which are GPL + class path exception).
> > >
> > > So how can "jni.cpp" (which is GPL only) include "jni.h" (which is GPL
> > > + class path) and finally be statically linked with other GPL only
> > > files into a GPL-only "libjvm.so"???
> >
> >
> > Why not? GPL'd code can use GPL+exception code. What makes you
> > think otherwise?
> >
> >
> > Andrew.
> >

_________________________________________________________________
Windows Live™ SkyDrive™: Get 25 GB of free online storage.
http://windowslive.com/online/skydrive?ocid=TXT_TAGLM_WL_SD_25GB_062009

[Martin Buchholz-3]

One fundamental queston is when something becomes a
"derived work".

The FSF has been known to strongly suggest that
linking two pieces of software creates a derived work,
but the FSF cannot decide that.

I imagine some lawyer at Sun thought as follows:

Whether an API is a published standard influences
whether or not a client of that API
is considered a separate work or not.
Most (but not all) of the interfaces to hotspot are
specified by a JCP standard (and that includes jni),
and this standard has multiple implementations,
so it is reasonable to presume that linking with
hotspot is not creating a separate program,
when not using the non-standard interfaces
(like sun.misc.Unsafe).  One can further presume
that one can use any interfaces for which the interface
specification file (e.g. a C header file) has the
Classpath exception.

In any case, it would be good for Sun to clarify its position.
In particular, engineers need to understand the policy
when creating a new source file.

Martin

On Wed, Jul 8, 2009 at 02:05, Florian Weimer<fweimer@...> wrote:

> * Volker Simonis:
>
>> My only point was that I don't think that Sun's interpretation of
>> "linking", "derived work" and "classpath exception" is in accordance
>> with the FSF view of these terms, especially in the case of the
>> HotSpot shared library which is build from files licensed under both
>> "pure" GPL and GPL plus classpath exception.
>
> There are two conflicting lines of thoughts regarding GPLed program
> loaders: The first one says that loaded programs are not subject to
> the loader's GPL license.  This is the stance taken by the Linux folks
> for their kernel.  The second one says that the loaded program has to
> be GPLed as well.  This one is sometimes cited in the Emacs Lisp
> context (meaning that anything which runs on Emacs has to be GPLed).
>
> So it's certainly a good idea for the copyright owners of such program
> loaders to clarify their position on this topic.
>
> --
> Florian Weimer                <fweimer@...>
> BFK edv-consulting GmbH       http://www.bfk.de/
> Kriegsstraße 100              tel: [phone]
> D-76133 Karlsruhe             fax: [phone]
>

[Florian Weimer-2]

* Martin Buchholz:

> Whether an API is a published standard influences whether or not a
> client of that API is considered a separate work or not.  Most (but
> not all) of the interfaces to hotspot are specified by a JCP
> standard (and that includes jni),

The publicly available JCP license does not permit deployment, only
development for evaluation purposes.  Things are even more complicated
if the API contains service loaders.  For instance, I think it's Sun's
intention that you aren't allowed to write a JDBC driver and
distribute it (without further restrictions) if you've obtained the
JDBC API spec from the jcp.org site.

So it's not clear to me if you can infer additional rights from the
existence of the JCP process.  Apparently, it was Sun's intent that
the main source for Java technology licensing was the JDK
distribution, and not the JCPs themselves.

> In any case, it would be good for Sun to clarify its position.
> In particular, engineers need to understand the policy
> when creating a new source file.

Right, especially since OpenJDK contains code which licensed under the
Apache 2.0 license (which is generally thought to be incompatible with
the GPL version 2).

--
Florian Weimer                <fweimer@...>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: [phone]
D-76133 Karlsruhe             fax: [phone]