GPLv2 with classpath exception

Hi Denys, Guillaume,

It occurred to me that you might not be aware of the details of the
classpath exception clause of the OpenJDK and that both scala-native and
scalajs may be doing a lot of unnecessary work in a perceived attempt to
avoid distributing under the GPLv2.

This is the OpenJDK License:

  http://openjdk.java.net/legal/gplv2+ce.html

It is GPLv2 with some exceptions bolted on (trimmed for brevity, please
read the fuller version):

=======================================================================
As a special exception, the copyright holders of this library give you
permission to link this library with independent modules to produce an
executable, regardless of the license terms of these independent
modules, and to copy and distribute the resulting executable under terms
of your choice.

An independent module is a module which is not derived from or based on
this library.
=======================================================================

You can check the sources to java/lang/String.java to confirm that
Oracle designates typical standard library classes as subject to this
"exception clause".


So long as we agree that libraries and applications are "independent
modules" under this definition, there is no reason to set about
re-implementing the JDK. You can just use the OpenJDK implementation and
fully satisfy the OpenJDK license requirements.

Given that this license is applied to current Java and Scala
applications, compiled for and running on the JVM, I don't see why those
"independent modules" would suddenly stop becoming independent modules
just because they've been compiled to run natively. They are independent
because they can run on *any* implementation of the JDK (e.g. Oracle's
proprietary implementation).

There is a technical point to be aware of. My interpretation is that the
exception does not extend to static linking. So you'd have to create a
dynamic libjvm.so (released as GPLv2+ce) and dynamically link to it from
the executable. I'm sure dynamic linking is something you'd like to do
anyway, but taking this route you can free up your resources from
writing a JDK and instead focus on dynamic linking.


My main concern with the current legal strategy (rewriting the JDK from
the specs and reverse engineering based on behavour of the ORACLE /
OpenJDK implementations) is that ORACLE do not feel that it is fair use.
It doesn't matter if you feel it is fair use, or even if the courts in
the USA feel it is fair use, ORACLE do not. Their court case with Google
is proof of this stance, and even if it concludes in Google's favour,
there is no reason ORACLE will not pursue others for doing the same
thing.


BTW, incase you think I have alterior motives, I absolutely do not want
all scala-native / scalajs applications to be subject to the GPLv2. I am
a huge fan of the GPLv3 and it is incompatible with the GPLv2, so I'd
find myself unable to use scala-native or scalajs for my applications.


Somewhat related. I sent you a PR to clean up the wording and your
interpretation of the GPL, you may wish to have a look in more detail

  https://github.com/scala-native/scala-native/pull/560

I can send a similar one to scalajs when you're happy.

Note that in particular this line is incorrect: "JDKs are under a
GPL-based license which is not compatible with our BSD 3-clause
license". There is nothing incompatible about the GPL and the BSD,
indeed ENSIME is a combination of both. What you mean is that you want
to distribute software under a permissive license and including a GPL
component would require you to be copyleft. Incompatibility is a
different thing, it means the licenses actually conflict with each other
such that either of the licenses cannot be obliged anymore (e.g. GPLv2
and GPLv3 - they cannot be combined).