How to interpret the Classpath-Exception?

[Volker Simonis]

Hi Clemens,

from my personal point of view, what you describe is not covered by the GPL+CPE.

GPL+CPE is intended to cover the "normal" use cases where you run a
Java application (even if it uses JNI code) on the OpenJDK without
"infecting" your code with the GPL. That's why all the OpenJDK code a
"normal" Java application will interface/interact with are covered by
the GPL+CPE (e.g. all the Java sources, most of the native class
library code and all the JNI/JVMTI headers). However, most of the
HotSpot sources (i.e. all the sources under src/hotspot) are only
covered by the GPL (without CPE). I doubt that you can port OpenJDK to
a new platform without touching the HotSpot sources.

One thing you could do however would be to use an alternative virtual
machine implementation like for example OpenJ9 which comes under a
less restrictive open source license. OpenJ9 is a clean room JVM
implementation which is available under either Eclipse or Apache
license [1] and uses the OpenJDK class library (without Hotspot) as
standard Java library implementation.

Regards,
Volker

[1] https://www.eclipse.org/openj9/oj9_faq.html

On Sat, Mar 23, 2019 at 11:27 AM Clemens Eisserer <linuxhippy at gmail.com> wrote:
>
>  Hi,
>
> To make it short - lets say someone (not me or anyone I am doing
> business with) would port OpenJDK to a new embedded OS (not using the
> Java or OpenJDK trademark) and does not (want to) open-source this new
> port.
> The argument against open-sourceing the OS specific code is, that
> thanks to OpenJDKs fine platform abstraction, the new code required to
> support the new OS would not touch any existing OpenJDK code but
> instead extend it in various places (by inheriting from predefined
> classes like GraphicsEnvironment, Graphics, etc and by implementing
> "native" functions).
>
> Is this actually considered legal by the GPL+classpath exception
> license? I read the classpath-exception up and down, but didn't come
> to a conclusion.
> I guess it all boils down to whether the OS-specific implementations
> count as "independent modules" as stated by the classpath exception:
> "permission to link this library with independent modules to produce
> an executable, regardless of the license terms of these independent
> modules,"
>
> Is this point of view valid or misinterpreting the license?
>
> Thanks & best regards, Clemens