Oracle JDK slips into container images through version tags, deprecated official images, and inherited FROM lines, and it counts as a deployment the moment it lands in a layer. This page shows you how the runtime gets there, how to detect it in your registry without tipping off Oracle, and what the bill looks like when it does.
Oracle JDK slips into container images through version tags, deprecated official images, and inherited FROM lines, and it counts as a deployment the moment it lands in a layer. This page shows you how the runtime gets there, how to detect it in your registry without tipping off Oracle, and what the bill looks like when it does.
Yes, Oracle Java in a Docker base image can be a licensing problem, and whether it is depends almost entirely on which version tag you pulled and when you pulled it. Oracle's own container repository builds JDK 26, 25, and 21 under the No-Fee Terms and Conditions (NFTC), but the JDK 17, JDK 11, JDK 8, and Server JRE 8 Dockerfiles ship Java runtimes under the Oracle Technology Network (OTN) License Agreement for Oracle Java SE. Same publisher, same repo, two completely different license consequences. The permissive-sounding fact that Oracle releases the build scripts under UPL 1.0 does not help you, because UPL covers the Dockerfile text, not the JDK binary baked into the layer.
From Oracle's audit perspective, presence is deployment. If Oracle Java is installed on a system in your environment it is considered deployed and requires a license, regardless of whether anyone has launched a Java application in months. An Oracle JDK sitting dormant inside an unused image layer in your registry still counts. That single principle is what turns a container hygiene issue into a seven-figure exposure. Our 2026 cloud, container, and Kubernetes licensing reality pillar covers the broader picture; this page is strictly about the base image itself.
The license attached to your image is not printed on the image name. It is a function of the version tag and the date you pulled it.
There are five recurring paths we see across client registries, and none of them announce themselves in the image name.
Oracle publishes an oracle/oracle-openjdk image where the OpenJDK archive is released under GPLv2 with the Classpath Exception (the safe license), and a separate oracle/jdk line where recent tags are NFTC and older tags are OTN. Two images from the same vendor look nearly identical and carry opposite obligations. Engineers pick the wrong one because the naming is close enough to feel interchangeable.
The Docker openjdk Official Image is officially deprecated, with all users advised to find replacements as soon as possible, and only Early Access builds have received updates since July 2022. The binaries in that image were built by Oracle from OpenJDK sources under GPLv2 with Classpath Exception, so the license itself is fine, but the image is stale, unpatched, and hard to distinguish from an Oracle-branded runtime without inspecting the binary. The same applies to adoptopenjdk, deprecated in favor of eclipse-temurin with no updates after August 2021. Legacy Dockerfiles still reference both.
Docker Hub still serves base images that bury Oracle license acceptance in fine print. One long-standing image states that by using it (or any image deriving from it) you implicitly accept the Oracle JDK software licence. Another declares that by using the container you accept the Oracle Binary Code License Agreement for Java SE. A single FROM line inheriting from these images pulls Oracle obligations into your build silently, ten years after the image was published.
Even a legitimately free image has a ticking expiry embedded in its version. The NFTC license expired for Oracle JDK 17 in September 2024; build 17.0.12 (July 2024) was the last free update, and every JDK 17 release after it is OTN and requires a subscription for production. Oracle's LTS guide shows Java 21 updates under NFTC until roughly September 2026 and Java 25 until roughly September 2028. A container pinned to a post-17.0.12 Oracle JDK 17 tag was free when someone built it and is a liability now.
Some Oracle Server JRE images cannot even legally sit in a public registry: Oracle license restrictions mean the image cannot be provided on a public Docker repository under OTN Developer License terms, and the software has to be downloaded at build time. When a team works around that by baking the binary in anyway and pushing to an internal registry, they have created both a redistribution breach and a deployment record.
The following table maps the versions most commonly found in base images to their current license position. Treat it as the first filter when triaging a registry. Figures are drawn from Oracle's own FAQs and the LTS guidance cited in our research.
| Oracle Java version in image | License today | Free for production? | Base image verdict |
|---|---|---|---|
| JDK 8, up to 8u202 | BCL | Yes (that build only) | Low risk, but unpatched |
| JDK 8, 8u211 and later | OTN | No, subscription required | High risk |
| JDK 11, all releases | OTN | No, subscription required | High risk |
| JDK 17, up to 17.0.12 | NFTC | Yes | Safe until you upgrade the tag |
| JDK 17, after 17.0.12 | OTN | No, subscription required | High risk |
| JDK 21 | NFTC until ~Sep 2026 | Yes, for now | Watch the expiry clock |
| JDK 25 | NFTC until ~Sep 2028 | Yes, for now | Lowest risk, still time-boxed |
The most dangerous images to find in a registry are Oracle JDK 8 at 8u211 or later and any Oracle JDK 11, because both require a subscription with no free window remaining. If either is in a base image that ships to production, you are already out of compliance on the day the scan finds it.
Oracle JDK 8 after 8u202 and any Oracle JDK 11 are the two tags that convert a base image into an unbudgeted subscription.
Since January 2026 the Java SE Universal Subscription is the sole licensing model, with Named User Plus and Processor metrics discontinued entirely. The metric is per employee, and it counts every employee including part-time workers, contractors, and employees of third-party agents and outsourcers. This is why one Oracle JDK layer, discovered in one image, can price your entire workforce. We break the mechanics down in the ten facts of employee-based Java licensing.
Published list price is $15 per employee per month for organizations under 1,000 employees, tiered down from there. Benchmark data across 80-plus contracts shows the same $15.00 published rate for 1 to 999 employees and negotiated enterprise rates of $9.50 to $12.80 per employee per month for the 1,000 to 10,000 band. A 1,000-employee organization at list is $180,000 per year, but auditors routinely inflate the count (for example to 1,800) by pulling in contractors, then apply back-license fees for the period the runtime was deployed before any subscription existed. The container-fleet angle also matters at scale: the Employee metric caps installation and execution at 50,000 processors excluding desktops and laptops, and large auto-scaled fleets can breach it. See how autoscaling can blow past the 50,000-processor cap.
The disproportion is the whole problem. A firm of 5,000 with only 50 Java developers still licenses all 5,000 employees. If a single base image put Oracle JDK into that estate, the bill is not scoped to the developers. We quantify that gap in why 50 developers can trigger a 10,000-employee bill.
Detection is where most teams either miss the runtime entirely or create the evidence Oracle wants. The most common discovery error is a scan that misses whole categories: teams check the server fleet and forget end-user devices, build pipelines, container images, and cloud workloads. Base images sit precisely in the blind spot. Two rules govern the exercise.
First, distinguish Oracle JDK from OpenJDK at the binary level, not the image name. Mislabeling a vendor-neutral build as Oracle Java raises your exposure rather than lowering it, and so does the reverse. Second, do not use Oracle's own download channels or accounts to investigate, because pulling from Oracle to check can generate the update activity an auditor later cites as evidence. Note also that Oracle's telemetry is built to catch exactly the runtimes that trigger fees: for container tracking via JMS Fleets, only containers with Oracle JDKs are detected. Oracle's tooling is not a neutral inventory; it is a billing sensor.
Run the detection yourself, offline, layer by layer. The practical sequence:
release files and the java -version output string offline; Oracle builds identify themselves as Oracle in the vendor string, OpenJDK-derived builds do not.FROM line back to its origin so you catch Oracle obligations inherited from a parent image, not just the top layer.For the overwhelming majority of container workloads, the runtime is fungible. Replacing an Oracle JDK base with a GPLv2-with-Classpath-Exception OpenJDK build (Eclipse Temurin, Amazon Corretto, Azul Zulu, BellSoft Liberica, Microsoft Build of OpenJDK, or Oracle's own oracle-openjdk image) removes the license trigger without changing your application. The engineering effort is real but bounded, and it is almost always cheaper than the subscription it avoids. Our companion guides walk the migration and the trade-offs: swapping Oracle JDK for OpenJDK across a cloud image pipeline and bring-your-own Oracle Java versus the provider's OpenJDK.
Sequence the remediation by risk, not by convenience. Purge Oracle JDK 8 (post-8u202) and Oracle JDK 11 images first, because those are the tags that are already billable. Then handle post-17.0.12 JDK 17 images. Then set a calendar control on JDK 21 (NFTC to roughly September 2026) and JDK 25 (to roughly September 2028) so a future automatic patch does not silently cross an expiry line. Finally, add a registry gate that fails any build introducing an Oracle-licensed runtime, so the problem does not reappear after you have cleaned it. If you are approaching a renewal, fold this cleanup into the wider footprint review described in optimizing your Oracle footprint before renewal.
Do not wait for an audit letter to look. The steps are cheap and the downside of not doing them is measured in per-employee subscription years.
If you have already been contacted by Oracle, do not respond with data pulled from Oracle's own tooling, and do not concede that the presence of a runtime equals a licensable seat before the scope is negotiated. The base image finding is the opening move, not the settlement.
Yes. Oracle treats any Oracle Java installed in your environment as deployed and therefore licensable, regardless of whether an application has ever run. A dormant Oracle JDK inside a base image layer, even one that never reaches production, counts as present and available for use. Remove it or license it.
Do not rely on the image name. Unpack the layers offline and inspect the runtime's release file and java -version vendor string. Oracle builds identify as Oracle and ship OTN, BCL, or Oracle Java SE license text; OpenJDK-derived builds are licensed under GPLv2 with the Classpath Exception. The license text in the runtime directory is the definitive signal.
The binaries in that image were built by Oracle from OpenJDK sources under GPLv2 with Classpath Exception, so the license itself is safe. The risk is that the image is deprecated, unpatched since July 2022, and easy to confuse with an Oracle-branded runtime. Migrate to a maintained OpenJDK distribution regardless.
Only if the build number is 17.0.12 (July 2024) or earlier. NFTC coverage for Oracle JDK 17 expired in September 2024, so every release after 17.0.12 is OTN and requires a subscription for production. A pipeline that auto-patched past that build converted a free image into a billable one.
Scanning your internal registry offline does not. The evidence risk comes from using Oracle download channels or Oracle-authenticated accounts to investigate, which can generate the update activity auditors look for, and from Oracle's own JMS Fleets telemetry, which is built to detect Oracle JDKs specifically. Inspect through your internal mirror only.
Under the 2026 Java SE Universal Subscription, the metric is per employee including contractors, so a single Oracle JDK in production can price your whole workforce. At the $15 list rate that is $180,000 per year per 1,000 employees, and auditors often inflate the count and add back-license fees for prior periods. The cost is not scoped to your Java developers.
Most Oracle Database estates carry 20 to 30 percent removable spend. The buyer side playbook for edition right sizing, option pruning, and third party support.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.