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, 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.

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 Docker image 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:

As 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.

I write about Java, Scala and everything in between. Lover of gadgets, apps, technology and tea.
  • hutchike

    So you’re saying if someone doesn’t disable the cookie, and doesn’t remove any Java distro files, then they’re fine using it in Docker and will not have broken any Oracle license terms?

    • Bruno Souza

      The cookie referenced in the article is basically the “I accept” for you to download Oracle’s JDK. IANL, but I do believe that even if you use some automated script to download Oracle’s JDK, you are implicitly accepting the license.

      Now, the issue that the article highlights is that if you create a Docker Image, and you publish it to Docker Hub, you are effectively redistributing Oracle’s JDK. THAT redistribution is what the license (that you one way or another, accepted by downloading the binaries from Oracle) does not allow you to do.

      So, if you use a Dockerfile, and you build your own image, you should be fine. If you remove things, but this is for your own use, you pretty much should be fine also… But if you redistribute this image to someone else (your customers, your partners or on Docker Hub), then you are breaking the license.

    • Henn Idan

      Thanks for the comment for Hutchike, glad to see Bruno already answered your question. Retribution still remans an issue even if you play by the rules 🙂

  • Gil Tene

    Great Post! and I love the term “Mystery Meat” as it applies to untested and uncertain builds of OpenJDK (which in some case in the past have come from automated top-of-tree pulls before OpenJDK code for a version was even complete or released). It is unfortunate that some of these are placed out where people run into them and potentially get indigestion. It is even more unfortunate that they are often named “openjdk”, confusing folks about what that actually means.

    In this context, I’d like to highlight the Zulu OpenJDK builds. Zulu builds are here to cover exactly the concerns raised in this post: Licensing (including the ability to redistribute the JDK binary), and “Mystery Meat?” questions. Given the context, it would probably be good to mention Zulu by name in your post, and link to so people can find it. Right after the “Mystery Meat” discussion would probably be a good place ;-).

    Zulu (see is a trusted, certified, compatible, and compliant build of OpenJDK. It is available for pretty much any Linux platform, as well as for Mac and for Windows. We also have it up on the Docker hub. , so it’s very docker friendly.

    And Zulu is not only free to download and pull: It is freely redistributable. That’s the whole point. It’s a non-mystery-meat, free to redistribute, no-need-to-skirt-legal-stuff JDK that fits docker like a glove. And you can trust it.

    Why can you trust it? Because at Azul, every Zulu binary (not just the OpenJDK source it is built from) undergoes full Java SE TCK testing to verify compliance and compatibility with the applicable Java SE version. And we beat it up in QA to make sure it actually works on the target platforms and the wide range of apps we test with. And then, with all that done, we generate a certificate that matches the checksum of the actual binary thing you download or pull form one of our repos.

    So each Zulu OpenJDK binary comes with an actual “This is NOT Mystery Meat” certificate.

    • anapsix

      I wonder why Debian doesn’t use it as default jre/jdk..
      Any downsides to Zulu?

      • Gil Tene

        Yes, I work for Azul. (You got the company right, but the title wrong. I’m the CTO). And I’m proud of it. But Azul is not the only responsible maker of OpenJDK binaries. I think that there are plenty of good OpenJDK builds out there that are built by responsible folks who spend the time to us the TCKs and release JDKs the way they were meant to be released. RedHat is one great example, and they deserve a positive mention in the “How can you stay a law-abiding Java user” potion above just like Zulu does. There are lots of others on the list if OpenJDK-TCK-capable folks ( who have as well, and pretty much anyone else who wants to put in the effort can. Zulu is simply (IMO) the easiest one to get across most platforms (Linux/Mac/Windows).

        As to why Debian doesn’t use Zulu as it’s default JDK (or use a binary build by some other responsible team that tests it with TCKs, or get the TCKs for their own builds and actually use them): I too wonder about that from time to time. Maybe if enough people ask about it…

        When it comes to the “Mystery Meat” label: I think it is a great analogy, and a well deserved label for some OpenJDK binaries. If people are offended by it, they should spend more effort on labeling their code as “untested and unfinished”, or qualifying their code the way JDKs are supposed to be qualified so the label wouldn’t be needed.

        For an example of where the label fits perfectly, we can look at a specific Debian practice: Debian repositories included something labeled as 8u40 well before the OpenJDK 8u40 code for that major update version was done. If you said “apt-get install openjdk-8” (just 8. not even asking for 8u40), at any point in time between Sep. 2014 and March 2015, that’s what you got. That was java 8 on Denian. Period. And that was when a perfectly stable OpenJDK 8u25 was available (and should have been the one delivered). OpenJDK 8u40 was not released until March of 2015. So if you ran an “up to date” java 8 on debian during that time, you were eating bad mystery meat for six months.

        Unless you think OpenJDK folks were just twiddling it’s thumbs on 8u40 fixes in those 6+ months, or that all those bugs that were fixed were just in the documentation, Debian’s java8 was clearly “mystery meat” during that period. The see-no-evil methodology of “we build 1000s of Java packages and millions of java lines of code with this, so if it were broken were would have noticed” clearly was not working. And if it was “mystery meat” then, it’s mystery meat now. The methodology hasn’t changed. The code is still not being tested with TCKs. Sometimes mystery meat has pieces of filet minion in it. And sometimes it’s horse meat. The point is that you don’t know.

        Java is an extremely well spec’ed thing. It is also an extremely stable and compatible thing. And it comes with TCKs that actually verify compatibility and compliance with the spec. The TCKs are not open source, but the OpenJDK TCKs are available at no charge to entities that want to run them on OpenJDK (see Plenty of folks have gotten them and put testing infrastructure in place to run them.

        And I can tell you from actual experience that the tests are worth running. TCKs often do flag things that do not show up in other tests, and that would have blown things up in production after weeks or months of undetected math errors, edge conditions, and other “not found by my tomcat ping test” exposures. And sometimes those issues pop up because of a simple change in the build environment, the gcc compiler version, or some other small detail that “the same source built differently” does not have. Testing the sources and hoping for good binaries every time is simply not sufficient.

        As far as I’m concerned there is no excuse for putting out binaries of OpenJDK builds (or any Java JDK) that have not run against those tests without a clear warning (e.g. by using “experimental” in the package and deb/rpm name) that it is untested, unverified, and not-known-to-be-compatible-or-compliant JDK. You may not get sued for doing it (unlike with “Java”, such tarnishing of the OpenJDK name doesn’t come with a automatic trademark violation). But you certainly deserve some scorn. And those bits certainly deserve the label “mystery meat”.

        • anapsix

          I stand corrected on the title, thousand apologies. It’s just people tend to disclose affiliation when there might be a conflict of interest..

          • Jilles van Gurp

            If the story about java 8u40 from the Azul CTO is correct that is reason enough for any devops person to not touch debian provided openjdk binaries with a ten foot pole. There’s simply no excuse for shipping pre-release jdks. Just read up on the stuff e.g. the Elasticsearch people find in jdks even after they are released. Crashes, freezes, data loss, etc.. Exactly the kind of stuff you want to avoid. Running pre-release jdk builds for anything serious is plain irresponsible. Given that, I’d also be extremely suspicious about any custom tweaks Debian does to the openjdk packages as well since there is no way of knowing what kind of issues that introduces with out running the full test suites provided by OpenJDK as well as e.g. extended load tests (which Elasticsearch does before they recommend using any particular version of java for their product).

            My experience with running java across red hat, ubuntu, and debian is that it and related dependencies tend to be afterthoughts. You get outdated versions of everything by default, generally for no good reason whatsoever (e.g. maven or ant). You are better off getting binaries of popular java tools from the original developers in most cases (which in the case of java are generally cross platform anyway).

          • Gil Tene

            Of course, I could be making up all sort of stuff today about the past. Without some date-captured evidence, there may be no specific reason to believe me. Luckily, since I did try to gently push people on this subject at the time, there is some documented-at-the-time data in system I have no control over:

            1. See my September 2014 comment and related thread on Docker’s “Update Java 8 to 8u40” commit at the time.


            Note that 8u40 was not released until March 2015, and the while Java 8 was a fully GA’ed, released, and supported product between those dates, this broken 8u40 was the only Java 8 you got if you did an “apt-get install openjdk-8” on a debian system during that time range. Or if you used “from java:8” in a dockerfile. Or if you looked into that dockerfile and chose to take what it took as an openjdk 8 deb package. During that time period, OpenJDK 8u25 was the proper, stable, and reliable codebase to use, and both Azul and RedHat responsibly shipped and supported it during that time period],

            2. You can also find specific discussion about the 8u40 situation during a January 2015 discussion (two months before 8u40 was actually released) in this post/thread:

          • Gil Tene

            Since some revived discussion about whether or not this is “FUD” has happened on the github commit log I linked to above (, I figured I’d include a cpu of my comment here as well:

            @ebourg: Facts are facts. Check the dates on the specifics logged in this
            discussion [ ]. Unfortunately, no amount of “folks have good intentions, and test against 1000s of oss projects, so what they put out must be good” has helped here.

            To be clear: I’m very glad to see that both Canonical and Debian teams NOW have access to OpenJDK TCKs. I applaud you for being one of the people who has personally joined the OpenJDK TCK signatories list to make Debian testing possible. And I wholeheartedly hope that the TCKs are actually being used to test and verify the compatibility and spec compliance of the actual binary artifacts being put in repositories (as opposed to checking something built from the same sources). As a member of both the JCP and OpenJDK community, I would very much like to see all builds of Java and OpenJDK (that are not clearly labeled as prototype/EA) be produced in a responsible fashion. And in the Java world “responsible” equates to “the actual binary artifacts have passed the relevant Java SE version’s TCKs”.

            But it’s clear that at the times noted in this discussion that was not the case. The bits that were being shared and used by folks were of “clearly bad” origin and pedigree, simply based of the dates. And the TCKs were clearly not being run on them. It’s hardly “FUD” to point out the specifics here: that bits in deb packages labeled openjdk-8 (at least as early as Sep. 14, 2014, and at least until March 2015) and the “official java” dockerfiles and images that were based on them were built from something that was not stable or released by OpenJDK, and was clearly not meant to be released. These deb packages were not named, marked or labeled as “experimental”, “prototype”, “early access”, or any equivalent label. The version string you got when running them (with “java -version”) identified the JDK as 8u40 (again, with no tags to warn folks). The only user-identifiable difference between these and the eventual (March 2015) actual release of OpenJDK 8u40 would be the reported build number. People mistakenly went to production with these bits thinking that they are “good” openjdk 8 bits. And for all we know, there may be folks sill running those bits, thinking they actually are OpenJDK 8u40.

            And to avoid any of that “OpenJDK wasn’t actually out yet” nonsense: OpenJDK was out, and people were using it in production well before the dates in this discussion. That’s exactly why these bits were so problematic, since end users (and re-packagers like Docker) had no idea that they are somehow distinguished from “good” OpenJDK 8 bits that were production-worthy. OpenJDK 8 was GA’ed in March 2014. At the time this github discussion was created, it had already been updated with 8u5, 8u11, 8u20, and later with 8u25, all of which were stable GA versions. Those are the versions of OpenJDK 8 that would/should have been provided to someone pulling “openjdk-8” package (or getting hold of the deb package somehow) at any time prior to March 2015.

            Unfortunately, this documented history of what some have now come to call “Mystery Meat” OpenJDK builds has cast a shadow on OpenJDK builds in general, and on Debian repositories specifically. That’s bad for the OpenJDK community as a whole. I think that it would be good to offset and differentiate from the previous practice by providing specific documentation of TCK execution for each JDK or JRE binary artifact (when, what binary [with checksum] were they run on, etc.), and by making sure that things built from non-released source trees are clearly labeled in the package names and versions string (e.g. openjdk-9-ea would be a fine package to share with folks at this point, but please please please don’t call it openjdk-9).

            Here’s hoping for a better, cleaner, and more responsible future for OpenJDK builds.

          • Paolo Inaudi

            It is surely FUD to point out that the debian UNSTABLE release was running an unreleased version of openjdk in that timeframe like this is a problem in production. The latest stable version, jessie, was released in april 2015 _with openjdk 7 only_. openjdk-8 8u72 was the first openjdk 8 release to ever hit debian stable in february 1st, 2016, through the backports channel. tracker dot debian dot org slash pkg slash openjdk-8 is pretty clear about this point (sorry for obfuscated link, i want do avoid disqus moderation). You can promote your company, but do not discredit good work made by others, please.

          • Paolo Inaudi

            It is also quite fun for the fact that what i just said has already been said to you in the very link YOU provided to prove your point: the github package maintainer there replied that he was tracking sid, which is the unstable debian release (and which he told you it was the unstable release, so don’t try to act like you didn’t know now). Unstable releases are, you know, unstable.

          • Gil Tene

            Seriously? Your argument is that since some committer of the official docker image for java, which decided to internally use unstable, untested bits for what people will rely on for production, mentions that fact in a comment stream of an esoteric commit, users of “docker run java:8” should know not to trust it, and should ignore the mislabeled (looks like a good GA release, except that one doesn’t exist) version string that comes out of it?

            This amplifies the issue with irresponsibly releasing untested and incomplete OpenJDK binary builds THAT ARE NOT CLEARLY LABELED (in the version string) as experimental (or EA, or internal, etc.) in any shape or form. That the bits were first put in an unstable sid repository doesn’t matter. The bits predictably escaped: via docker hub, and by people sharing the deb packages or recipes for getting them to run on stable debian and ubuntu releases). The eventual, unsuspecting recipients were left with a mislabeled Mystery Meat JDK. they ran untested, bad JDKs in production without knowing it.

            to the folks who actually build these things: I’m not asking that you stop building pre-release openjdk bits or sharing them. I’m asking that you label your unstable stuff as unstable (not just in the choice of repo you publish them to, but specifically in the version strings and in the package names) so that people will know what they are. As long as you don’t, there is no reason to trust your stable releases either, since there is no way for a recipient that is actually running the bits to tell the difference.

          • Gil Tene

            I was not pointing to an unstable debian release in that timeline. I was specifically pointing to the “Official Docker image for Java”. If you doubt that, look at the README for the repo I that commit and comment trail is in: . Note that “Official Docker image” are explained here:, including this: “…Provide drop-in solutions for popular programming language runtimes, data stores, and other services, similar to what a Platform-as-a-Service (PAAS) would offer”.

            So this “people know not to use it in production” argument is nonsense. People *did* use it in production. It was recommended way to run Java 8 in production.

            Where this official Java image took it’s bits from, and whether the people building it were doing the responsible thing or not in doing that is immaterial. Doing “docker run java:8 java -version” during that period of time was using a Mystery Meat JDK that was misreporting it’s version, and showing no indication (in the version strings or elsewhere) of being an early-access/prototype/not-yet-relased thing.

            And in case you want to stand behind the “people know better” argument, you might want to check this out:

            Note the date (November 7, 2014), and note the contents of the docker file (the one that starts with “FROM java:8”). And note that the bits for this would come from exactly the commit I was pointing to (a misreporting OpenJDK 8u40 that did not actually exist, and was not tagged with warnings). This really happened. People

            You can blame the user of these official images all you want, and say that they are the ones responsible for checking the pedigree of the bits involved. But that’s a cop-out, and the whole point in calling these things “Mystery Meat” JDKs. You can’t trust what they say, and you end up having to check for yourself how they were build, how they were tested, and whether or not the sources they came form even match the versions they report.

            If you think that it is “FUD” to point out that the official docker image for Java was using clearly Mystery Meat bits, I’m not sure what responsible warning you wouldn’t be calling FUD.

            To me, any JDK build that doesn’t actually get tested with the appropriate Java SE TCKs, and/or comes from a source with a history of mislabeling versions (even if it’s in the misguided hope that mislabeled pre-released bits won’t make it into the wild) is suspect. The “trust us, we now what we are doing, and we don’y need those silly tests and responsible practices here” approach clearly failed in the past. Arguing that it didn’t, and that the same practices should continue just makes me suspect the current offerings of being just as bad.

            Looking forward, I *really* hope to not see “docker run java:9 java -version” be similarly badly built, and similarly misreport what it is in the next 24 months (*after* a good GA version actually exists next year). But I’m sadly suspecting that it might given this history.

          • Paolo Inaudi

            “It was a recommended way to run Java 8 in production”. Still, it was NOT recommended to run openjdk 8 in production. And, “FROM debian:experimental” is a pretty clear disclaimer. To keep users away from unstable unreleased version you can either rely on them to read what they are installing, or the only chance is to go fully closed source and never, ever release anything not production-ready. Which is quite close to never, ever release anything, since you are unable to beta-test.

          • Gil Tene

            So you actually read “…drop-in solutions for popular programming language runtimes, data stores, and other services, similar to what a Platform-as-a-Service (PAAS) would offer”. As “not recommended to use in production”. I must be using the wrong english-to-english dictionary.

            And when users looked at instruction for using these “Official Docker image for Java”, which were absolutely touted as trusted builds that are ready to go to production, they didn’t see “FROM debian:experimental”. They also didn’t see “FROM java:8-experimental”. What they saw said “FROM java:8”. (e.g. see what it actually said, in Nov. 2014, in this article Doing that (FROM java:8) delivered a non-existent (at the time) and mislabeled (with no hint of being experimental) OpenJDK 8u40.

            And this was in November of 2014. A good OpenJDK 8 (u25) was well past GA and used in production all over the place.

            The point is that placing a package that is not in itself labeled as “experimental” (or equivalent) inside an experimental repo is a recipe for disaster. When that package leaks to the world (via example like how docker’s official images, or others where people copied and propagate the deb package itself, or it’s contents), the fact that the repo it came form is experimental is lost one hop after the leak. The unsuspecting user that receives it or runs on it already-installed has not idea where it came from. Their version string (e.g. the output from java -version) is their only means of telling whether or not the stuff is any good. And when the version string lies (says it’s openjdk 8u40 with no experimental qualifiers), the resulting confusion leads to what we are discussing here.

          • Paolo Inaudi

            “OpenJDK builds has cast a shadow on OpenJDK builds in general, and on Debian repositories specifically”. Thanks to you, now people know they can find unreleased builds in Debian unstable and experimental repositories. Really, this is sooo bad…. Guy, you might have a point on the docker maintainers. But really, debian has nothing to do with this. If your intent wasn’t to put debian in a bad shape (and I don’t see your point in doing so), you would continue with your train of thought and blame the openjdk folks for letting people get the source and compile development snapshots, because hey, this way someone could give the binary to someone else, put it on the internet until yet another guy puts it on a production server believing it is a good java build. And this doesn’t make any sense.

          • Gil Tene

            Building an experimental binary without labeling it as such and sharing it with the world is a problem, and a way to reliably poison the reputation of the very thing you are building binaries of. If unstable and experimental debian builds of openjdk identified themselves as such in their java -version output, and in their deb package names, I’d have not problem with them.

            But as they clearly did at least between Sep. 2014 and March 2015 with 8u40 (and perhaps, for all I know, as they are still doing right now), they are sometimes good / sometimes bad Mystery Meat distributed without the warning label. I’m just calling them that.

          • Paolo Inaudi

            A production system with debian stable, in that timeframe would have responded “The package was not found”. There was no openjdk-8 package in debian stable until 2016. Here is your reference: , page 2. 2014-09-08: openjdk-8u40 hits ‘experimental’. The next day it reaches unstable. First release to hit ‘testing’ is 8u45, 2015-05-16, AFTER official release which was 2015-04-13. The Dockerfile in the commit you blame even states
            “FROM debian:experimental” as first line. And as tianon kindly pointed out to you, java:latest was still pointing to java 7, which was recommended at the time.

          • Gil Tene

            I’d like to make sure the “Mystery Meat” term that is well deserved by some openjdk builds out there does not get applied widely to all Linux distros.

            Specifically, I feel an obligation to point out that to my knowledge RedHat does a very good job with building and testing of OpenJDK for use by actual RHEL distros and customers. In my mind, they stand out in this regard (from other distros on your list). When they (RedHat themselves, and not someone else that builds stuff from the same sources without re-testing) deliver you an openjdk binary package in some form, I would confidently trust it as being good.

            RedHat also puts some very real investment into OpenJDK. They actually lead the OpenJDK 7 and OpenJDK 6 projects, and like Azul, they provide timely back ports of security issues to those projects as upstream issues in Oracle-supported versions pop up.

          • Paolo Inaudi

            I’m sure you’ll find some unreleased openjdk version in Fedora Rawhide, which is somehow the RedHat ‘unstable’ branch. Of course not in RHEL, but then again, neither in Debian stable.

          • Gil Tene

            Are you saying that you’ve actually seen mislabeled experimental openjdk builds in Fedora (ones that do not self-identify as experimental)? Or just that you think other people are also doing the same “distribute experimental openjdk binaries wrongly labeled as production versions” trick that Debian did with OpenJDK 8u40?

          • Paolo Inaudi

            Here you are:
            September 2, 2014, Fedora Rawhide receives java-1.8.0-openjdk-, even earlier than debian experimental. Don’t tell me there was a b in the package name, it stands for build and not beta. Hey, experimental branches are experimental. Full stop. In most GNU/Linux distributions, package names cannot be changed, since the dependency management system relies on them not to change; as per the -version output, you do realize that is openjdk who controls that, don’t you? distribution maintainers don’t include patches just to change a version string, they include them if they are really needed to integrate with other packages or to backport bugfixes. And openjdk relies also on people who put their development snapshot into experimental branches of distribution repositories, since this means more testing. If Azul can come there on release day, build openjdk for linux and distribute it to paying customers as stable, is also because people using debian unstable/experimental, fedora rawhide, opensuse tumbleweed, archlinux testing and so on tested it thoroughly. It makes no sense for maintainers to think about the fact that through multiple hops that binary could go in production. Feel free to blame docker maintainers (though, again, they were advising to use java 7 at the time), but blaming debian is nonsense.

          • Paolo Inaudi

            The story is fortunately false, see my comment below.

          • Gil Tene

            False my a**. Facts are facts, and “docker java:8 java -version” ran a Mystery Meat JDK that reported as “OpenJDK 8u40” with no indication wahtsoever of being an unstable or experimental build during the time period documented. The people responsible can say “not my problem, the plans were on display” (similar to the logic in, but that is not a good excuse for doing this to people.

          • Jonathan Dowland

            “If the story about java 8u40 from the Azul CTO is correct”

            Luckily, it isn’t.

          • Jilles van Gurp

            You are right, I fact checked things a bit. I would call it partially correct still. While Debian was indeed not shipping openjdk 8 in its stable release at all, the only thing available from Debian was a build of an unreleased openjdk u40. This despite the fact that there had been multiple stable openjdk 8 releases at that point. I’d argue that is a strange choice to make for your users.

            Anyway, because of the slow pace of just about anything landing to stable, Debian users routinely rely on testing and unstable packages to get access to what is essentially perfectly good release quality software; particularly when it concerns packages from projects with sane testing such as openjdk. Openjdk arguably has better testing for openjdk than Debian, so if they say it’s good to go why not trust them?

            It’s not unheard off for early testing/unstable packages to end up in upstream distributions like ubuntu even and indeed I found a ppa page linking a package of openjdk 8u40 that predates the actual openjdk release by two months as well as a reference in the change log: for a build for ubuntu vivid that clearly predates (Tue, 27 Jan 2015) the openjdk release, which happened one month before vivid’s scheduled release in late April. From the changelog, it appears that vivid (not an LTS release) may have actually shipped with the March 27 build referenced in the changelog, which would presumably be based on the openjdk release from early March. Interestingly, the changelog does not list any build at all for u25, which was a stable release from Oracle.

            Given the importance of java and openjdk to the linux ecosystem, it was not an unreasonable expectation for there to be release quality builds during this time frame and there weren’t any. Around this time it was also hard to find usable Red Hat builds. The apparent practice of providing unstable builds from what appear to be unreleased openjdk tag, is worrying. These are not builds that should even be considered for promotion to testing. At best it is a work in progress. In all fairness the first few openjdk 8 releases had some high profile issues and a lot of bug fixing happened between 25 and 40 that probably prevented openjdk 8u20 builds from being promoted from unstable (according to the changelog there never even was a u25). I suspect Ubuntu wanted to ship something with vivid and opted to bet on u40 being there in time.

          • Paolo Inaudi

            “These are not builds that should even be considered for promotion to testing”: they were not considered, 8u40 never left unstable. As for the changelog, look at the changelog there: Vivid shipped with openjdk 8u45, built on Apr 19. Not sure why an ubuntu build appears in the debian changelog.

          • Gil Tene

            The “the story about java 8u40 from the Azul CTO is correct” (me) is not about debian. It’s about Docker’s official image for java (and what debian bits it chose to use, and what the users thought they were getting). And unfortunately it is 100% true. [you can re-read what I actually said above]

            That during the time that debian’s unstable builds were making mislabeled OpenJDK binary builds available in deb package form, debian’s stable release didn’t actually include these bits, doesn’t matter to the people who ended up using them without knowing where they came from. The bits made it into the world without being marked as unstable, and through multiple vectors, made it into unsuspecting production environments that actually thought they were running OpenJDK 8u40.

            That’s what Mystery Meat is all about…

          • damnhandy

            Thanks for clarifying this Gil. I had thought this “Mystery Meat” argument was just your typical issue with package managers in general where you’re not always sure what point release you’re getting. This is indeed concerning.

            Now that I see Azul appears to have removed the referrer restrictions from the download URLs, i can now download Azul JDKs and JRE via cURL. This did not work a few months ago unless the referrer was the Azul download page.

        • Jonathan Dowland

          The latest stable version of Debian between September 2014 and March 2015 was Debian 7, codename “Wheezy”. It did not come with any version of openjdk-8.

          Within that time period openjdk-8 did exist within the “unstable” and “testing” distributions: these are the development areas that Debian developers use to prepare the next stable release. As development distributions, they are not supported, and it is strongly discouraged to use them for any production environment (not least because they lack security support).

          There is also a sub-project called “backports” which provides newer versions of some packages for releases of Debian. It’s vaguely analogous to Fedora’s EPEL. You have to explicitly opt-in to receive backported packages, and the instructions make clear that the packages are likewise not supported, and provided on an as-is basis. Having said all that, openjdk-8 was never backported for wheezy either.

          So, the only way you you could get the version of OpenJDK 8 during that time period is if you were running a development distribution, which is not supported for production use, and so there’s no problem with you getting an unsupported OpenJDK on top.

      • Paolo Inaudi

        Debian probably doesn’t love to work with companies whose CTO spreads FUD about them. See my comment below.

    • Henn Idan

      @gil_tene:disqus @anapsix:disqus @jillesvangurp:disqus Thanks for the comments and input! We love getting feedback from the community. By the way, we did mention RedHat IcedTea in the post as an additional alternative.

      • Gil Tene

        We should get the terms IcedTea and OpenJDK right for the audience:

        Red Hat’s IcedTea project is/was a great source for OpenJDK-based Java SE 6 and Java SE 7 builds. IcedTea was needed with older version of OpenJDK, mainly to fill in the blanks on parts that were not 100%OSS at the time. The need has gone away with OpenJDK 8, and starting with Java SE 8, there is no more IcedTea. There is just OpenJDK

        Red Hat has simply been shipping good, trusted, well tested builds of OpenJDK 8 for RHEL distros and in their repositories.

  • anapsix

    > if you’re downloading a Dockerfile that contains Oracle’s JDK, you’re not holding up your part in the agreement.
    I think you meant, “if you’re downloading pre-built Docker image, that contains Oracle JDK”.
    Docker files are simply instructions used to build images.

    I wondered about this myself, having one of the more popular images with Oracle Java..

    Oracle may manage to take down images from Docker Hub, but unlikely to have any legal ground (pure speculation, I’m not an attorney) to take down repositories hosting Dockerfiles. Then they would have to take down instructions on preseeding license acceptance in Debian or RedHat.

    Or they may choose to ignore it and watch Java remain to be a popular programming language.
    Docker lowers the cost of entry, smaller images make it easier for developers to work with environment, have less reasons for ops to dislike Java..

    • Bruno Souza

      Oracle could indeed take down images from Docker Hub, and yes, they do have legal ground. After all, you accepted their license when you downloaded (even if automatically) their product (Oracle’s JDK). If they are doing it or not, I can’t say. But I do know that Oracle has notified _companies_ that are redistributing Oracle’s JDK without a license to do that.

      On the other hand, I don’t believe there is any legal ground on preventing anyone from distributing scripts or Dockerfiles, that when run by a user, will download (even automated) Oracle’s JDK from Oracle’s site. Those scripts don’t negate the fact that the user legally accept the license when they run them.

      So, the most sensible thing to do is what you say in your last paragraph: download the Dockerfile, build your own images. Don’t redistribute those images outside your company, unless you bundle your application with it.

      All in all: if you use and redistribute a PROPRIETARY product (Oracle’s JDK), make sure you read the license and understand it. Otherwise, use and distribute an open source product (OpenJDK), that has a much easier to deal with license. An OSI-approved open source license 🙂

  • Lukas Eder

    Oops, nice find. Or actually, not so nice. Thanks for sharing!

    • Henn Idan

      Thanks for the comment!

  • Iqbal Ahmed

    Wouldn’t a similar set of legal restrictions apply to the use of MySQL on Docker?

    • Bruno Souza

      MySQL is GPL, so, no, it does not apply.
      Also, OpenJDK, as the article mentions, is also GPL.
      There is no legal issue redistributing unmodified GPL licensed code/binaries.

    • Henn Idan

      Thanks for the comment Iqbal, as Bruno mentioned – it depends on the license, which in MySQL case is GPL

  • fisadev

    Interesting article!

    Just a small detail: “if you’re downloading a Dockerfile that contains Oracle’s JDK”.
    That isn’t correct. The dockerfile is an instructions file, it can’t contain files or anything, so it’s impossible for a Dockerfile to contain the jdk.
    You should replace “Dockerfile” with “docker image”, which is the thing that could contain the jdk.

    • Henn Idan

      Thanks for the comment! We’ll update the post.

  • mixmatch

    Fuck Oracle.

  • Mike

    This sounds like it would also apply to folks deploying applications using AMIs and other immutable infrastructure tooling. Can anyone confirm?

    • Bruno Souza

      It never applies to “using”, it only applies to “distributing”.
      You can use Oracle’s JDK on a Docker image, or on an AMI you created, without problem. The license applies to _distribution_, and what you can’t do is to distribute a Docker Image, or AMI, that has Oracle’s JDK in it, as the article mentions.

    • Henn Idan

      Thanks for the comment. As Bruno mentioned, the licensing mainly refers to distribution.

  • Bruno Souza

    Those potential conflicting situations are quite confusing, and we need to be really careful of what it means…

    The article says a very important thing:

    “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.”

    Yes, redistributing a Docker image with Oracle’s JDK in it breaks Oracle’s license. But then, the article continues:

    “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.”

    This is less clear… If you are downloading a _Dockerfile_, then this is source only, it has no binaries, it cannot “contain Oracle’s JDK”.

    If you download a Dockerfile and build an image out of it, then YOU are downloading Oracle’s JDK and YOU are (even if in automated form, with a cookie) accepting Oracle’s license.

    Now, the article is correct that you can’t upload this image to a public Docker registry, without breaking Oracle’s license. Because this then becomes “redistribution” and this is forbidden by the license. I think this is an issue, and one that Oracle should look into.

    Unless of course, you redistribute it with you application… So, if your Docker image is actually a Tomcat image, including a complete and unmodified Oracle’s JDK with it is OK.

    All of this just highlights something that we all know is completely true: you CANNOT redistribute a proprietary product! Hey, this is not news, is it? Oracle’s JDK is a PROPRIETARY product, with a PROPRIETARY license. And you can only redistribute it if you follow Oracle’s license.

    This is why we keep telling everyone: do NOT use Oracle’s JDK if you plan to redistribute it! Use ALWAYS OpenJDK, that is an open source product, and YES, you can redistribute it. And modify it. And, and…

    All in all, the article brings some good points, but specifically, I think some things are misleading:

    The title:
    “Running Java on Docker? You’re Breaking the Law”
    Totally not true! No way I can read that phrase has ANY truth in it! You can run Java on Docker as much as you want! Even Oracle’s JDK! The only legal issue is if you REDISTRIBUTE (that is, upload to a public Docker Hub for example). Yes, I understand that many people do want to do that. In that case, use OpenJDK. Hummm… But that is still Java. So… The title is plain false…

    The long “illegal” script:
    “What you’re about to see is probably illegal. Don’t try this at home:”
    False again… Running that script is NOT illegal in any way. Even with Oracle’s JDK! If you then REDISTRIBUTE the image resulting from this script, then, depending how and to whom you are distributing this to, it may be illegal. Of course, using OpenJDK, this script turns out to be totally legal, as long as you comply with the GPL license.

    Bottom line: dealing with proprietary software is a pain. Avoid if possible. This is an advice for ANY proprietary software you may want to use (Oracle’s JDK included). If you want to redistribute your work to others (including uploading to Docker Hub), use open source software. OpenJDK is open source. Choose wisely your distribution of any open source software (there is usually several), because that has other implications (but they were detailed in other posts).


    • Henn Idan

      Hey Bruno, thank you for your comments and input, we appreciate your feedback and clarification for our readers! The post has been updated and the term Dockerfile was changed to Docker Image.

  • justinedelson

    Good food for thought here… There is a bit of hyperbole in both the title and body. Nothing here is “breaking the law” or “illegal”. It’s a violation of a license agreement which is very very different.

    • Henn Idan

      Thanks for the comment – that’s right, we didn’t necessary mean civil law 🙂

      • Jonathan Dowland

        Nor criminal…

  • travisspencer

    Perhaps I’m coming at things from a different angle, but I don’t see the issue with distributing Java in a Docker container as long as it’s bundled with your software and not just a stand-alone container that has Java pre-installed. I’m not a lawyer, by any stretch of the imagination, but if you reread the part of the Oracle license agreement sited in this article, you find the boldened part:

    Oracle grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute [Java], provided that you distribute [Java] complete and unmodified and only bundled as part of, and for the sole purpose of running, your [Java] Programs

    From that, it seems the Oracle has no issue with you putting up a Docker container that has Java in it as long as it also has your Java app in it. In this case, creating the Docker container like the example Dockerfile and using a script to send a cookie to auto-accept the agreement may be OK because A) you’re doing it on your behalf and not on behalf of the receiver of the distributed Docker container and B) the agreement says that you agree to be bound by the contract not only if you click the agree button but if you use the software at all.

    So, from my non-lawyer PoV, distributing Java in Docker seems perfectly acceptable for ISVs.

    (Check with your lawyer to get actual legal advice; this is only my unqualified $0.02.)

    • Ralph Tice

      Yeah this article is a bunch of clickbait… of course you can’t host Oracle JDK in containers published to Docker Hub, but every organization serious about Docker should be building and hosting their own base images, where they’re free to install Oracle JDK as long as they don’t make them available publicly.

      The Dockerfiles themselves are perfectly fine for this reason. My infrastructure can download Docker images legally all day long. I can’t make these available docker images available to you, but the Dockerfiles themselves should be fine.

      This is a Docker Hub problem and not a Docker problem.

  • Michael Lorton

    Don’t say “breaking the law”. In some formal sense, you may be breaking an agreement that you are party to. If you get a Cease and Desist letter from Oracle about it, you should Cease and Desist.