A complete Java scan tells you what you have. A defensible one is the difference between paying for 200 installs and paying for 12,000 employees, because it strips out the noise Oracle counts as revenue.
A complete Java scan tells you what you have. A defensible one is the difference between paying for 200 installs and paying for 12,000 employees, because it strips out the noise Oracle counts as revenue.
Most organizations run a Java discovery scan, get a spreadsheet with a few hundred or a few thousand rows, and consider the inventory done. It is not done. It is raw material. When Oracle's License Management Services (LMS, now branded GLAS) reviews an estate, they do not accept a count at face value. They test attribution, question exclusions, and treat every ambiguous row as chargeable until you prove otherwise. In our audit-defense practice, the gap between a complete inventory and a defensible one has been worth 60 to 90 percent of the claimed exposure, removed before the commercial conversation even started.
This page is about that gap. Not how to scan, but how to make the output survive Oracle scrutiny: timestamps that establish when installs appeared and were removed, version attribution that separates Oracle JDK from OpenJDK builds, documented exclusions, and methodology notes that show your work. If you have not yet built the surrounding record set, start with building the Java evidence file, of which this inventory is the technical core.
Understand the commercial mechanics before you touch the data, because they explain why defensibility matters so much. Since January 23, 2023, Oracle sells Java under the Java SE Universal Subscription, priced on an Employee metric. List runs $15.00 per employee per month at 1 to 999 employees, $12.00 at 1,000 to 2,999, $10.50 at 3,000 to 9,999, and drops to roughly $5.25 at 40,000-plus. The metric counts all full-time, part-time, and temporary employees, plus the staff of your agents, contractors, outsourcers, and consultants who support internal operations. Named User Plus and Processor licenses for Java stopped being sold in 2023.
The consequence is brutal and non-intuitive. A company with 200 Java installs can open a letter that prices 12,000 people. The size of your Java footprint does not set the price. The size of your workforce does, once Oracle establishes that you owe anything at all. That single fact reframes the entire purpose of your inventory: it is not there to size the bill. It is there to prove you owe nothing, or to shrink the population of hosts that could trigger the employee-count charge.
A company with 200 Java installs can open a letter that prices 12,000 people. Your inventory does not size the bill. It proves whether you owe one at all.
Across roughly 35 to 45 Oracle Java audits we defended in 2024 and 2025, Oracle's first finding priced 100 percent of employees even where Java ran on 10 to 20 percent of machines. Download evidence from java.com accounts drove 30 to 50 percent of the claimed exposure. Oracle opened on the full employee count and settled 5 to 15 times lower once the estate was evidenced rather than assumed. The evidence did the work. A raw scan does not qualify as evidence.
A raw scan fails on four fronts, and each one hands Oracle leverage. First, version attribution: scripts routinely misclassify free OpenJDK builds as chargeable Oracle JDK. Second, dating: without reliable install and removal timestamps, you cannot prove a host was retired before the audit date or first appeared under a free license. Third, deduplication: a single physical install often generates multiple registry or filesystem entries, and bundled runtimes inside other products get counted separately. Fourth, methodology: an undocumented scan cannot be defended when Oracle asks how it ran, what version of the collection script produced it, and what it excluded.
Oracle's own auditors exploit these gaps deliberately. In one case, Oracle scripts discovered Java on 800 machines against 500 previously licensed, all carrying update levels from 2021 to 2023 that Oracle treated as evidence of unpaid commercial usage. Update-level metadata is itself a weapon. If your inventory does not capture and contextualize it, Oracle's version does, and theirs is the one that gets believed.
This is where most inventories quietly break. Not all Java is Oracle Java, and not all Oracle Java is chargeable. But the properties scripts read do not tell you cleanly. When you query the java.vendor property on an OpenJDK build, it can return "Oracle Corporation." A naive vendor-string check therefore falsely attributes a free OpenJDK runtime to a paid Oracle product. Distributions like Amazon Corretto and Azul Zulu are OpenJDK builds with vendor-specific strings; one-liner detection scripts misclassify them as Oracle JDK because they do not contain the token "OpenJDK."
There are more traps. The java -version command prints to stderr, not stdout, and its format varies between distributions, so scripts that parse stdout silently return nothing. Java bundled inside WebLogic or Oracle Database may carry entirely different rights than a standalone install. Old, unused versions on decommissioned-but-not-wiped systems still register as installs. Each of these produces a false positive that Oracle will price. Your inventory must attribute every install to a specific distribution and vendor, using multiple signals (install path, package metadata, binary signature, release file contents), not a single vendor string.
Whether an Oracle install is even chargeable depends on version and update level under the No-Fee Terms and Conditions (NFTC) license. Get the version-level facts right and you can move installs off the ledger entirely. The table below shows the version boundaries that matter as of the research date.
| Oracle JDK version | License / free status | Key date |
|---|---|---|
| JDK 8, 11 (legacy) | OTN, paid for commercial use since Jan 2019 | Jan 2019 update paywall |
| JDK 17 | NFTC free ended Sep 2025 | Updates after Sep 2025 not free for commercial production |
| JDK 21, 22, 23, 24 | NFTC free until Sep 2026 | Hosts still on these after Sep 2026 fall outside the grant |
| Any version with commercial features enabled | NFTC not valid, chargeable | Additional fee regardless of version |
Defensible NFTC status depends on the same underlying data for every host: which version and update level is installed, whether any commercial feature is enabled, what the host does, and whether Java is actually being used on it. If your inventory captures version but not update level, or attribution but not commercial-feature usage, it cannot support the NFTC argument. Document which installs are already free or licensed in a dedicated entitlement proof file so the exclusion is evidenced, not asserted.
Whether an install is free is a version-and-update-level question. If your inventory captures version but not update level, it cannot support the NFTC defense that removes the install from the ledger.
Oracle's auditors ask a predictable question: "When was Java first installed on these systems?" They ask it to set a start date for calculating back fees, often reaching back to January 2019 when Java SE updates became paid for commercial use. Every year of claimed unlicensed use compounds, because Oracle adds a support uplift of roughly 22 percent per year on top of the license fee. A weak install-date position turns one year of exposure into five or six.
Your inventory must therefore carry two timestamps per host wherever the operating system provides them: first-installed date (from package manager records, MSI install metadata, or filesystem creation times), and last-seen or scan date. Together these establish the window during which each install existed. Update-level metadata acts as a corroborating third signal, because a runtime patched to a 2016 release supports a 2016 install narrative that predates the paid model. Reconstruct download history alongside install dating; our guidance on reconstructing your Java download history when Oracle cites it covers how to reconcile Oracle's download logs against your actual deployment record.
The removal side matters just as much. Hosts retired before the audit date are out of scope. But Oracle will not accept a bare assertion that a machine was decommissioned. You need a removal log with standards: the host identifier, the removal date, the method (wiped, reimaged, uninstalled), and the person or ticket authorizing it. Get this wrong and Oracle reopens hosts you thought were closed. Follow disciplined removal and decommission log standards so a retired host stays retired.
An audit-defensible inventory is honest about what it excluded and why. Exclusions are not omissions; they are decisions, and every decision needs a documented rationale. Bundled JREs shipped inside Oracle products with their own licensing, OpenJDK distributions confirmed by multiple attribution signals, development-only tooling, and retired hosts each belong in an exclusion register, not silently deleted from the file. The register should record the count excluded, the reason category, and the evidence supporting each category.
This matters for a practical reason. If you hand Oracle a filtered inventory with no exclusion register, they assume you filtered to hide chargeable installs, and they inflate accordingly. If you hand them a clear population of, say, 1,850 detected Java signatures reduced to 210 chargeable Oracle installs through documented exclusions, you control the narrative. The exclusions are your argument written down.
The final layer separates an inventory that survives challenge from one that collapses under it. Oracle will ask how the scan ran. You need a written methodology attached to the file: what tool or script produced the data, which version of that script, the date range of collection, the scope of systems in and out, and the account privileges used. Oracle updated its own detection script after Java 17 introduced different terms; an old script version can flag installations no longer at issue. If Oracle runs the scan, insist on knowing which version and document it. If you run it, document yours the same way.
A hard rule from 25 years of these engagements: never allow Oracle to run scanning tools or take unchecked access to your systems without a clearly defined scope and a nondisclosure agreement in place. Their script is optimized to find revenue, not to give you a fair count. When you produce your own methodology-documented inventory first, you set the baseline and force Oracle to argue against evidence rather than dictate it. Baird Holm and multiple licensing advisors reach the same conclusion: run your own internal audit, analyze usage against permitted use, and act on the gaps proactively to limit retroactive fees.
Be deliberate about what leaves your building. A methodology-complete inventory is powerful internally and, when scoped correctly, in negotiation. But not every field belongs in Oracle's hands. Before you respond to any data request, read what to provide and what to refuse and consider keeping the working analysis under privilege and off Oracle's desk. The inventory that wins the argument is not always the one you disclose in full.
Oracle tracks Java binary downloads in detail: IP addresses, corporate domain associations, download timestamps, and account information used at download. Installed copies not affirmatively disconnected send automatic update check-ins to Oracle's servers. This is why an audit letter can name your company before you have said a word. But download and telemetry data has a fatal weakness that a good inventory exploits.
Downloading Java is not deploying it. Deploying it in 2016 under a free license is not owing retroactive fees under a 2023 pricing model. Oracle's download logs create the illusion of evidence, not the substance of it. Your install inventory, with attribution, timestamps, and documented exclusions, is the only record that shows what is actually running, on which version, under which license, right now. That is why the estate evidence beats the download logs, and why removing telemetry from retained legacy installs (by disabling auto-update) is part of a controlled position. For the telemetry mechanics, see what Oracle Java telemetry actually transmits.
Treat your inventory as a legal exhibit, not an IT report. Re-run discovery with multi-signal version attribution so no OpenJDK build gets counted as Oracle. Capture install date, last-seen date, and update level on every host. Build an exclusion register with a reason and evidence for each category. Write the methodology notes: tool, version, scope, date, privileges. Cross-reference retired hosts to a formal removal log. Then, and only then, do you have something that survives Oracle scrutiny and pulls 60 to 90 percent of the claimed exposure off the table before you negotiate a cent.
If Oracle has already made contact, do not respond with a raw scan and do not let their script run unscoped. Get the inventory to defensible standard first. Our flagship Oracle Java audit defense runs the full lifecycle from controlled first response through evidence, OpenJDK leverage, and settlement, and the defensible inventory is where it starts.
A complete inventory lists installs. A defensible one attributes each install to a specific vendor and distribution, records first-installed and removal timestamps, captures version and update level, documents exclusions with evidence, and attaches methodology notes stating which tool and version produced the data. It is built to survive Oracle challenge, not just to inform IT.
Because the java.vendor property can return "Oracle Corporation" even on free OpenJDK builds, and distributions like Amazon Corretto and Azul Zulu carry vendor-specific strings that naive scripts misclassify as Oracle JDK. A single misattributed row becomes a chargeable install in Oracle's finding. Multi-signal attribution using install path, package metadata, and release-file contents prevents free builds from being priced.
Oracle sets a back-fee start date from when Java was first installed, often reaching to January 2019 when commercial updates became paid, and adds roughly 22 percent annual support uplift that compounds every year. Reliable first-installed dates limit how far back the claim reaches, and documented removal dates prove retired hosts are out of scope.
No, not without a clearly defined scope and a nondisclosure agreement, and even then with caution. Oracle's script is optimized to find revenue, and an outdated version can flag installs no longer at issue. Produce your own methodology-documented inventory first so you set the baseline and force Oracle to argue against evidence.
Oracle's download logs record IP addresses, domains, timestamps, and account data, and installed copies send auto-update check-ins. But downloading is not deploying, and a 2016 free-license deployment does not create 2023-model back fees. An install inventory with attribution, dating, and exclusions shows what is actually running and under which license, which is the record that governs the negotiation.
In our practice across roughly 35 to 45 Oracle Java audits in 2024 and 2025, a verified inventory removed 60 to 90 percent of claimed exposure before the commercial conversation, and Oracle settled 5 to 15 times lower than its opening number once the estate was evidenced rather than assumed on the full employee count.
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.
