How to interpret the Classpath-Exception?

[Volker Simonis]

On Mon, Mar 25, 2019 at 1:03 PM Mario Torre <neugens at redhat.com> wrote:
>
> 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.
>

I really can't understand why most people start to hyperventilate over
"legal/license" questions on OpenJDK mailing lists. This doesn't
usually happen even for the most weird  technical questions and a lot
of times people answer to such questions without being experts in the
corresponding areas or without the ambition of providing the ultimate
and single authoritative answer.

But for perfectly valid and reasonable legal/licensing questions (at
least from my point of view :) the questioner is usually heavily
criticized how he could ever dare to ask such a question and he's been
told to walk away.

If somebody has no answer to a technical question, he simply doesn't
answer. For legal questions it seems that a lot of people feel
empowered to answer why they (as well as everybody else on the list)
will not and can not answer.

If legal/licensing questions weren't relevant for the OpenJDK, we
would not have the need to provide a legal section right on our home
page [1]. But once it's there, I think it's valid to discuss such
topics in the same way we discuss every other topic. I'm perfectly
aware of the fact that providing "legal advice" [2] may be subject to
certain regulations in various countries. But that shouldn't hinder us
to "discuss" such topics here.

I think it is clear to everybody that nobody should base his business
decisions on information/opinions he received from an open source
projects mailing list. But that's also true for any other advice you
receive here. After all it's just a mailing list where everybody acts
in good faith and to his best knowledge.

Regards,
Volker

PS: I don't have the intention to start a indefinite, controversial
discussion so I won't answer to this thread any more. But I'll take
the liberty of answering to other legal questions on the OpenJDK
mailing lists in good faith and to the best of my knowledge :)

[1] http://openjdk.java.net/legal/
[2] https://en.wikipedia.org/wiki/Legal_advice

> 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