Using Oracle Java with Docker might put you in legal liability. Why?
The relationship between Oracle and Linux had its ups and downs. Major distributions require users to jump through a few more hoops in order to use Oracle’s Java. If you’re using Docker, the plot thickens, and you might be breaking the law by violating Oracle’s License Agreement without even knowing it. In this post we will help you get the full picture and make an informed decision about your use of Java and Docker. Let’s dig in.
How did Java become an issue on Linux?
Oracle Java is not available on most Linux distributions, due to the fact that Oracle retired the “Operating System Distributor License for Java” (JDL). This means that standard software repositories lack built-in Java and Oracle Java. Users can still use Oracle’s JDK, when all they have to do is download it themselves, instead of getting it directly from the repository. However, when reading section C of Oracle’s License Agreement we’ve encountered the following text:
“Oracle grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs…”
While Oracle JDK is free to download and free for commercial use, the agreement raises a question when it comes to redistribution. A deeper dive into the JDK readme file indicates that you can only distribute unmodified versions of the JRE and JDK, as long as you follow the instructions of keeping the required files.
This requirement lead to that most Linux distributions are unwilling to redistribute Oracle Java on their own channels. Debian users are able to download the Oracle Java tar manually from Oracle, and use java-package to install it, CentOS requires users to download the rpm provided from Oracle at java.com, so they’ll be able to accept the license manually, while RedHat provides instructions on how to add a repo that is maintained by Oracle.
“Mystery meat” OpenJDK builds
In one of our latest posts we showed you how to make your Docker 7x lighter with Alpine Linux, using a smaller Java image. We received a comment on Twitter that caught our attention. The comment came from Ben Evans, co-founder and technical fellow at jClarity, Java editor at infoQ and author at O’Reilly Media. Ben shed some light on Oracle’s License Agreement and OpenJDK builds used in popular Java Docker images.
https://twitter.com/kittylyst/status/692372191069999104
Ben further explained that the issue with Debian or Ubuntu OpenJDK builds is that they do not correspond to any known version of Java; “It’s therefore almost impossible to know what commit on the source tree the Debian / Ubuntu binaries correspond to.”
Ben added that the binaries haven’t been through any of the compatibility and conformance testing that certified Java binaries (from Oracle, Red Hat or Azul) have been subjected to.
“The time of most open source developers is a pretty scarce quantity, and as a result I expect very few OpenJDK devs would be interested in tracking down or reproducing a bug that an end user has on one of these “mystery meat” builds, as there’s every chance that the reported bug might have been fixed before the next release branch.”
No redistribution? No Docker
You’ll find that Oracle’s License Agreement is very easy to break, especially if you’re downloading your Java files from someone else. This is where Docker rises as another part of an already tangled relationship: the redistribution section in the agreement has a direct affect on Docker images that use a compiled version of Java.
To put it in simple terms, if you’re downloading a Dockerfile that contains Oracle’s JDK, you’re not holding up your part in the agreement. The image might not contain the required files from Oracle, or whoever built it could have inserted a cookie that automatically approves Oracle’s Terms and Conditions for you. When you download Oracle’s JDK from the official website, you are required to manually click a box to approve the terms and conditions. By adding the cookie, the user is unaware of the terms or of his need to approve them.
What you’re about to see is probably illegal. Don’t try this at home:
# Download and unarchive Java
RUN mkdir /opt && curl -jksSLH "Cookie: oraclelicense=accept-securebackup-cookie"\
http://download.oracle.com/otn-pub/java/jdk/7u79-b15/jdk-7u79-linux-x64.tar.gz \
| tar -xzf - -C /opt &&\
ln -s /opt/jdk1.7.0_79 /opt/jdk &&\
rm -rf /opt/jdk/*src.zip \
/opt/jdk/lib/missioncontrol \
/opt/jdk/lib/visualvm \
/opt/jdk/lib/*javafx* \
/opt/jdk/jre/lib/plugin.jar \
/opt/jdk/jre/lib/ext/jfxrt.jar \
/opt/jdk/jre/bin/javaws \
/opt/jdk/jre/lib/javaws.jar \
/opt/jdk/jre/lib/desktop \
/opt/jdk/jre/plugin \
/opt/jdk/jre/lib/deploy* \
/opt/jdk/jre/lib/*javafx* \
/opt/jdk/jre/lib/*jfx* \
/opt/jdk/jre/lib/amd64/libdecora_sse.so \
/opt/jdk/jre/lib/amd64/libprism_*.so \
/opt/jdk/jre/lib/amd64/libfxplugins.so \
/opt/jdk/jre/lib/amd64/libglass.so \
/opt/jdk/jre/lib/amd64/libgstreamer-lite.so \
/opt/jdk/jre/lib/amd64/libjavafx*.so \
/opt/jdk/jre/lib/amd64/libjfx*.so \
&& addgroup -g 999 app && adduser -D -G app -s /bin/false -u 999 app \
&& rm -rf /tmp/* \
&& rm -rf /var/cache/apk/* \
&& echo 'hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4' >> /etc/nsswitch.confAs mentioned above, this code contains 2 major issues:
- The cookie that overrides your need to approve the license.
- Removal of several elements from the installation package (In order to minimize the disk footprint of a Docker image)
Not very Oracle-license-friendly, is it?
How can you stay a law-abiding Java user?
You have 2 options:
- Keep doing whatever you’re doing. This means that you might not follow Oracle’s license. However, it worked for you up until now, and we all know old habits die hard and you probably won’t start re-compiling everything from scratch.
- Switch to OpenJDK. A lot of users already use the open sourced Java option, and you’ll be happy to read that the user license agreement is much more friendly and basic:
“By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software–to make sure the software is free for all its users.”
When choosing the second option, you should take into account that some OpenJDK images are unsupported by the community, and they may contain “in between” Java versions that are not officially released yet.
If you’re not sure where to start, you might want to choose RedHat IcedTea, which is recommended by the Free Software Foundation, or Azul System Zulu.
Final Thoughts
Now you’re facing the tough question: what to do/choose? Some developers would choose the OpenJDK community, thanks to the ability to modify, change and add elements they need in order to make their code work. But as Ben mentioned before, when using OpenJDK you might find yourself trying to catch a bug on a “mystery build” – that isn’t even your fault.
The choice is all yours. We all know that terms of agreements never stopped anyone from using a certain product, and we’re sure it’s not going to stop you now. We can only lay out the facts and options, so you’ll know what to look into when choosing the image for your next project.
| Reference: | Running Java on Docker? You’re Breaking the Law from our JCG partner Henn Idan at the Takipi blog. |
