Oracle opens a Java audit on your entire employee count, then settles 5 to 15 times lower once your estate is evidenced. This guide is the buyer-controlled record that produces that result: what to preserve, what to generate, and what to keep off Oracle's desk.
Oracle opens a Java audit on your entire employee count, then settles 5 to 15 times lower once your estate is evidenced. This guide is the buyer-controlled record that produces that result: what to preserve, what to generate, and what to keep off Oracle's desk.
In twenty-five years of negotiating Oracle Java positions, the single most reliable predictor of a low settlement is not the negotiator's skill. It is the quality of the evidentiary record the buyer walks in with. Oracle's Global Licensing and Advisory Services (GLAS) team opens almost every Java case the same way: it asserts a liability figure calculated on your full employee count under the Java SE Universal Subscription, then waits for you to disprove it. If you cannot disprove it with records, you pay it.
That is the mechanic buyers underestimate. The Java employee metric counts your entire workforce (full-time, part-time, temporary staff, plus agents, contractors, and consultants under Oracle's own price-list definition), not the number of people who touch Java. A 4,000-person company at the $15 per employee per month list tier faces a headline annual figure of $720,000 regardless of whether four servers or four hundred run Oracle Java. The only thing that moves that number down is a documented, defensible record of what is actually installed, what is already free or licensed, and what has been removed.
This article is deliberately narrow. It is not the response playbook and it is not the detection or triggers analysis (those live elsewhere in this hub). It covers one thing: the evidentiary discipline you control before GLAS engages, and the chain-of-custody that keeps your own records from becoming Oracle's ammunition. Everything here is buyer-side data hygiene. Get it right and the negotiation becomes arithmetic. Get it wrong and there is no negotiation, only a bill.
Oracle opens on the full employee count. It settles 5 to 15 times lower only when your estate is evidenced. The record you keep is the leverage you have.
An audit-grade Java evidence file is not a spreadsheet of hostnames. It is a reconciliation that answers four questions for every Java installation in your estate, and for the estate as a whole. Each answer must be defensible with an artifact Oracle cannot wave away.
The reconciliation matters because Oracle's own primary evidence is weak. Oracle's principal artifact in a Java audit is its download log, which records the email address, IP address, Java version, and download date for every pull from its sites. That is circumstantial. A download does not prove a current, production, license-requiring deployment. But if you have no counter-record, Oracle's log becomes the only record, and the only record wins. Your file exists to make Oracle's download log the weaker piece of evidence, not the stronger one.
Most organizations can produce a Java inventory. Very few can produce a defensible one. The difference is evidentiary provenance. A defensible inventory records not just that Java exists on a host, but how you discovered it, when, and with what tool, so that when Oracle challenges a data point you can show the collection method rather than argue from memory.
Build the inventory yourself, using your own configuration management database, endpoint management tooling, or a purpose-built discovery scan. Do not build it from Oracle's scripts (more on that below). Capture the Java vendor string precisely, because the phrase "we run Java" collapses under scrutiny into three very different license positions. Our guide on making your Java install inventory audit-defensible walks through the field-level structure and the provenance metadata each record needs.
The vendor distinction is the single highest-value column in the file. In one real case, a financial-services company with 4,000 employees received a soft audit, and analysis of its own inventory showed that the overwhelming majority of installations were OpenJDK, not Oracle JDK. The remaining Oracle JDK instances sat in non-production environments covered by existing OTN terms. Oracle withdrew the claim entirely. That outcome was not negotiated. It was evidenced. The company simply proved, install by install, that Oracle's download-log inference did not translate into licensable Oracle JDK deployments.
An inventory that says 'we run Java' is worthless. An inventory that says 'this host runs OpenJDK 17.0.9, not Oracle JDK' is a claim withdrawal waiting to happen.
Once you know what is installed, you must prove what each install is entitled to run under. This is where the Java licensing regime punishes the unprepared, because the free grant is both version-bound and time-bound, and it changes as new Long-Term Support (LTS) releases ship.
The NFTC license, introduced in September 2021, permits free use of the current LTS version of Oracle Java from its release until one year after the next LTS version ships. Concretely, Oracle has stated that JDK 21 updates remain available under the NFTC until September 2026, one year after JDK 25 LTS released in September 2025. The moment that window closes, a host still running that version under NFTC needs a paid subscription or a version move. Your evidence file must record the version and update level per host precisely enough to place each one on the correct side of that line.
OTN is the second trap. Older Oracle JDK 8, 11, and 17 releases fall under the Oracle Technology Network License Agreement, which permits development, testing, and personal use but bars production use. A host running OTN-licensed Oracle JDK in production is out of compliance the moment it enters production, regardless of employee count arithmetic. Conversely, an OTN install genuinely confined to non-production is defensible, which is exactly how the 4,000-employee case above closed. The evidence must therefore capture not only version and license terms but the environment classification (production versus non-production) with something more durable than an assertion.
| License regime | Covers | Production use | Evidence the file must hold |
|---|---|---|---|
| NFTC | Current LTS, until one year after next LTS ships | Permitted, but time-bound | Per-host version and update level; the NFTC end date for that version |
| OTN | Older Oracle JDK 8, 11, 17 | Prohibited | Environment classification (non-prod) with a durable artifact, not a claim |
| Java SE Universal Subscription | Any Oracle JDK, any use | Permitted | Order document, entitlement quantity, effective date, employee metric basis |
| OpenJDK (non-Oracle build) | Corretto, Azul, Adoptium, and others | Permitted, no Oracle fee | Vendor string in inventory proving the build is not Oracle's |
This mapping is not academic. It is the spine of the file. Our detailed treatment of documenting which Java installs are already licensed or free covers how to build the per-host proof so that when Oracle asserts a subscription requirement, you answer with a regime and an artifact, not a hope. And because Oracle cites different clauses depending on your contract vehicle, cross-reference which audit clause Oracle is actually citing before you accept its framing of your obligations.
Oracle will cross-compare the inventory you submit against its own download records. If its log shows you downloaded Java 8 update 241 in 2021 from a corporate IP, it will expect to find that install in your deployment data, and it will treat any absence as either concealment or unlogged usage. This is precisely why you must reconstruct your own download history before Oracle presents its version.
Reconstruction means pulling your own records of what was downloaded, by whom, from where, and mapping each download to a current disposition: still installed and licensed, still installed and free, removed (with a decommission log entry), or never deployed. A download that was pulled to a test machine and deleted the same week is not a liability, but only if you can show it. The Java download history reconstruction guide details the sources to mine (proxy logs, endpoint records, procurement tickets) and how to build the disposition map.
There is a related telemetry dimension buyers routinely miss. Oracle Java installations can transmit data, and Oracle's download and support systems already hold identifying detail before any audit letter arrives. Understanding what Oracle already knows from Java telemetry and download logs tells you which of your records Oracle can already contradict, which is exactly the set you must reconcile most carefully. Never submit an inventory you have not first reconciled against what Oracle can independently see.
During a formal audit Oracle will ask you to run its LMS scripts or the ReviewLite tool and hand back the output. Understand precisely what these scripts do: they collect data on all Oracle products on the host, not just Java. Oracle uses that broader collection to discover compliance gaps in database, middleware, and options you never intended to expose in a Java matter. Running an unreviewed Oracle script is the fastest way to convert a Java audit into a full-estate audit.
The chain-of-custody discipline here is non-negotiable. Never run Oracle's scripts without first reviewing them in an isolated test environment. Verify the exact scope of data collection. If the audit is contractually limited to Java, insist the script collection be limited to Java, and confirm which script version you are being asked to run, because Oracle updates these tools roughly twice a year and they are not publicly downloadable. Ask, in writing, which version and what fields it captures before it touches a single production host.
The better posture, wherever your contract permits, is to generate the evidence yourself using your own tooling and provide validated output rather than raw Oracle-script data. Running the equivalent of an internal Oracle license audit ahead of Oracle gives you the same data Oracle wants, but under your control, reviewed before it leaves the building. When you do this well, you can often satisfy the cooperation obligation with your own dataset and avoid handing Oracle a script that reaches beyond Java.
An unreviewed Oracle script turns a Java audit into a full-estate audit. Test it, scope it to Java, and log the version before it touches production.
Removing Oracle Java to reduce exposure is sound, but removal without a record is worse than no removal at all, because Oracle can point to a historic download and you cannot prove the install is gone. Every retirement needs a log entry: host, version, install path, removal date, removal method, and the person or process that executed it. That log is the artifact that stops Oracle from counting a January install in a June audit.
Timing and method both matter to defensibility. A removal executed and logged before the audit notice arrives is materially stronger than one done during the audit window, which Oracle may characterize as evidence tampering. Follow disciplined Java removal and decommission log standards so that each retirement is provable, dated, and closed in a way Oracle cannot reopen. The log is not a formality. It is the difference between an install you retired and an install Oracle bills you for.
Not all of your evidence problems come from downloads. Every request you submit through My Oracle Support creates a record of which Oracle products you use and how. Oracle's GLAS team has access to that data. A support ticket that references a Java feature, a version, or an option not covered by your current entitlement can inform or even initiate an audit. This is ambient evidence you generate without thinking about it, and it lives on Oracle's systems, not yours.
The discipline is preventive. Review what your teams reference in support interactions, and treat MOS the way you would treat any communication that Oracle's licensing arm can read. This is not about withholding legitimate support requests. It is about awareness that your operational records and your compliance records are the same records to Oracle, and that careless phrasing in a ticket can undercut a carefully built inventory. Where you can, keep detailed licensing-status analysis out of channels Oracle controls.
The most dangerous document in a Java audit is often one you created: an internal exposure estimate, an email conceding that a set of hosts "probably needs licensing," or a self-assessment that assumes the worst. If that document is discoverable, it can become Oracle's opening figure. The evidence file has two layers, and they must not be confused: the factual, provable record you intend to share, and the analytical, deliberative work product you must protect.
Route sensitive analysis through counsel and structure it to preserve legal privilege where your jurisdiction recognizes it. Mark work product accordingly, and keep speculative exposure math out of freely circulating email threads. Our guide to keeping Java audit records under privilege and off Oracle's desk details the practical mechanics. The principle is simple: facts are for Oracle when you choose to share them; your interpretation of those facts is for your side only.
The most expensive sentence in a Java audit is one your own team wrote: 'these hosts probably need licensing.' Keep interpretation privileged; share only proven facts.
Because the Java SE Universal Subscription is priced per employee, and because Oracle's definition of employee sweeps in contractors, agents, and consultants, the headcount figure is a decisive input Oracle will try to set to your disadvantage. The contractual language is unambiguous: the licensed quantity must at minimum equal the number of employees as of the order's effective date, counting the total workforce rather than actual Java users. Oracle will reach for the largest defensible number, often your published headcount or a LinkedIn-derived figure, because a higher count is a higher bill.
Establish your own source of truth before Oracle proposes one. Define which categories count, document the number from your HR and procurement systems, and hold that figure with the same provenance discipline as the install inventory. If Oracle's figure and yours diverge, you want to be the party with the sourced, dated, defensible number. Building an internal source of truth for the Java employee count is the difference between negotiating from your data and reacting to Oracle's estimate. This is one metric the evidence file cannot reduce, only measure accurately, so accuracy is the entire game.
The cooperation clause is real but bounded. The standard audit clause gives Oracle the right, on 45 days' written notice, to audit your use to confirm compliance, and it requires reasonable assistance, which the Master Agreement expressly extends to running Oracle's measurement tools and providing the resulting data. But the same clause states the audit must not unreasonably interfere with your normal business operations, and market practice and the contract together limit an audit to once per year, during business hours, reaching only the programs and legal entities the agreement covers. An audit that exceeds those conditions is exceeding the contract, and you are entitled to say so.
That 45-day notice window is not a courtesy. Its function is preparation time: it is the interval in which you read the contract, scope the audit, complete internal discovery, and decide what leaves the building before any data changes hands. Treat it as the most valuable 45 days you will spend on the matter, because the file you finish in that window is the file that determines the settlement.
When Oracle issues its data request, respond with proven facts scoped to Java, and refuse or narrow requests that reach beyond the contractual scope. You are not obligated to volunteer raw script output covering non-Java products, and you are not obligated to accept Oracle's download log as proof of deployment. You may, and should, demand that Oracle put its evidence in writing and produce tangible proof of actual installation or active use before you concede any figure. Our guidance on what to provide and what to refuse in a Java data request maps the line between reasonable cooperation and overreach.
Be aware of the 30-day payment trigger buried in the clause: you agree to pay within 30 days of written notification any fees applicable to use in excess of your rights. That trigger fires on Oracle's findings, not on the truth, which is one more reason the findings must be built on your evidence, not Oracle's inference. The stronger your file, the less there is to notify.
The order in which you assemble the evidence determines whether it holds together. Discovery before disclosure is the governing rule: know everything Oracle might raise before Oracle raises it, so nothing in Oracle's download log surprises you and nothing in your own submission contradicts a record Oracle already holds.
| Step | What you build | Why the order matters |
|---|---|---|
| 1 | Own install inventory (vendor, version, path, host, environment) | Everything downstream reconciles against this; build it first, from your tools |
| 2 | License-status mapping (NFTC / OTN / subscription / OpenJDK) | Turns raw inventory into a liability position, install by install |
| 3 | Download history reconstruction and disposition map | Pre-empts Oracle's log cross-comparison; reconcile before you submit |
| 4 | Decommission log for all removals | Stops Oracle counting retired installs; log before the notice, not during |
| 5 | Employee count source of truth | Fixes the metric input before Oracle proposes its own figure |
| 6 | Privileged analysis layer, held separately | Keeps your interpretation off Oracle's desk while facts stay ready to share |
Run this sequence proactively, ideally on an annual internal cycle rather than only when a notice arrives. The organizations that settle 5 to 15 times below Oracle's opening figure are not the ones with the best lawyers. They are the ones that had steps one through six already built when the letter came, so the 45-day window was spent negotiating from evidence rather than scrambling to create it.
A mature Java evidence file lets you respond to any Oracle assertion with an artifact rather than an argument. Oracle says you downloaded Java 8; you show it was retired in 2023 with a logged decommission. Oracle says a host needs a subscription; you show it runs OpenJDK, not Oracle JDK. Oracle says another needs one; you show it runs the current LTS under a valid NFTC window. Oracle prices on 8,000 employees; you produce your sourced count of 6,200 with the category definitions documented.
Each of those exchanges shaves the claim, and together they are how a headline employee-count figure collapses to a fraction of itself. The file does not make you compliant if you are not; it makes you provable where you are, which is a different and more valuable thing. It converts a vendor assertion into an evidentiary contest, and in an evidentiary contest the party with the sourced, dated, per-host record wins. For the full lifecycle around this evidentiary core, see the flagship Java audit defense engagement, which runs from controlled first response through settlement with the evidence file at its center.
Start now, not on notice. The single action worth taking this quarter is step one: build your own Java install inventory, with the vendor string captured precisely, so that the day Oracle's letter arrives you already know the answer to the only question that matters, which is what you actually run and under what right.
No. A download record shows the email, IP, version, and date of a pull, but it does not prove current, production, license-requiring deployment. It is circumstantial. You are entitled to demand that Oracle produce tangible evidence of actual installation or active use, and a defensible install inventory can rebut the log entirely.
Only after reviewing them in an isolated test environment and confirming scope. These scripts collect data on all Oracle products, not just Java, and Oracle uses the broader output to find gaps in database and middleware. Insist the collection be limited to Java, confirm the script version, and where possible provide your own validated data instead.
Reconstruct your download history far enough back to cover any version Oracle's log might cite, then map each download to a current disposition: still installed, removed, or never deployed. Retired installs need a dated decommission log, ideally created before the audit notice arrives, so Oracle cannot count them.
The Java SE Universal Subscription prices per employee, and Oracle's definition counts the total workforce including contractors and consultants, not just Java users. The file cannot reduce this metric, only measure it accurately. Establish your own sourced, dated headcount before Oracle proposes a larger figure from your public data.
Oracle holds download logs with identifying detail, and its GLAS team can access My Oracle Support tickets that reference your product use. Any record living on Oracle's systems can contradict your submission, so reconcile your inventory against what Oracle can independently see before you hand anything over.
Separate the two layers of your file: shareable factual records and protected analytical work product. Route sensitive exposure estimates through counsel to preserve privilege where recognized, mark work product accordingly, and keep speculative liability math out of freely circulating email. Facts are for Oracle when you choose; interpretation is for your side only.
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.
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.
