An estate sweep routinely finds Oracle JDK on 15 to 35 percent of the servers a buyer swore were running OpenJDK, and that gap is the single largest source of audit exposure. This is the file level discovery method that closes it before Oracle's telemetry or its scripts do the counting for you.
How to Negotiate the Oracle Java Employee Agreement: Honest Leverage in a Captive Deal
Priced per employee, every employee, from $15 down to $5.25. At renewal your leverage is thin and OpenJDK threats rarely land. The one-year runway, trading through the wider Oracle relationship, and containing what you sign.
An estate sweep routinely finds Oracle JDK on 15 to 35 percent of the servers a buyer swore were running OpenJDK, and that gap is the single largest source of audit exposure. This is the file level discovery method that closes it before Oracle's telemetry or its scripts do the counting for you.
Because the two documents were produced by different methods for different purposes, and neither one started from the file evidence that actually settles the question. The estate a customer describes and the estate a sweep produces are almost never the same list.
A proper sweep typically identifies Oracle Java on 15 to 35 percent of the servers a buyer assumed were running an open source build. On a 3,000 server estate the midpoint of that range is roughly 750 machines carrying a licensable runtime nobody had recorded.
The quality of your discovery decides whether you negotiate from facts or from doubt. Nothing else in the engagement matters as much.
The consequence is arithmetic rather than principle. Because the subscription prices per employee rather than per install, a single misidentified runtime on one build server can, in Oracle's reading, put the whole workforce in scope. The counting rules sit in our Oracle Java licensing pillar.
This page assumes you have read our broader guidance on running internal Oracle licence audits before Oracle does. Java misidentification behaves differently from database option drift, so it needs its own method.
Because the field most scripts read first does not identify the distributor. The java.vendor property returns Oracle Corporation on many open source builds that carry no Oracle obligation whatsoever.
Red Hat's documentation confirms the behavior for its OpenJDK builds. The Adoptium project's build history records the same artifact: AdoptOpenJDK builds shipped with java.specification.vendor, java.vendor and java.vm.vendor all set to Oracle Corporation, tracked as issue 465 in the temurin build repository.
So a scan keyed on the vendor string, or worse on the word Java, flags neutral builds as licensable. That cuts both ways. It inflates your apparent liability, which frightens finance into overbuying, and it means a script that cannot separate the two will overstate exposure if you let its output stand.
The reliable evidence lives in files, not in installer metadata or the package manifest. The release file in the JDK home directory carries an IMPLEMENTOR line that names the true distributor.
What the release file IMPLEMENTOR line reports, by distribution
| Distribution | IMPLEMENTOR value | Licensable by Oracle |
|---|---|---|
| Oracle JDK | Oracle Corporation | Yes, subject to the governing terms and version |
| Eclipse Temurin | Eclipse Adoptium | No |
| Amazon Corretto | Amazon.com Inc. | No |
| Azul Zulu | Azul Systems, Inc. | No |
| Red Hat build of OpenJDK | Red Hat, Inc. | No |
| Legacy AdoptOpenJDK | AdoptOpenJDK, with vendor properties reporting Oracle | No, despite the vendor string |
Commercial inventory vendors document the same limitation from the other direction: Java version and edition are not exposed in installer evidence or the Linux package repository, so file scanning has to be enabled explicitly. After Java 11 the two code bases are effectively identical, which is exactly why the licence, not the binary, is the discriminator.
The vendor string says Oracle. The release file tells the truth. Never build a licence position on the wrong one.
In the categories that are not on the server list. Teams check the production fleet and stop, which leaves the places shadow Java accumulates most comfortably entirely unmeasured.
An image is a single artifact that becomes many running instances, so a decision made once in a base image propagates silently across the estate. That is a control opportunity as much as a risk.
Scan the registry rather than chasing running containers, because the registry is where the decision lives and where a fix applies once. Record the image digest, the base image lineage and the build date, which also gives you the dated evidence that matters for the lookback discussed in our page on the three year Java penalty window.
Independent software vendors ship applications with a runtime included, and buyers frequently assume the vendor licensed it. Sometimes true, sometimes not, and the assumption is worth converting into a document.
Ask each vendor in writing to state which Java runtime its product installs, which distribution it comes from, and under what licence the vendor distributes it. A written answer is a defence, and silence is a finding you should record as unresolved.
Our pages on embedded JDKs in third party applications and Java embedded and OEM licensing go further on where liability lands.
Workstations are the hardest category to govern and the easiest to fix once you accept that governance beats detection here. Point developers at an internal artifact repository so the default path never touches Oracle's download page.
That single control removes the download signal, standardizes the build, and makes the next sweep cheaper. The practical sequence is in our note on cleaning up pipelines and developer workstations.
Assuming a bundled right covers everything, and then buying a subscription over workloads that were already covered. Both are entitlement mapping failures, and both are common.
A database or middleware product includes a right to use Java to run that product. It does not license the runtime for anything else on the host.
If another application uses the same installation, that use falls outside the bundle and needs its own entitlement. This is the distinction that decides whether a host is a finding or a footnote.
Procurement buys a subscription to be safe, without checking that a middleware entitlement already covers the workload. Nobody revisits it, and the duplicate cost recurs annually.
Tag every Oracle runtime with its coverage source during discovery, so duplicated machines are stripped out before anything is signed. Our Java SE procurement insights cover the entitlement mapping in detail.
A proactive assessment at a 3,000 employee manufacturer shows why the raw number is never the licensable number. The sweep found 87 Oracle Java installations across 54 servers.
On analysis, 23 were misidentified open source builds carrying no obligation, and 18 were runtimes bundled with an Oracle database and covered under existing rights. Roughly 47 percent of the flagged installs evaporated once fingerprinting and entitlement mapping were applied.
The three counts every sweep should produce
| Count | What it measures | Manufacturer example |
|---|---|---|
| Found | Every Java runtime the sweep detected, before analysis | 87 installs across 54 servers |
| Oracle branded | Confirmed Oracle distributions after file level fingerprinting | 64 after removing 23 open source builds |
| Licensable | Oracle runtimes with no existing coverage | 46 after removing 18 bundled runtimes |
Report all three numbers, in that order, with the reasoning between them. A single figure invites challenge. A ledger that shows its own subtractions is much harder to dispute.
Because the metric is organizational rather than technical. The subscription counts the workforce, not the people who touch Java, so the number of installs is a threshold question rather than a volume one.
That is what converts a discovery error into a very large problem. One confirmed licensable runtime can put the whole employee population in scope, which is why the difference between 46 licensable installs and zero is not a difference of degree.
Less than it implies, but more than most buyers assume. Oracle's view is assembled from download records associated with your domain, any usage data you have supplied, and whatever the account relationship has revealed over time.
Download activity is the primary signal, and it is the one buyers most often forget they generated. A developer retrieving a JDK from Oracle's site creates a record that persists long after the artifact is deleted.
Which is why your own fingerprinted inventory is the document that decides the argument. The telemetry picture is covered in what Oracle already knows through usage data.
Feeding an estate into a vendor operated service is a disclosure, and it is not reversible. For discovery before any review, use an independent scanner whose output you hold and can interrogate.
The specific hazards are set out in our note on the management service self report trap. Oracle's own scripts, discussed in our guide to Oracle compliance scripts, capture usage but do not reliably separate distributions.
Their output should never stand as your baseline. Verify current positions against Oracle's Java SE licensing FAQ, and see our GLAS formal notice response guide for the formal process.
As a repeatable process with preserved output, not a one off panic scan. The sequence below is the one that produces an inventory a negotiator can stand behind.
Tooling matters, methodology matters more. Commercial and open source scanners all work when configured for file level evidence, and all mislead when left on default vendor string logic.
The common advice is to find every Oracle runtime and remove it immediately, on the theory that an estate with no Oracle binaries has no exposure. We disagree, and the sequence is what makes it wrong rather than the goal. Removal is the right destination, but deleting a runtime before you have captured its install date, patch level and host record destroys the evidence you need to bound a retroactive claim, and a claim about the past does not disappear because the present is clean. Worse, a remediation sweep that leaves no trail looks like exactly what a vendor will characterize it as. Capture the dated record first, preserve it properly, then remediate, and keep the decommission evidence as carefully as the install evidence.
Source: Redress Compliance advisory engagement file, 2024 and 2025.
Discovery is not the end of the exercise. It is the foundation that makes everything after it defensible, and you cannot negotiate well from a number you did not produce yourself.
Nothing on this page is legal advice. Questions about privilege, evidence preservation and third party vendor liability should be taken to counsel before you act on them.
A sweep typically finds Oracle JDK on 15 to 35 percent of the servers a buyer assumed were running an open source build. On a 3,000 server estate the midpoint alone is around 750 previously unknown installs. Because the subscription prices per employee, even a small number of confirmed Oracle runtimes can drive a very large obligation.
Many open source builds report java.vendor as Oracle Corporation despite carrying no Oracle obligation. Reading that property flags neutral builds as licensable and inflates your apparent exposure. Use the IMPLEMENTOR line in the JDK release file instead, because it names the actual distributor and is the distributor's own declaration.
Only for that product. Those agreements include a restricted right to run Java to operate the specific product. If the same installation serves any other application, that use falls outside the bundle and needs its own entitlement. Map every runtime to a coverage source to avoid both exposure and paying twice.
Ask each vendor in writing which runtime its product installs, which distribution it comes from, and under what licence the vendor distributes it. Some vendors hold distribution rights and some do not. A written answer becomes part of your defence, and an unanswered request should be recorded as an unresolved item rather than assumed away.
Both, but start with the registry. One base image becomes many running containers, so the decision lives in the image and a fix applies once. Record the image digest, its base image lineage and its build date, which also gives you dated evidence if a retroactive period is ever argued.
Not before you have preserved the record. Capture install date, patch level and host details first, then remediate, and keep the decommission evidence. Removing a runtime does not remove a claim about past use, and an undocumented cleanup is far harder to explain than a documented one.
Be cautious. Supplying an estate to a vendor operated service is a disclosure and it cannot be withdrawn. For discovery before any review, use an independent scanner whose output you control, preserve it yourself, and never treat a vendor script's output as your baseline.
File scanning. Java version and edition are not exposed in installer evidence or the package repository, so an inventory tool left on default settings will produce a confident and wrong answer. Turning on file scanning and reading the release file is what turns an inventory into evidence.
Oracle GoldenGate is licensed per processor on source and target, doubling the count. List prices, the option stack, and the buyer side defense in one paper.
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.
