How to interpret the Classpath-Exception?

[Mario Torre]

On Mon, Mar 25, 2019 at 11:25 AM Volker Simonis
<volker.simonis at gmail.com> wrote:
>
> Hi Clemens,
>
> from my personal point of view, what you describe is not covered by the GPL+CPE.

But that's the problem right there ;)

"personal point" isn't a legal thingy.

I think we should move this discussion elsewhere.

Cheers,
Mario

> 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



-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898