A single misidentified Java binary on one server can trigger a $630,000 annual employee-metric subscription claim, because Oracle prices the estate, not the install
Oracle Java is billed per employee, so one Oracle-licensed binary anywhere in the estate converts a 5,000-person company into a $630,000-per-year list exposure while 40 correctly identified OpenJDK installs cost nothing. The distinction lives in the license attached to the binary, not in the code, which is why detection has to go four layers deep past `java -version`. Until you can prove distribution and license per install, every discovery report you hand Oracle is an admission you cannot defend.
Prepared by Redress Compliance · August 30, 2026 · Oracle Java advisory. Detection and audit-defense engagements, 2024 to 2026.
Executive summary
Misidentification is asymmetric: one false positive costs a 5,000-employee company $630,000 per year at list, while one false negative leaves the same amount unbudgeted and audit-exposed.
Under the Employee metric the licensed quantity equals total headcount plus agents, contractors, outsourcers and consultants, so the number of installs is irrelevant to the price and a single Oracle binary sets the entire bill.
The `java -version` string identifies build lineage, not vendor, and it is wrong to treat it as proof either way.
Oracle builds print `java version` and `Java(TM) SE Runtime Environment` while OpenJDK builds print `openjdk version` and `OpenJDK Runtime Environment`, but repackagers, custom builds and relabeled runtimes break that rule often enough that you need `java.vendor`, `java.vendor.version`.
The `release` file `IMPLEMENTOR` key, and package provenance before you call it.
Version number alone decides billing for JDK 8, 11 and 17, where OTN terms already apply, and JDK 21 loses free NFTC coverage on September 16, 2026.
Oracle JDK 17.0.13 and later, and every Oracle JDK 21 update after the final NFTC build shipped in July 2026, require a paid subscription for production use, so a routine patch can convert a compliant install into an exposed one without any change to the vendor string.
Partial migration buys nothing: if one application anywhere still runs an unlicensed Oracle JDK, the full employee-count subscription is owed.
The estate does not need to be standardized on a single OpenJDK distribution, but it does need to be free of every unlicensed Oracle binary, which makes 100 percent detection coverage the only threshold that changes the invoice from $630,000 to zero.
Detection accuracy is negotiation leverage, not just hygiene, and it is worth 20 to 40 percent off list in a contested renewal.
Buyers who arrive with a per-host evidence file (vendor property, release file, package source, install path, license version) reset the conversation from Oracle's inventory to yours, and that is the only position from which a metric or headcount carve-out is negotiable.
The four detection layers, and what each one actually proves
Identification is not one command, it is four layers of evidence, and each layer answers a different question with a different degree of authority.
Layer one is command output: `java -version` prints `openjdk version` and `OpenJDK Runtime Environment` for an OpenJDK build, and `java version` with `Java(TM) SE Runtime Environment` for an Oracle build.
That distinction is real (Oracle JDK 25.0.1 prints `java version "25.0.1" 2025-10-21 LTS` and `Java(TM) SE Runtime Environment (build 25.0.1+12-LTS-29)`), but it identifies build lineage, not the vendor who compiled and licensed the binary.
Layer two is JVM system properties, reached with `java -XshowSettings:properties -version`, which exposes `java.vendor`, `java.vendor.version` and `java.runtime.name`.
Layer three is the `release` file in the JDK home, whose `IMPLEMENTOR` and `IMPLEMENTOR_VERSION` keys are the closest thing to a signed vendor declaration you will get from a running install.
Layer four is package and path provenance: the package manager record, the installation path, the download source, and on macOS the `CFBundleIdentifier` retrieved via `/usr/libexec/java_home` and matched against known vendor tokens (adoptopenjdk, amazon, apple, azul, openjdk, oracle, sap).
Two cautions on layer four. Any script matching a fixed vendor token list returns Unknown for distributions not on the list, and Unknown is not the same as Oracle.
And `IMPLEMENTOR` strings drift, so verify what you find against the vendor's currently published values rather than a list someone wrote three years ago.
| Detection layer | Command or artifact | What it proves | Where it fails |
|---|---|---|---|
| 1. Command output | `java -version` | Build lineage: Oracle-style `java version` and `Java(TM) SE Runtime Environment` versus `openjdk version` and `OpenJDK Runtime Environment` | Says nothing about which vendor compiled and licensed the binary; rebuilds and repackaged JDKs can mislead |
| 2. JVM system properties | `java -XshowSettings:properties -version`, reading `java.vendor`, `java.vendor.version`, `java.runtime.name` | Vendor as the JVM reports itself at runtime, plus vendor-specific build version | Values are set at build time and can be inherited or altered in custom or container images |
| 3. Release file | `IMPLEMENTOR` and `IMPLEMENTOR_VERSION` in `$JAVA_HOME/release` | The vendor's own declaration on the shipped artifact, the strongest single on-host signal | Strings change between releases; unlisted vendors and stripped files resolve to Unknown, not to Oracle |
| 4. Package and path provenance | Package manager records, install path, download source, macOS `CFBundleIdentifier` via `/usr/libexec/java_home` | Where the binary came from and who put it there, which is the audit-grade chain | Manual copies, unzipped tarballs and image layers leave no package record at all |
The four layers are not redundant checks of the same fact, they are a chain of custody with increasing evidential weight and decreasing coverage. Layers one and two scale to thousands of hosts and give you a fast triage sort.
Layers three and four are what survives contact with an Oracle reviewer, because they connect a binary to a vendor and a distribution channel rather than to a string the JVM chose to print.
Any install where layers one to three agree and layer four is silent is not a clean install, it is an unproven one.
Treat Unknown as its own bucket and never let it collapse into Oracle. In our audit-defense work, the single most expensive discovery habit is a script that resolves any non-matching vendor token to Oracle by default, because that default becomes the number Oracle quotes back at you.
Bucket Unknown separately, re-run layers three and four against it, and only then classify. Detection tooling is also a two-way street: read how Oracle detects unlicensed Java through download logs and telemetry before you assume your inventory is the only one in play.
Version number, not vendor string, is what triggers the bill
A confirmed Oracle binary is not automatically billable, and a confirmed OpenJDK binary is never billable, so any detection routine that captures vendor without capturing the full version and build number has produced half an answer.
OpenJDK distributions ship under GPLv2 with the Classpath Exception and are free for production use indefinitely, which is why the difference between Oracle JDK and OpenJDK sits in the license, not the code.
On the Oracle side, the No-Fee Terms and Conditions license covers JDK 17 and later, permits free commercial and production use, and permits no-charge redistribution, but it is time-limited and version-specific.
JDK 17 is the precedent that proves the cliff is not theoretical: 17.0.12, released July 2024, was the last free NFTC build, and every JDK 17 release from 17.0.13 onward falls under OTN and requires a paid subscription for production use. JDK 8 and 11 are already OTN territory.
JDK 21 runs free until September 16, 2026, with the last free NFTC-licensed update distributed in July 2026. JDK 25 is free in production until September 2028, a year after Java 29 arrives as the next LTS in September 2027. Non-LTS JDK 26 is free only until September 2026, when JDK 27 supersedes it.
The mechanism that converts this into an unbudgeted invoice is patch automation.
A configuration management tool, a container base image rebuild, or an unattended updater applying 17.0.12 to 17.0.13, or applying the October 2026 JDK 21 update, changes nothing a vendor-string scan would notice while moving the binary from NFTC to OTN.
The vendor field reads Oracle before and after. The runtime name is identical. Only the fourth digit moved, and the fourth digit is the billing trigger.
Capture vendor, full version, build number and patch date on every install, and pin the last free build explicitly rather than trusting a policy that says "latest patch." Our advice to clients is blunt: until you can prove you did not upgrade yourselves into non-compliance.
Assume your patch pipeline already did.
Defend an Oracle Java audit without overpaying
Oracle now audits Java SE on employee count, not installs, which can multiply the bill several times over. How to defend the notice and exit to OpenJDK.
Get the white paper →Why Oracle prices your headcount and not your install count
The single most expensive misunderstanding in Java licensing is the assumption that a subscription scales with deployment. It does not.
Under the Java SE Universal Subscription, Oracle counts Employees, and its definition is deliberately wide: all full-time, part-time and temporary employees, plus the staff of your agents, contractors, outsourcers and consultants supporting your internal business operations.
The price list is explicit that the licensed quantity is determined by the number of Employees, not by the number who actually use the programs, and that quantity must at minimum equal your headcount as of the order effective date.
There is no partial-estate option, no server-based fallback, and no mechanism to license only the two application servers where an Oracle binary was found. This is why a single misidentified install is not a small problem.
A 5,000-employee company that needs Oracle Java on 40 servers pays 5,000 employees, which at list is $630,000 per year, or $15,750 per server. The same 40 servers running correctly identified OpenJDK builds cost zero.
The delta is entirely a function of what your evidence says about the license attached to the binary, and nothing to do with how many binaries exist.
Two mechanics compound the exposure. First, the tiering is volume-based and drops from $15 per employee per month at the bottom to $5.25 at published scale, with lower rates negotiable above 50,000 employees.
The tier is not a discount you earn, it is a function of your headcount, so growth through acquisition raises the bill automatically.
Second, there is a ceiling most buyers never read: under the Employee metric you may install and run on up to 50,000 processors, exclusive of desktop and laptop processors, and anything beyond that requires additional licensing.
For a large VMware or container estate this is a live constraint, not a formality, and it is worth modeling before you sign rather than discovering it in a true-up. One point in your favour: the published rate is all-in.
There is no separate 22 percent support line on the Universal Subscription, so any budget model that adds a support uplift on top of the per-employee rate is double-counting and inflating your own business case.
| Headcount / band | Published rate per employee per month | Annual list cost | What the install count changes |
|---|---|---|---|
| 5,000 employees, 40 Oracle Java servers | $10.50 (3,000 to 9,999 band) | $630,000 | Nothing. $15,750 per server is arithmetic, not pricing |
| 4,000 employees | $10.50 | $504,000 | Nothing |
| 10,000 employees | $8.25 | $990,000 | Nothing |
| 28,000 (Oracle's own worked example: 23,000 employees plus 5,000 agents, contractors, consultants) | $6.75 | $2,268,000 | Nothing |
| Above 50,000 employees | Below $5.25, negotiable | Negotiated | Separate 50,000-processor cap applies, desktops and laptops excluded |
Read the table as a risk model, not a price list. Every row has the same right-hand column, and that is the whole point: your remediation lever is binary count zero, not binary count reduced.
Oracle's 28,000 example is instructive because it publishes the contractor inclusion openly, which means your headcount figure in a negotiation is not your HR payroll number.
It is payroll plus the managed service desk, plus the offshore development partner, plus the facilities contractor if they touch internal systems.
In market experience, buyers routinely understate this by 10 to 25 percent in early modeling and then find the number moves against them once Oracle applies its own definition.
Establish your defensible headcount early, document how you derived it, and treat any reduction in contractor scope as a negotiation lever rather than an afterthought.
And before you accept that you need the subscription at all, confirm which builds are genuinely billable using the version-by-version free versus paid position, because the metric only bites once a single unlicensed Oracle binary is conceded.
The detection problem is really an evidence-custody problem
The technical question at the centre of this article was solved years ago.
Reading four layers deep past `java -version`, into the release file, the vendor properties, the package manager record and the binary provenance, will tell any competent engineer whether a given install is an Oracle build or a free OpenJDK distribution. That is not where organizations lose.
They lose because knowing the answer and being able to prove the answer to a hostile third party, eighteen months after the fact, are entirely different capabilities, and almost nobody builds the second one.
Oracle's audit posture is constructed precisely in that gap. The commercial model does not depend on Oracle proving you are non-compliant. It depends on Oracle presenting a plausible claim narrative that you cannot cheaply rebut, and then letting the per-employee arithmetic do the rest.
Once the conversation is about a 5,000-person company facing $630,000 per year, or a 28,000-count organization facing $2,268,000, the cost of assembling retrospective evidence is trivial by comparison, and Oracle knows that most buyers will settle rather than litigate the technical question.
The asymmetry is not legal, it is evidentiary.
What gives Oracle the opening is that its own evidence is timestamped and yours usually is not.
Download logs tied to a corporate domain, update check-ins from binaries still phoning home, and telemetry from Java Management Service all produce dated, per-artifact records that sit in Oracle's systems, not yours.
Understanding how Oracle actually finds unlicensed Java matters here because the record is not a scanner output, it is a history.
A discovery report that says "OpenJDK, Temurin 17" as of last Tuesday does not rebut a claim that an Oracle binary was downloaded and deployed in March 2024 and removed before the scan ran. Point-in-time truth cannot answer a period claim.
There is a second, quieter problem: most inventory tooling reports a vendor field rather than the artifacts underneath it. That field is hearsay.
It is the tool's interpretation of a release file or a registry key, not the release file or registry key itself, and if the tool normalized incorrectly, or if someone repackaged an Oracle binary into a container image with a rewritten label, the report is confidently wrong.
Under audit pressure you will be asked to substantiate it, and "the CMDB said so" is not a substantiation. Preserve the raw output: the full `java -version` block, the `release` file contents, the package manager record, the file hashes, per host, with the collection date attached.
That is what converts the burden.
Evidence collected before Oracle makes contact, timestamped, per-host, and archived immutably, does something a post-notice scan cannot: it establishes a baseline that predates the dispute, and it forces Oracle to argue against your record rather than against your memory.
In audit-defence work this is the single highest-leverage artifact a buyer can hold, because it moves the discussion from "prove you were compliant" to "show us the specific host and date you dispute." Most claim narratives do not survive that question.
The ones that do get narrowed to a handful of hosts, which is a very different negotiation from an estate-wide employee-metric assertion.
This is also why partial migration programs fail, and they rarely fail on engineering. Replacing Oracle JDK with Temurin or Corretto is a routine exercise.
What breaks is the tail: the vendor appliance shipped with an embedded Oracle runtime, the developer laptop image nobody re-baselined, the legacy build server that pulls a pinned Oracle artifact from an internal repository.
Because the rule is all-or-nothing, one surviving unlicensed Oracle binary reinstates the entire per-employee subscription, so a migration that is 98 percent complete and 100 percent unevidenced is commercially identical to one that never started.
Programs should be measured on hosts with preserved proof of the running binary, not on hosts touched.
Measured against a $630,000 to $2,268,000 annual exposure, detection discipline is the cheapest insurance in the Oracle portfolio.
Standing up per-host evidence capture, retaining it for the full contractual lookback, and refusing to hand Oracle any scanner output you cannot substantiate from raw artifacts is a small engineering investment against a seven-figure claim.
Find and document the installs on your own schedule, using your own definitions, before anyone else defines them for you.
Where detection routinely goes wrong in the field
Across audit-defense engagements, the same five failure modes account for nearly every false exposure claim and every genuine one that arrives as a surprise.
The first is the bundled JRE: a vendor application (ERP middleware, backup agents, storage management consoles, monitoring collectors) ships a private Java runtime inside its own installation directory.
And no enterprise discovery tool attributes it because it was never registered with the OS package manager and never appeared on PATH.
The second is the developer laptop with four JDKs, where `java -version` on the shell resolves to Temurin while the application launcher, the IDE run configuration, or a `JAVA_HOME` set inside a service wrapper points to an Oracle build.
The third is containers, where the host runs Corretto and the base image runs Oracle JDK 17 pulled from a public registry, invisible unless you inspect image layers rather than hosts.
The fourth is relabeled and repackaged builds, where an internal platform team rebuilt a runtime, edited the release file, or wrapped the binary, and the version string no longer describes what is actually installed.
The fifth, and the one that produces the most confident wrong answers, is the inventory tool with no vendor field: it normalizes everything to "Java 17.0.13" and the report reads identically whether the binary is billable Oracle or free OpenJDK.
That is a data model problem, not a scanning problem, and no amount of rescanning fixes it.
The pattern underneath all five is the same: every one of them fails in the direction of ambiguity, not in the direction of a clean answer. An unresolved install is not a neutral state.
Oracle's employee metric means one unresolved binary on one server carries the same commercial consequence as a hundred, so ambiguity resolves in the vendor's favor by default unless you close it yourself.
Treat every "unknown vendor" line as a billable install until you have raw evidence proving otherwise, then work the list down.
On the negotiation side, advisory sources diverge materially. Some published guidance describes 20 to 40 percent below list as the realistic outcome of advisor-assisted negotiation; other guidance describes 50 to 60 percent as achievable at large scale through structured negotiation.
Both bands are real, but they describe different buyers. The upper band belongs to organizations with 20,000-plus employees, a credible and demonstrated migration path to an OpenJDK distribution, and a multi-year commitment on the table.
In our experience, most mid-market and lower-enterprise buyers land in the lower band. Budget on 20 to 40 percent and treat anything above it as upside, because a business case built on 55 percent that lands at 30 percent leaves you funding the gap out of an already-approved number.
And note that the discount applies to a metric you cannot shrink through consolidation: reducing installs does nothing to the price, so discount is the only lever left once you have accepted the subscription at all.
Resolving the five failure modes above, before you talk to Oracle, is what keeps the alternative (removal) credible enough to move the discount.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
Your first five moves
- Run the four-layer check across every host and every container image, and keep the raw output. Capture `java -version`, the `release` file, binary path and package provenance, and the license files present on disk, stored with hostname, image digest, and timestamp, because a screenshot without provenance is worthless in a dispute.
- Split the inventory into four buckets, not two. Confirmed Oracle billable, confirmed Oracle inside the NFTC free window, confirmed OpenJDK, and unresolved: the unresolved bucket is your work queue and it should be driven to zero before any conversation with Oracle, since finding your own installs first is the only version of this exercise you control.
- Freeze patching on every Oracle JDK 21 install before September 2026. The last free NFTC-licensed JDK 21 update ships in July 2026 and everything after moves to OTN, so an unplanned patch cycle upgrades you into a paid position exactly as JDK 17.0.13 did in 2024; hold the version until the replacement decision is signed off.
- Remove every unlicensed Oracle binary, not most of them. One remaining Oracle JDK in production requires a subscription priced on total headcount, which means a 95 percent migration and a 0 percent migration cost the same $630,000 for a 5,000-employee company; individual applications can run different distributions, so the estate does not need to be standardized, only cleared of Oracle.
- Hold the evidence file internally, under privilege, and never hand Oracle a scanner export. Route the work through counsel where you can, answer specific contractual questions with specific answers, and remember that discovery output is an admission of scope, not a defense: what you volunteer becomes the baseline Oracle prices against.
Frequently asked questions
Does `java -version` reliably tell me if I have Oracle JDK?
It is a strong first indicator but not proof. Oracle builds print `java version` and `Java(TM) SE Runtime Environment`, while OpenJDK builds print `openjdk version` and `OpenJDK Runtime Environment`.
Repackaged, relabeled and custom-built runtimes can produce misleading output, so confirm with `java -XshowSettings:properties -version` and check the `java.vendor` and `java.vendor.version` properties plus the `IMPLEMENTOR` key in the JDK's `release` file.
Are Oracle JDK and OpenJDK actually different code?
For current releases, functionally no. In terms of build, Oracle JDK and OpenJDK are substantially identical, and the source is the same OpenJDK project.
What differs is the license attached to the binary you downloaded: OpenJDK distributions ship under GPLv2 with the Classpath Exception and are free for production indefinitely, while Oracle-branded binaries fall under NFTC or OTN terms depending on version and update level.
Is Oracle JDK 21 still free in 2026?
Only until September 16, 2026. Oracle JDK 21 received updates under the NFTC until that date, one year after the next LTS, and the last free NFTC-licensed JDK 21 update was distributed in July 2026.
Every JDK 21 update after that falls under the Java SE OTN License, which requires a paid subscription for production use.
If I patch Oracle JDK 17, do I become liable?
Yes, if you go past 17.0.12. The NFTC license expired for Oracle JDK 17 in September 2024, build 17.0.12 released in July 2024 was the last free update, and all subsequent JDK 17 releases are licensed under OTN.
Organizations routinely upgrade themselves into a compliance issue through automated patching, so freeze Oracle JDK 17 patching until you have replaced the binary.
If most of our Java is OpenJDK, do we still owe Oracle anything?
Yes, if any unlicensed Oracle JDK remains in production. You escape the subscription only when all Oracle JDK deployments are removed and replaced.
There is no partial credit under the Employee metric: one remaining application on an unlicensed Oracle binary triggers the full headcount-based subscription, which for a 5,000-employee company is $630,000 per year at list.
Do all our Java installs need to be the same OpenJDK distribution?
No. Individual applications can use different JDK distributions, and the estate does not need to be standardized on one vendor. Temurin, Corretto and Zulu can coexist across the estate without licensing consequence. Standardization is an operational preference, not a compliance requirement.
How do I identify the JDK vendor on macOS?
Use `/usr/libexec/java_home -V` to enumerate installed JDKs, then read `CFBundleIdentifier` from each JDK's `Info.plist`. Grep the identifier for adoptopenjdk, amazon, apple, azul, openjdk, oracle or sap.
If the result is Unknown, the JDK is installed but is not from a recognized vendor list, and you must fall back to the `release` file `IMPLEMENTOR` key and the installer's package provenance.
