Does Running Java on Docker Containers Violate Agreements?
In a recent blog post Henn Idan raised an issue that using Oracle Java in containers could be violating the Oracle licensing agreements. This was raised in response to an initial tweet recommending a recompiled version of Java for Alpine Linux to which Ben Evans suggested this was an express violation of the Oracle license.
Although OpenJDK is available under the GPL, the OracleJDK compiled binaries that are available for download from java.com have a different binary license. Since Oracle owns the copyright to the code, they are able to release versions that aren't under the GPL – and the JRE that comes from Oracle also includes certain technologies like the Applet plug-in and Java WebStart which are used by companies to launch GUIs in a platform-independent manner. It also includes features such as Flight Recorder and Mission Control that are free for development use but require additional licenses for production use.
The Oracle Binary Code License Agreement for Java SE comes with a license to use the product (either the JDK or the JRE):
2. LICENSE TO USE. Subject to the terms and conditions of this Agreement including, but not limited to, the Java Technology Restrictions of the Supplemental License Terms, Oracle grants you a non-exclusive, non-transferable, limited license without license fees to reproduce and use internally the Software complete and unmodified for the sole purpose of running Programs.
Since this license is non-transferrable, it does not grant the ability to distribute software, nor does it allow for those to whom the software has been distributed to use it.
There is an additional supplemental license term which gives some limited rights to redistribute the software:
C. LICENSE TO DISTRIBUTE SOFTWARE. Subject to the terms and conditions of this Agreement and restrictions and exceptions set forth in the README File, including, but not limited to the Java Technology Restrictions and Limitations on Redistribution of these Supplemental Terms, 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, (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software, (iv) you do not remove or alter any proprietary legends or notices contained in the Software, (v) you only distribute the Software subject to a license agreement that: (a) is a complete, unmodified reproduction of this Agreement; or (b) protects Oracle's interests consistent with the terms contained in this Agreement and that includes the notice set forth in Section H, and (vi) you agree to defend and indemnify Oracle and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. The license set forth in this Section C does not extend to the Software identified in Section G.
Apart from the liability and indemnification (which may be of concern to some) the license itself allows the Java technology to be used for the sole purpose of running the programs (and, for example, that the programs aren't just a simple Java launcher application). So if the Java runtime was distributed in conjunction with a product that might be acceptable; but in the case of Docker containers, when the Java runtime is in a different container image from the Java application itself, that may not be possible under these terms.
(The Section G defines restrictions on security patches that have been provided by Oracle Premier Support and is mentioned for reference only, as it does not affect the legitimacy of the standard Java redistribution itself. There's even a Section E that defines publishers the rights to include JDK on electronic media with printed books or magazines; remember when printed magazines had CDs on them? Remember printed magazines, or for that matter, CDs?)
However, there is an additional supplemental term that permits distributing redistributables:
D. LICENSE TO DISTRIBUTE REDISTRIBUTABLES. Subject to the terms and conditions of this Agreement and restrictions and exceptions set forth in the README File, including but not limited to the Java Technology Restrictions and Limitations on Redistribution of these Supplemental Terms, Oracle grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute those files specifically identified as redistributable in the README File ("Redistributables") provided that: (i) you distribute the Redistributables complete and unmodified, and only bundled as part of Programs, (ii) the Programs add significant and primary functionality to the Redistributables, (iii) you do not distribute additional software intended to supersede any component(s) of the Redistributables (unless otherwise specified in the applicable README File), (iv) you do not remove or alter any proprietary legends or notices contained in or on the Redistributables, (v) you only distribute the Redistributables pursuant to a license agreement that: (a) is a complete, unmodified reproduction of this Agreement; or (b) protects Oracle's interests consistent with the terms contained in the Agreement and includes the notice set forth in Section H, (vi) you agree to defend and indemnify Oracle and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. The license set forth in this Section D does not extend to the Software identified in Section G.
Oracle's README file contains a reference to Oracle's website, that contains links to different README files. (The fact that they are not distributed or part of the JDK or JRE may be a concern to some, since there is no traceability as to the content of the README file over time.) The current version for JDK 8 has a section on redistribution for released versions (beta and pre-release versions may not be redistributed):
You may reproduce and distribute the Software (and also portions of Software identified below as Redistributable), provided that you comply with the terms and conditions of the Oracle Binary Code License Agreement for the Java SE Platform Products.
The term "vendors" used here refers to licensees, developers, and independent software vendors (ISVs) who license and distribute the Java Runtime Environment (JRE) with their programs.
Vendors must follow the terms of the Oracle Binary Code License Agreement for the Java SE Platform Products.
There are separate required and optional files in the distribution for both the JDK and the JRE:
Required vs. Optional Files
The files that make up the Java Runtime Environment (JRE) are divided into two categories: required and optional. Optional files may be excluded from redistributions of the JRE at the vendor's discretion.
Please refer to the JRE Readme for details of which files are required and which files are optional when distributing a JRE.
The JRE Readme provides rights to reproduce and distribute versions (and portions) of the software under the Oracle Binary Code License. For example, JavaFX may be excluded, as may the contents of
jre/ext. All non-optional files are required files, and must be distributed with the JRE; the JDK files must only be distributed in conjunction with a JRE.
These files are described in terms of the JDK and JRE version 8 and below. The reorganisation of JDK and JRE version 9 and above will result in a different agreement about what may be excluded or must be included. Some files, such as the cacerts certificate file, can be amended in order to keep up-to-date with changing certificates.
Java also ships with a limited form of security with 40-bit key strength, widely assumed to be trivially broken and the target of several degrade attacks (such as BEAST and POODLE) but can be upgraded using the unlimited strength cryptography upgrade. However, it appears that these may not be redistributed but require the user to download them directly:
An unlimited strength version of these files indicating no restrictions on cryptographic strengths is available on the JDK web site for those living in eligible countries. Those living in eligible countries may download the unlimited strength version and replace the strong cryptography jar files with the unlimited strength files.
Since it's likely that most modern applications will require a sane level of encryption out of the box, even if the rest of the environment could be redistributed the lack of security might be a significant issue. This may also be an issue with builds of the OpenJDK, separately from OracleJDK.
There are builds available for OpenJDK which suggests running
sudo apt-get install openjdk-8-jre or
su -c "yum install java-1.8.0-openjdk" from unspecified remote repositories. In Debian (and presumably Ubuntu's) case, the latest version is openjdk-7, although openjdk-8 is available in testing and openjdk-9 is available in experimental. These builds aren't created by Oracle and therefore don't have any support; in addition, it's not necessarily clear what other patches have been applied or which tags were used to build from them.
Henn Idan describes this as Mystery Meat – you don't know what you're getting, and you don't know its origin or history. Gil Tene, founder of Azul Systems, followed up and said that provided that the Java distribution has been tested with the Java Testing Compatibility Kit (TCK) it should be safe to use. He highlighted that Azul's builds of Open JDK come with a certificate that confirms which version the build was performed from and an assertion that it passes the TCK. Azul is one of several TCK licensees for Java, and the builds that Red Hat distributes as part of their Enterprise Linux (RHEL) distro, for example, are also TCK compliance tested.
One of the problems highlighted in the Henn Idan blog post is the fact that the Docker openjdk image is built using the version from Debian unstable, since OpenJDK 8 is not yet available in a stable release. That would suggest anyone who has based a Docker image from this base repository has been using a release that explicitly has not been tested by Debian for Java conformance or any history. Since Debian has not made Java 8 available they are not likely to be interested in certification at this stage; however, the docker/openjdk repository appears to be the canonically available one from Docker. Regardless of the issues raised earlier regarding the redistribution of JDK parts, the fact that the canonical Docker image is based on a known unstable version from Debian should be a concern.
Finally, questions were raised about the legality of writing or using Docker files that download Oracle's JDK automatically. By setting a cookie value to represent clicking the "I agree" to the Oracle Java download it is possible to automate the download and installation of the JDK (or JRE) onto a target system. Although the Docker file itself isn't against Oracle's licensing rights, the downloaded image does not have redistribution rights. Since the Docker client will build an image snapshot based on the result of this command's execution, but before the application's files have been laid down, and then potentially make that image available for binary download elsewhere (for example, Docker Hub), that resulting image may itself be infringing. Since these rights are not necessarily transferrable, anyone then using such an Oracle image may be in violation of Oracle's copyrights.
You also represent and warrant that you do not intend to distribute the software in a manner that is not compliant with relevant export control laws or regulations administered by the U.S. Commerce Department, OFAC, or any other government agency.
According to GNU/FSF this wording "is not a violation of the GPL. Those distributors (almost all of whom are commercial businesses selling free software distributions and related services) are trying to reduce their own legal risks, not to control your behavior." However since there are no ways of enforcing this from builds based on Docker Hub it may not be possible to use images distributed in that way. It's also not clear whether these terms are in conflict with OpenJDK's GPL, which states:
You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
At present there have been no publicly identified letters for copyright holders in the on-going Java debate, but with the rise of containers, the distribution of software becoming more modular and separate distribution for container layers, it is clear that distribution of these images may open both the users and the publishers of these images to public repositories to legal action. Those wishing to avoid this should seek independent legal advice.
InfoQ has summarised this information as is, and this should not be considered legal advice. Further corrections and updates to this post may occur as the situation changes or is re-evaluated. We asked Oracle to comment on this article but did not receive a response at the time of publication. We will update the article if we hear from them.
Last updated: 24th March 2016 - amended to clarify the situation with regards export warranties and terms-of-use on the Zulu site
Please not discredit Debian and other Linux distributions
Re: Please not discredit Debian and other Linux distributions
You are misreading the article. The *Docker Image* is built from the version of openjdk-8 in the Debian unstable repository:
One of the problems highlighted in the Henn Idan blog post is the fact that the Docker openjdk image is built using the version from Debian unstable
The "image is built" and not "openjdk is built" is the important distinction here.
This article is incredibly misleasing
The headline asks: "Does Running Java on Docker Containers Violate Agreements?" yet the content of the article is about redistribution of Java via container. Second, Charles seems to think the only game in town in the Debian container and cites true points about Java and Debian and it is exactly the reason The Official Java repo on Docker Hub uses Ubuntu and Alpine instead of Debian:
On the topic of support, stating that OpenJDK is unsupported is slightly disingenuous. Yes, Oracle does not support OpenJDK but community support is available. The builds are actively developed and maintained. If you ever got a rate sheet from Oracle and saw the outrageous prices they charge for Java support, it's obvious why many don't pay for Java support.
The mystery meat argument is also bogus. Yes, if you run apt-get install openjdk-8, you're getting the latest version in the repository.That's true of ANY piece of software retrieved via package manager You can make the same exact arguments for other software software as well, such as python, ruby whatever. This is not a problem with OpenJDK or Docker, but rather apt and yum. With that said, why single out OpenJDK here?
There's a lot of FUD and conjecture in this article, which is surprising as there's a lot of great articles on InfoQ. This is not one of those.
Re: This article is incredibly misleasing
Re: This article is incredibly misleasing
But it is the case that:
a) any Docker image that redistributes the Oracle JRE is in violation of Oracle's proprietary license. Needless to say we have done off-the-record fact checks on this, but weren’t able to get anyone to go on the record at the time of publication.
b) If you use OpenJDK you can end up with an unknown version of Java - specifically whatever Debian or Canonical happened to pull from the source tree and ship, which in some cases have been automated top-of-tree pulls before OpenJDK code for a version was even complete or released. Again in the research we did for the piece we found specific examples where this was the case. See for example:
As to your point about why we highlight Zulu we did so because every Zulu binary undergoes full Java SE TCK testing to verify compliance and compatibility with the applicable Java SE version - and they come with an actual certificate that tells you exactly what you are getting, like this one:
Plus their license allows for redistribution.
I sincerely hope that we’ll see responsible OpenJDK builds from everywhere in future; there’s no reason I can see why this shouldn’t happen, but it won’t if we keep ignoring the fact that their is a problem here.
No problem with Red Hat's OpenJDK builds
Re: Please not discredit Debian and other Linux distributions
>... Gil Tene's FUD, which you are reporting, uses this perfectly normal
> situation to tell that openjdk builds from Debian should not be trusted
I'm not sure why you think this "FUD" is mine. I didn't write either this article or the other. I just strongly agree with them. I (along with many others) am trying to stop the FUD *against* OpenJDK. It's the irresponsible, mis-labeled, and used-massively-by-unsuspecting-people JDK builds that are creating that FUD. As a member of the Java community (and of the JCP EC), I feel that this FUD is hurting us all, and eroding both OpenJDK's and Java's reputation for stability and compatibility.
And if you are claiming something like "there is nothing wrong with labeling some software any way I want to, including with the same label as that a future production JDK will have. The end user should be responsible for checking the pedigree of their actual bits, rather than believe what them bits I build report when asked", it's you who are spreading the FUD about OpenJDK that we are trying to prevent.
There is a wide and long standing consensus in the java-using community that bad & mislabeled java versions are a bad idea. Java has a strong track record of compatibility and compliance. The actual specification is captured in JSRs via the JCP, and things that call themselves "java" verify compatibility and compliance with that specification via well defined and very detailed TCKs (which are used to verify the actual binary artifacts of the build are good). This expectation of quality and compatibility has served the community well for 20 years. All responsible JDK/JRE distributions through history (including responsible builds of OpenJDK) have kept to these rules, and avoided mislabeling themselves as "java" unless they meet the spec and testing criteria. When preliminary or experimental JDKs are not built from actually released code, and are not verified as spec-compliant, they clearly self identify as such (including in their java -version output). E.g. current OpenJDK 9 early access builds do not report as OpenJDK 9u40. Their version strings are a clear warning of their in-flux state.
Unfortunately, there have been cracks in this responsible behavior in the past couple of years, and these cracks are contributing to the FUD that "OpenJDK is not real java". There are many examples of this happening, but there is a specific one that is well documented, and exposed a vast number of docker users of Java 8 for a period of at least 6 months. It's probably what drove these articles (since they focused on the issue in the context of Docker).
To follow the specific thread of how bad this stuff gets, you can start with the following article (from Nov. 2014), which led many people to use a bad version of Java 8 while thinking it is a production-worthy, good JDK: blog.giantswarm.io/getting-started-with-java-de...
The poor and unsuspecting readers of this article (along with the unsuspecting writers, I'm sure) were misled by the JDK bits chosen to be the Official Docker image for Java 8 at the time. they thought that by basing their docker images with Docker's official, and "trusted" "FROM java:8", they were getting a blessed Java SE 8 JDK. They weren't. What they were (and maybe still are) actually running was an untested, compiled-from-top-of-tree-of-a-yet-to-be-released-version thing that was not OpenJDK 8. The bits were not only were the bits from a bad and unstable source, they were mislabeled as "OpenJDK 8u40" and reported as such in their "java -version" output, so users had no indication that they were running a bd JDK. This situation continued at least until March 2015 (a full year after OpenJDK 8 was GA'ed, and well into the period were developers were writing to it's new features and delaying it in production)
Where did those bad bits come from? They cam from a debian experimental build of OpenJDK 8u40 (which was being distributed at least 6 months before OpenJDK 8u40's code was ever complete and released). The fact that an experimental build of OpenJDK 8u40 was being created and distributed is not in itself a problem. The fact that is was not labeled as experimental is. And the fact that people seem to be arguing that this practice is fine (and should presumably continue) is even worse. If this experimental OpenJDK 8u40 build was clearly labeled as experimental (including in it's java -version output), this discussion would not be happening. That's because the folks running it would immediately know it's not a stable JDK, and move on. And the folks writing the "Getting started with Java on Docker" article would not have been misled by the "FROM java:8" recommendation. And the folks actually building the "FROM java:8" thing at Docker would not have been misled by the "java -version" output, and would have probably called their thing "FROM java:8-experimental" to make it clear to everyone. But that didn't happen. Docker didn't base their official Java:8 image on the stable OpenJDK 8u25 GA'ed builds that were available (or the (or 8u5, 8u11, 8u20 that were available before that). They based it on 8u40, which unfortunately did not really exist.
Unfortunately, the mislabeling of JDK bits that made it out into the world caused many people to run a JDK version that was not really what they though it was. And now we have a mess on our hands with people suspecting any openjdk build they see, "because they lie". Well at least some of them lied, and since we can't tell which ones....
Unlike the commercial Java builds (where these rules are enforced with licenses and trademarks, and no non-TCK tested thing gets released in a mislabeled way), OpenJDK's good name depends on the responsibility of the people building binary JDKs from it's sources and *sharing* those binaries with others. To keep (or to regain) that good name, I implore anyone who builds openjdk binaries to make sure that the JDK they produce is labeled correctly. All you have to do is label it as "experimental" (or "untested", or "unstable", or whatever), and these problems wouldn't occur.
Azul makes Zulu builds of OpenJDK freely available (and freely redistributable), and we responsibly build them and certify them as such. But we are certainly not alone. There are others who also build good OpenJDK JDKs, and test them to verify that they really are good. As many of the community members can attest, I've been advocating strongly (both at the EC and elsewhere) to secure and ensure easy access to the OpenJDK TCKs for anyone wanting to responsibly build good JDKs. Many people and companies have signed up to do that (openjdk.java.net/groups/conformance/JckAccess/j...), and I am hoping the list will keep growing. It is my hope that all distros will move to responsible labeling and responsible testing. And the sooner the better.
But it's not lack of access to the TCKs that is our greatest obstacle (yes, it could be made better, but it's currently free for anyone wanting to build from OpenJDK). It's arguments against proper labeling and proper testing that worry me most. The "we don't have to label and test our stuff properly, let the end-users worry about the details" approach is hurting Java, and hurting OpenJDK. So is the "they tested it against 1,200 oss apps, so they would have seen problems if they existed, they don't need to run those silly TCKs" approach. There is probably no way for us (as a community) to enforce responsible building of OpenJDK, but I'm appealing to people's good nature to stop hurting java and openjdk by making up their own rules.
Re: No problem with Red Hat's OpenJDK builds
> Fully Open Source, fully TCK certified, and available to run in containers.
Agreed! I wish everyone else was willing to do the same.
Re: This article is incredibly misleasing
> The mystery meat argument is also bogus. Yes, if you run apt-get install
> openjdk-8, you're getting the latest version in the repository. That's true
> of ANY piece of software retrieved via package manager You can make
> the same exact arguments for other software software as well, ...
> ... With that said, why single out OpenJDK here?
It's the fact that the latest thing in [at least some] repositories that claim to be stable, blessed, trusted, or "official" is [at least some of the time] a bad thing. That makes the Mystery Meat label a good one.
As a specific example: between Sep. 2014 and March 2015, if you used the Official Docker image for Java 8 and did this:
docker run java:8 java -version
You got something that reported as "openjdk 8u40". What you were running was (most likely) an untested, unfinished, still-full-of-bugs in-development top-of-tree snapshot. But you had no way to tell (other than digging up the actual pedigree of the meat bits you were using), because the the version label was lying to your face. Now, if you were savvy enough to go back and see that 8u40 made no sense, because it was not yet released (it was only released in March 2015), you may have caught that. But most people would (and did) just accept it as "the latest good java", and ran on it.
This happened. And If that's not Mystery Meat, I don't know what is.
Saying "that's a problem with apt-get" (or with docker run) about official images or repos is like saying "that's a problem with buying meat from the butcher at a well-regarded grocery store. When the well regarded store [sometimes] sells you mystery meat with a "good meat" label, it hurts not just store's reputation, it makes everyone suspect all the stores.
And before someone again starts with the "but the official [not sid] debian repo was good" stories, let me point out that (at least according to the OpenJDK TCK signatories list at the time) noone at debian had access to TCKs during those dates... This seems to have changed in the recent past, and some of the debian folks are now OpenJDK TCK signatories, so maybe things are getting better. I'm certainly hoping they actually use them on the actual binary builds that they put in their actual official repos.
"You also represent and warrant that you do not intend to distribute the software in a manner that is not compliant with relevant export control laws or regulations administered by the U.S. Commerce Department, OFAC, or any other government agency."
See www.gnu.org/licenses/gpl-faq.en.html#ExportWarr... for a discussion of why (according to GNU/FSF) this language is not in conflict.
Re: This article is incredibly misleasing
Re: What does Oracle say?
Re: What does Oracle say?
See this for more information: www.java.com/en/download/faq/distribution.xml
pretty good article and discussion
Re: What does Oracle say?
This is all a tempest in a teapot, though, if Docker just uses a TCK-tested build of OpenJDK (like the excellent packages from Red Hat and Azul). Nobody's being forced to use Oracle's builds unless you want support or a handful of closed-source features...and then you're going to pay for it anyway.