A removal you cannot date to the day is worth nothing: one un-evidenced Oracle JDK host puts a 12,000-employee estate on the hook for $1,188,000 a year at list
Oracle prices Java on employees, not installs, so a single surviving Oracle JDK install converts the entire headcount into a subscription trigger. Removal only defeats that if you can prove the exact date, host, and version that left the estate, because Oracle keeps download logs for years and will otherwise assume company-wide deployment. The logging standard you run in 2026 is the record that gets tested in 2027.
Prepared by Redress Compliance · August 31, 2026 · Oracle Java advisory. Audit-defense and removal-evidence engagements, 2023 to 2026.
Executive summary
Removal does not shrink the bill, it removes the trigger, and that is a binary outcome at $1,188,000 a year for a 12,000-employee estate.
Under the Java SE Universal Subscription the licensed quantity must at minimum equal the employee count, so four Oracle JDK installs and four thousand price identically, and the only defensible position is zero installs with dated proof.
Uninstalling is not erasing: Oracle's download logs carry username, IP, date, time and exact file, and Oracle has stated it keeps those records for years.
A clean scan taken in 2026 rebuts nothing about a 2019 download, which is why the removal record must state the date usage stopped, not merely that the host is now clean.
The burden of proof sits on you, and the October 2026 CPU is the date your timestamps are measured against.
Oracle JDK 21, 22, 23 and 24 leave the NFTC with the October 2026 Critical Patch Update, so a removal logged 15 September 2026 is free and the same host patched in November 2026 is a paid deployment.
Three artifacts close a host permanently: a timestamped removal record, a change ticket with a named approver, and a post-removal negative scan at least 30 days later.
Engagements where all three exist see reopened hosts drop to near zero; engagements relying on a single inventory export routinely see Oracle re-list the same 40 to 200 hosts in a second data request.
What a removal record must contain before Oracle will stop counting the host
A removal record is not an absence, it is an event.
Oracle's audit teams do not accept the disappearance of a row from a discovery export as proof that anything happened, and after twenty-five years across this vendor's LMS and GLAS engagements I have never seen an inventory delta survive a substantiation request on its own.
What survives is a positive record of an act, with an actor, a target, and a clock reading. Six fields are mandatory and three artifacts corroborate them.
Oracle's own guidance to customers, echoed in every audit FAQ it publishes, is that you must document the removal process and be prepared to demonstrate that those instances are gone, along with the corresponding removal dates.
That is the standard you are being measured against, so build to it deliberately rather than reconstructing it under a 30-day response clock. If your existing files are thinner than this, start with building the Java evidence file before Oracle asks, then hold every new removal to the table below.
| Element | What it must show | Why Oracle accepts or rejects it |
|---|---|---|
| Hostname or asset ID | Immutable identifier that ties to the CMDB record, not a DNS alias | Aliases get reassigned, so Oracle argues the record describes a different machine |
| JDK vendor and full version string | Vendor, major version, and build (for example 1.8.0_401-b10, not "Java 8") | Version determines whether the install was OTN, NFTC, or free, and therefore whether the period before removal was billable |
| Install path | Absolute path of the removed directory | Proves which of several co-resident runtimes left; a bare hostname does not |
| Removal timestamp | Date and time to the minute, with timezone or UTC offset | Cliff dates (October 2026 CPU for JDK 21) are decided in days, not months |
| Executing account | Named human or a service account mapped to a named owner | A close by an unattributable service account is treated as unverified |
| Change ticket reference | Ticket ID resolvable in the ITSM system, with approver name | Links the technical act to an authorised business decision |
| Corroborating artifact 1 | Console output or screenshot with a visible system clock | A cropped screenshot with no clock proves the state, never the date |
| Corroborating artifact 2 | Named approver, distinct from the executor | Separation of duties is what makes the record evidential rather than self-asserted |
| Corroborating artifact 3 | Post-removal rescan showing the host clean | Confirms the removal held and did not regress at next patch cycle |
The three failure modes I see most often are all self-inflicted and all fixable at zero cost.
First, bulk removals logged with a single date for 400 hosts: one script, one timestamp, one ticket, and Oracle rightly asks which of the 400 was actually touched on that date, then treats the whole batch as undated.
Second, screenshots without a visible system clock, which prove a state and never an event. Third, tickets closed by an automation account with no human approver, which Oracle characterises as the customer certifying its own compliance.
The distinction worth internalising: weak evidence answers "is it there now?" and strong evidence answers "who removed what, from where, at what minute, under whose authority?" Only the second question survives a rebuttal, because Oracle's counter-evidence is a dated download log.
And you cannot beat a timestamp with a blank space.
Why the employee metric makes one missed host cost the same as a thousand
The Java SE Universal Subscription is priced on Employees, defined to include full-time, part-time and temporary staff plus the equivalent staff of your agents, contractors, outsourcers and consultants supporting internal business operations.
Quantity is set by headcount as of the order effective date, not by who touches the software. Oracle's own worked example on the price list runs a 28,000-employee company (23,000 staff plus 5,000 contractors) at 28,000 × $6.75 × 12 = $2,268,000 a year.
The published list has seven bands from $15.00 down to $5.25, ending at 49,999 employees, with a separate ceiling of 50,000 Processors (excluding desktops and laptops) before additional licences bite. A 4,000-person firm at the $10.50 band pays $504,000 a year.
A 12,000-employee estate pays $1,188,000 whether it runs four Oracle JDK installs or four thousand.
That flatness is the whole argument for spending money on removal evidence. Cost does not scale with install count, so reducing installs from 900 to 1 changes nothing about the invoice. Only reaching zero, and proving the date you reached it, removes the trigger.
Every un-evidenced host is therefore not a fractional exposure, it is a full-value one, and it carries the entire headcount bill on its own. The buyer controls exactly one variable here: evidence quality per host.
Discount negotiation, band placement, and processor counts are all downstream of whether Oracle accepts that the last install left on a specific day.
Fund the logging discipline as insurance against a seven-figure annuity, not as an IT hygiene line item, and pair it with an install inventory that is audit-defensible rather than merely complete.
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 →Dating removals against the 2026 licence cliffs
Removal dates only mean something when they are read against the licence boundary that applied to the version on that host.
Oracle has confirmed that JDK 21 updates through and including September 2026 remain under the No-Fee Terms and Conditions, and that from the October 2026 Critical Patch Update onward, JDK 21 updates move to the Java SE OTN licence, the same licence that already governs Java 8, 11 and 17.
JDK 22, 23 and 24 travel with 21.
That means the question an auditor asks is never simply "was it removed," it is "was the last patch you applied a free one, and did the host survive past the date its licence flipped." The JDK 17 precedent settles how this plays out: 17.0.12 in July 2024 was the last free build.
The NFTC expired in September 2024, and every later 17 release is OTN and chargeable in production.
Java 8 is the older and more expensive version of the same trap, because updates from 8u211 in April 2019 onward moved to OTN, which is why most retroactive claims we defend trace back to a 2019 or 2020 patch event, not a 2026 one.
On JDK 25 the sources genuinely conflict: Oracle's blog says October 2028, Oracle's downloads page says September 2028. Log to September 2028 and treat the extra month as unproven.
Pair every removal timestamp with the patch-application timestamp for that host, because the patch is the positive act Oracle can see and the removal is the negative one it cannot, as covered in reconstructing your Java download history when Oracle cites it.
| Version line | Last free update / cliff | Licence after cliff | What your log must date |
|---|---|---|---|
| Oracle JDK 8 | 8u211, April 2019 | OTN, paid in production | Every patch applied after Apr 2019, plus removal date |
| Oracle JDK 17 | 17.0.12, July 2024 (NFTC ended Sep 2024) | OTN, paid in production | Whether host stopped at 17.0.12 or took a later build |
| Oracle JDK 21, 22, 23, 24 | Updates through Sep 2026 | OTN from the Oct 2026 CPU | Removal or migration completed before the Oct 2026 CPU |
| GraalVM for JDK 21 | Sep 2026 | GraalVM OTN (incl. Early Adopter terms) | Same cliff, logged separately from the JDK |
| Oracle JDK 25 | Sep 2028 (downloads page) or Oct 2028 (blog) | OTN | Log to Sep 2028; the extra month is unproven |
The table looks like a patch calendar. It is actually a pricing schedule.
Each cliff converts a host that costs nothing into a host that triggers the Employee metric, and under that metric a 12,000-employee estate is on the hook for $1,188,000 a year at list whether the surviving install count is one or one thousand.
The economics of removal are therefore binary: you are not reducing a bill, you are deleting a trigger, and the trigger only disappears on the day you can prove the last chargeable artifact left the host.
Note the asymmetry the second column creates. Oracle does not have to prove the host ran a paid build after the cliff. It only has to show a download log entry for a post-cliff patch tied to your IP range, and then ask you when that host stopped existing.
If your answer is "some time in Q4," the whole quarter is chargeable. Date to the day, or expect Oracle to date it for you at the least favourable end of the range.
The reopening problem: why Oracle re-lists hosts you already removed
When Oracle re-lists a host you removed six months ago, the reflex inside most IT teams is to call it an error or bad faith. It is neither. It is the rational response of an auditor who is holding one kind of evidence and receiving another.
Oracle's evidence is a positive act with a timestamp: a download log entry carrying an account username or email, an IP address, a date and time, and the exact file pulled. Oracle keeps those records for years and has said so.
Your evidence, in most engagements, is an absence: a discovery scan showing that nothing called Oracle JDK is present today. Absence proves the present tense and nothing else. It is silent on the six years between the download and the scan, which is precisely the window Oracle is charging for.
That asymmetry is compounded by sequencing. Oracle scores the account before it makes contact, matching patch downloads to your IP ranges and building a working hypothesis about deployment scale. The person who emails you already knows a dated event occurred. They expect a dated event in reply.
A clean inventory export is not a dated event. It is a snapshot, and a snapshot arriving in response to a timestamped download record reads, to an auditor, as a non-answer.
Oracle's stated fallback when the customer cannot supply dates is to present the old download record and assume company-wide deployment, which under the Employee metric means the entire headcount.
The customer instinct that does the most damage is the urge to send a better inventory each round. Round one is a partial scan. Round two adds the endpoints. Round three adds the build agents and the container images.
Each export is more complete and more honest than the last, and each one resets the question to the present tense while quietly signalling that earlier answers were incomplete.
Oracle reads that sequence as evidence that discovery is unreliable, which is exactly the finding that justifies reopening hosts. Completeness is not the currency here.
A three-line ticket with a date beats a 4,000-row spreadsheet without one, which is the distinction we draw in making your Java install inventory audit-defensible, not just complete.
The underrated artifact is the change ticket, and it is underrated because engineers see it as bureaucracy rather than evidence. A scan records a technical state.
A change ticket records a business decision: a named requester, a named approver, a scheduled window, an outcome, and a closure timestamp. That transformation matters because Oracle's position on unauthorised installs is that "a contractor downloaded it without permission" is not a defence.
The Employee definition already sweeps in the staff of your agents, contractors, outsourcers and consultants, so the contractor argument fails on the contract's own wording.
The only thing that answers a positive act by an individual is a positive act by an accountable individual on your side, with a date. A change ticket is that. A scan is not.
Twenty-five years of arguing these files produces one durable rule. Evidentiary weight comes from when the record was created, not from how tidy it looks. A removal log written contemporaneously, in the ordinary course of business, before anyone knew an audit was coming, is a business record.
A reconstruction assembled after the audit letter, however meticulous, is advocacy, and every auditor is trained to discount advocacy. Reconstructions can be worth building when nothing else exists, and we build them, but they cost more, prove less, and rarely close a host permanently.
So the practical test for any removal log is not "does this look complete." It is "would this survive being read by someone who wants it to fail, three years from now, with no one from the original project still employed." That means the record must be created at the moment of removal.
Must carry a date to the day, must name a human, and must sit in a system that cannot be edited retrospectively without leaving a trail.
Get that right and reopening stops, because the auditor has nothing to push against. Get it wrong and every round of the audit starts from the same place: Oracle holds a dated event, you hold a snapshot, and the snapshot loses.
Running removal logging as a standing process, not an audit project
Removal logging fails when it lives in a spreadsheet owned by the Java team, because the spreadsheet has no immutable timestamp, no approver, and no retention policy, and the Java team disbands the moment migration is declared done.
The record has to sit inside the change management system, where each removal generates a ticket with a machine-readable close date, the hostname, the JDK version and build number, the executing engineer, and an attached artifact showing the absence of the binary after the fact.
Ownership belongs to asset management or ITAM, not to the engineering group that performed the work, for the simple reason that ITAM survives reorganizations and holds the CMDB that Oracle will ask you to reconcile against.
In practice the cadence that holds up is a monthly rescan of the full estate against a signature list, a 90-day verification checkpoint per removed host to catch redeployment, and a 12-month checkpoint to confirm the host has stayed clean through a patch cycle and a hardware refresh.
Retention has to match Oracle's side of the ledger: Oracle keeps download logs for years, so a three-year retention window on your removal records is not conservative, it is the minimum symmetry.
The most common source of reopened hosts in our engagement work is not the removal itself but the golden image, where an Oracle JDK remains baked into a template and reinstalls itself on every new build, silently restoring the exposure two quarters after the ticket closed.
Image hygiene therefore needs its own control: template scan on every publish, with the scan output filed alongside the removal tickets. The handover point is defined, not implied.
Once a removal ticket closes with its artifact attached, the record moves into the wider Java evidence file and is indexed by host so it can be produced against a specific Oracle claim in hours rather than weeks.
What the engagement record shows about which removals hold
Oracle ran low-conversion contact from roughly 2023, and that soft outreach has been converting to formal notices through 2026 as the JDK 21 cliff lands.
One application still running unlicensed Oracle JDK requires the subscription regardless of 3,000 clean hosts, because the metric is employees, not installs.
The recurring patterns across audit-defense engagements are narrow and repeat with unhelpful reliability. First, the same host list comes back in the second and third data request when the customer answered the first with inventory alone.
Inventory tells Oracle what you can see today, it says nothing about what left and when, so the auditor treats the gap between the download log and the current scan as unproven and re-lists the hosts.
Second, contractor and outsourcer endpoints are the most frequently reopened category, because they sit outside the customer's change management system entirely and the removal, if it happened, generated no ticket anyone can produce.
Third behind them are developer laptops and CI runners, where a build agent pulls an Oracle JDK from a cached artifact repository months after the estate was declared clean.
Fourth, and this is where buyers give away leverage, Oracle's own claims are frequently unsubstantiated at the host level and customers rarely test them.
You are entitled to ask Oracle to produce the specific download record, the account, the IP, the date, and the file, and to explain how a 2019 download of 8u211 establishes production deployment in 2026.
In our experience that request narrows the claimed population materially, because much of it is inference rather than evidence.
The uncomfortable arithmetic underneath all of it is that partial removal fails completely: the employee metric means a 12,000-employee estate owes $1,188,000 a year at list on the strength of a single surviving install.
So the value of a removal programme is entirely concentrated in the last few hosts you cannot date.
Treat those hosts the way you would treat a defensible install inventory, as items requiring an artifact, not an assertion.
- 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
- Freeze and date the current removal record set this week, exporting every uninstall log, inventory delta, and screenshot to write-once storage with a hash and a named custodian, because a record you can still edit is a record Oracle will argue you edited.
- Retro-fit change tickets and approvers to removals already performed, pairing each host with a ticket number, requester, approver, and completion timestamp; where the ticket never existed, write a signed attestation naming the engineer and the date rather than leaving the host silent, and file it into your Java evidence file alongside the entitlement proof.
- Run a 30-day confirmation rescan against a named host list, not a summary count, so every host that showed an Oracle JDK path has two dated observations (present, then absent) from the same discovery tool, which is the only pattern that survives the challenge described in making the install inventory audit-defensible.
- Align every removal timestamp to the October 2026 CPU boundary, because JDK 21, 22, 23, and 24 updates leave the NFTC at that Critical Patch Update; a removal you can prove landed before it is a no-fee position, and one you can only prove landed sometime in the fourth quarter is a negotiation you lose.
- Demand Oracle substantiate any download record before conceding a single host, requiring the account, IP, exact file, and timestamp in writing, and mapping each one to a host and a removal date; at 12,000 employees the difference between a rebutted record and an accepted one is $1,188,000 a year at list, so no host goes uncontested for the sake of speed.
Frequently asked questions
Does uninstalling Oracle Java remove my licence liability?
No, not for the past. Removal limits future exposure only, because Oracle may still rely on download logs that record the username, IP address, date, time and exact file downloaded, and Oracle has stated it retains those records for years.
Uninstalling closes the forward risk; only a dated removal record plus proof that no usage occurred after that date addresses the backward claim.
What evidence proves an Oracle JDK install was actually removed?
Three artifacts together: a removal record showing hostname, full version string, install path and a timestamp to the minute with timezone; a change ticket referencing that host with a named human approver; and a post-removal scan taken at least 30 days later showing the host clean.
A single inventory export showing absence is the weakest form of evidence, because it proves the present state and says nothing about the date usage stopped.
How long should we keep Java removal logs?
At minimum, match Oracle's own retention. Oracle keeps download records for years, so a removal log destroyed after 12 months leaves you unable to rebut a download entry from 2019 or 2021.
Treat removal records as permanent audit artifacts held for the life of the estate plus the applicable contractual claim period, and store them where they survive tooling changes.
What happens to Oracle JDK 21 in October 2026?
Beginning with the October 2026 Critical Patch Update, Oracle JDK 21 updates move from the No-Fee Terms and Conditions to the Java SE OTN licence, the same licence that already applies to Java 8, 11 and 17. GraalVM for JDK 21 moves on the same date.
Updates through and including September 2026 remain under the NFTC, so a removal or patch decision dated before that boundary is materially different from one dated after.
Is it enough to remove Oracle Java from most systems?
No. A subscription is avoidable only if all Oracle JDK deployments are removed and replaced with an OpenJDK distribution.
If any single application continues to use unlicensed Oracle JDK, the Universal Subscription applies at full employee count, which is why one contractor laptop or one CI runner carries the same cost as the whole estate.
Can we argue that a contractor downloaded Oracle Java without authorisation?
That defence does not work. Oracle is not persuaded by claims that the organisation was unaware of improper use or that a subcontractor or employee downloaded the product without permission.
The employee metric already includes the staff of agents, contractors, outsourcers and consultants, so the practical counter is your own internal audit plus change tickets showing who authorised, and who removed, each install.
Should we accept Oracle's list of downloads at face value?
No. You are entitled to ask Oracle to substantiate the records it cites, including the account, IP range, date and file for each entry. Buyers routinely concede hosts on the strength of a summary spreadsheet that Oracle never had to evidence.
Ask for the detail first, then match each entry against your removal log before you agree that a single host was in scope.
