Change the JDK to use openjdk8-openj9
Closed this issue · 25 comments
Apache project will have issue using JDK licensed under oracle BCL or GNU GPL.
For docker image with JDK, we have to switch to use
https://hub.docker.com/r/adoptopenjdk/openjdk8-openj9/.
Is this also an issue if the mentioned alternative JDKs are not part of our release? We're moving to use a prebuilt docker image of OpenJDK. I'm wondering if this paragraph specifically applies here: https://www.apache.org/legal/resolved.html#platform
@markusthoemmes That is good question I am currently seeking the answer as well.
So far, my answer tends to be fine with Apache, because the docker image uses OpenJDK binaries that are built with Eclipse OpenJ9. License can be found here:
Licenses for the products installed within the images:
Eclipse OpenJ9: The project license is Eclipse Public License 2.0 and Apache License, Version 2.0 (you can choose), but the EPLv2 license has a secondary compatibility for the GPL v2 that is used by OpenJDK. You can combine the two projects and use them together (as OpenJDK's GPL v2 of course). The full license is documented in the LICENSE file.
For detailed information, please refer to https://hub.docker.com/r/adoptopenjdk/openjdk8-openj9/.
However, I do really need to confirm it with legal expert.
@markusthoemmes @houshengbo Some things that seem clear to me:
- We do not plan to distribute source code, only binary JVM/JDK libs.
- The intent of the Oracle Binary Code License Agreement (BCLA) is that "Oracle Java Standard Edition version 8 is still free as long as it is used for general purpose computing." (which includes JDK and JavaFx SDK).
- OpenJ9/J9 (equivalent by name now) does not get us the JDK; it is the byte code interpreter only (JVM) and does not (according to my source) include any libs (i.e., JDK) so it does not give us what we need. Given that, If we use Eclipse OpenJ9 we would likely be able to ref. their license just fine.
- The "Java community" sponsors distributions that carefully construct JDK+OpenJ9 distributions that have carefully compiled all parts of Java (various licenses) to assure that consumers that they have no onerous licensing problems here: https://adoptopenjdk.net/ (including Docker images.
- Quoting the site "AdoptOpenJDK provides prebuilt OpenJDK binaries from a fully open source set of build scripts and infrastructure. Looking for docker images? Pull them from our repository on dockerhub". BUT it should still be investigated IMO.
- Java experts put this together, but it does not provide us a license; but we still need to point to licenses for each comp. that they built and brought together. Note: it suprised me the reference Docker image (which may have come from this consortium) provides it under an Apache 2 license (see below).
- it seems (and need to confirm) that the docker image Vincent found (https://hub.docker.com/r/adoptopenjdk/openjdk8-openj9/) "seems" to be from that group and Docker hub lists it as Apache 2 license for the image only and has a long description of which says:
Eclipse OpenJ9: The project license is Eclipse Public License 2.0 and Apache License, Version 2.0 (you can choose), but the EPLv2 license has a secondary compatibility for the GPL v2 that is used by OpenJDK. You can combine the two projects and use them together (as OpenJDK's GPL v2 of course). The full license is documented in the LICENSE file.and references their LICENSE file which I have not gone thru.
regardless, we should seek to validate our binary packing/distribution decisions with Apache legal.
My inclination is to bring this issue up with our mentors via the PMC and have them help us get a read from Apache sources before doing any work around developer opinions. The first step IMO would be to have someone create a complete description of what we intend to package (JVM version, JDK/libs, etc.) to get the most precise answer on the first response.
@mrutkows Apache policy seems to raise caution of BCL:
BCL
Oracle's (originally Sun's) Binary Code License falls far short of the Open Source Definition, thereby violating the first criterion for license approval.
Oracle JDK does not get along with Apache.
@mrutkows in which way do we package JVM/JDK libraries?
The openwhisk-runtime-java docker image will not be useful to our users if it doesn't include a J2SE class library. So I don't see that switching the JVM runtime for licensing reasons is useful. No matter what JVM runtime we bundle, we will need the class libraries.
@markusthoemmes AFAIK, this discussion was started because the Java runtime's Docker image would be part of our project's (convenience binary) release that would have to consider distribution issues as that image would not be usable without them.
The release will only include the Dockerfile, not the Docker image - right?
@rabbah for the source code release, we would not be producing a binary (obviously) which would include no Java-related source code which is fine for that release phase (and all that is required for Apache graduation). IMO, this issue only arises if we intend to produce our own Docker images as part of a (convenience) binary release. We have been trying to prepare for both source and binary releases when preparing the LICENSE file.
Options exist; we can proceed with source release (and should) and assure that our LICENSE files clearly indicate which dependencies are source vs. binary (which has been discussed several times, but should look at the LICENSE template/wording we have today closely to assure this distinction is quite clear to any reader).
In the meantime, we should seek Apache guidance IMO if we still intend to produce a java runtime in the form of a Docker image. @houshengbo your thoughts?
This is the line downloading the oracle jdk
https://github.com/apache/incubator-openwhisk/blob/master/common/scala/Dockerfile#L44.
As long as we release binary or docker image, we depends on the oracle jdk.
curl --silent --location --retry 3 --header "Cookie: oraclelicense=accept-securebackup-cookie" \
http://download.oracle.com/otn-pub/java/jdk/"${VERSION}"u"${UPDATE}"-b"${BUILD}"/"${SIG}"/jdk-"${VERSION}"u"${UPDATE}"-linux-x64.tar.gz \
| tar xz -C /tmp && \
Given Scala's reliance on Java as a pre-req (i.e., it points to Oracle directly):
- https://www.scala-lang.org/download/
we may not be able to have binary releases.
@mrutkows -- Correct. The controller/invoker are in Scala, so any binary build will have multiple docker images that contain a JVM. I'd suggest looking to see how the Kafka and Zookeeper projects handle this. They are both apache projects with strong Java dependencies.
@dgrove-oss apparently, Kafka's LICENSE and NOTICE files are bolierplate (i.e., no listing of ANY license dependencies for source or binary at all). Although they clearly produce binaries as part of their tars and Vagrantfiles, etc.) and clearly up-front in their README state this pre-req:
You need to have [Gradle](http://www.gradle.org/installation) and
[Java](http://www.oracle.com/technetwork/java/javase/downloads/index.html) installed.
however, on their download page, they offer "source" and "binary" :
https://kafka.apache.org/downloads
and again, the LICENSE (in kafka_2.12-1.1.0.tgz) of the binary package/tar is "bolierplate" (no dependencies listed at all)!
the binary NOTICE file only has:
This distribution has a binary dependency on jersey, which is available under the CDDL
License. The source code of jersey can be found at https://github.com/jersey/jersey/.
Similarly, Zookeeper appears to only produce source code releases and its LICENSE and NOTICE reflect this (i.e., only "bundled" dependencies listed).
I noted that their GitHub LICENSE was bollerplate, whereas their TAR License had these additions:
This distribution bundles jline 0.9.94, which is available under the
2-clause BSD License. For details, see a copy of the license in
lib/jline-0.9.94.LICENSE.txt
This distribution bundles SLF4J 1.6.1, which is available under the MIT
License. For details, see a copy of the license in
lib/slf4j-1.6.1.LICENSE.txt
This distribution bundles a modified version of 'JZLib' as part of
Netty-3.7.0, which is available under the 3-clause BSD licence. For
details, see a copy of the licence in META-INF/license/LICENSE-jzlib.txt
as part of the Netty jar in lib/netty-3.7.0.Final.jar.
So there may be some automation to insert somewhere...
Their "how to release" instructions on their project Wiki also, indicate source code only.
The "official" images on DockerHub do not appear to be produced by the Apache project.
@dgrove-oss @houshengbo (see above license research on kafka and zookeeper projects).
It looks like for both these cases their "main" repos. appear to have all documentation focused on source code releases.
However, we see somehow that Kafka does provide binaries which, so far, I do not see how they are produced and of course they do not list any dependencies at all in their LICENSE filel (i.e., from their project page https://kafka.apache.org/downloads)
Of course, the significant difference to consider, when producing binaries, is "do we re-package/re-dist." (i.e., by providing a Docker image pre-installed) where they can simply tell others to "install this yourself".
Does the tool, with which binaries are created, matter when it comes to the license of the binary (given that the tool's license doesn't prohibit anything like that)? I.e. if we use OpenJDK to compile a binary jar for the OpenWhisk code, does that affect the license of the product?
From a dependency PoV, even a binary release like Kafka's is only dependent on some JRE + other binary deps. That shouldn't affect the product's license at all.
The only "binary" where we'd bundle a specific JRE/JDK is our docker images. Are those officially part of the release @mrutkows?
As for docker images: There's no official image for Kafka and the "official" image for Zookeeper is not part of the Apache project. https://github.com/31z4/zookeeper-docker
@markusthoemmes as per the Docker images published, I found the same (as noted/linked above)... It seems that packaging a "jar" is fine (not statically linked), we just cannot redistribute images (or anything that has the actual JRE/JDK. At least, that is my reading and is consistent with what we are seeing with other Apache projects.
Apache projects, like Kafka, Zookeeper, Casandra, etc, do not ship anything in JDK, though they depend on Java. They do not ship docker image depending on JDK either. Their binaries depend on JRE/JDK to compile, but that's fine.
Our OpenWhisk release, I mean the release of Docker image(which is one openwhisk's strengths of our platform), pull down the oracle JDK in Dockerfile, build it inside our image, etc. This may put us in peril, since Oracle BCL license of oracle JDK is not welcome in Apache. The oracle JDK is actually built in the image we are about to release. OpenWhisk is different from any other Java-based project in Apache. EVER!!
For source code release, we do not need to bother the Oracle license. This concern is raised for the release of docker images.
At this moment, the best way it can work out is that
Docker image of OpenJDK is based on Eclipse OpenJ9: The project license is Eclipse Public License 2.0 and Apache License, Version 2.0(https://hub.docker.com/r/adoptopenjdk/openjdk8-openj9/), but we need to verify if there is still any risk left.
If it is safe, use "FROM adoptopenjdk/openjdk8-openj9:jdk8u162-b12_openj9-0.8.0" in Dockfile, if it suffices for openwhisk.
OpenJDK itself is licensed under "GNU General Public License, version 2,
with the Classpath Exception"(http://openjdk.java.net/legal/gplv2+ce.html), which is not friendly to Apache as well. We should avoid packaging and building anything on top of it.
Just had conversation with IBM's expert on Apache Harmony and AdoptOpenJSDK project and he said he believed we should have no problems if we either use the adopt image if we choose to build our own image using the OpenJ9-OpenJDK from https://adoptopenjdk.net/ (with or without the HotSpot JIT). He is also connecting me with Tim Ellison at Apache (also worked on Harmony and now on Adopt) to confirm his opinion and perhaps get an Apache point-of-view.
Either way, we should plan to use the OpenJDK/J9 to ever have a hope of releasing image binaries.
Quoting from the adoptopenjdk license file (https://hub.docker.com/r/adoptopenjdk/openjdk8-openj9/).
The Dockerfiles and associated scripts are licensed under the Apache License, Version 2.0.
Licenses for the products installed within the images:
Eclipse OpenJ9 + OpenJDK: The combined works license is GNU GPL v2 with Classpath Exception.As with all Docker images, other software is likely to be included, which might be under other licenses (such as Bash, etc from the base distribution, along with any direct or indirect dependencies of the primary software being contained).
As for any pre-built image usage, it is the image user's responsibility to ensure that any use of this image complies with any relevant licenses for all software contained within.
In other words, this Dockerfile is just like almost any other non-trivial Docker file. The produced images of course contains software under a variety of licenses because the real world is messy. I'm missing why this is a particular problem (vs for example an image that contains bash, which is GPL3 https://www.gnu.org/software/bash/).
Good one @dgrove-oss! Didn't think about all the other stuff in a docker image. I think its illusionary to have a docker image with no GPL software in it, so why bother about the JDK specifically?