Under the employee metric, installs do not drive the bill, but they decide which uses you must never concede to Oracle. This is how you assemble the proof file that keeps NFTC, bundled, and legacy-covered installs out of the paid count.
Under the employee metric, installs do not drive the bill, but they decide which uses you must never concede to Oracle. This is how you assemble the proof file that keeps NFTC, bundled, and legacy-covered installs out of the paid count.
Since the 2023 Java SE Universal Subscription moved to an employee-based metric, a common misconception has taken hold: that because you now pay per employee rather than per install, the install list no longer matters. That is half right and dangerously so. A high install count does not increase your subscription cost, but every install you fail to attribute to a free or already-licensed basis becomes a data point Oracle uses to argue that your entire population is deployed and therefore should be subscribed. The purpose of the proof file is not to reduce a per-install charge. It is to remove specific installs from the conversation entirely, so they never appear in the paid population that Oracle tries to anchor the employee count against.
In 25 years negotiating Oracle Java positions, the single most expensive error we see is a company buying a subscription for deployments that were already covered, either by the No-Fee Terms and Conditions (NFTC), by bundled restricted-use rights inside another Oracle product, or by a legacy perpetual or subscription entitlement. Redress Compliance's own entitlement reviews consistently identify six-figure overspend from exactly this failure to map deployments to their license basis. The proof file is the artifact that prevents it. It sits alongside your audit-defensible install inventory and your broader Java evidence file, but its focus is narrow: proving a specific install is free or covered.
Installs do not drive the bill. But an undocumented install is an install Oracle counts as deployed, and deployed is the word that anchors your employee number.
Every Oracle Java install on your estate falls into one of four categories: paid (subscription required), NFTC-free, bundled restricted-use, or legacy-covered. The proof file exists to move installs out of the first category and into one of the other three, with evidence that survives an audit. Each basis has a different evidentiary standard, and the version-string trap means you cannot prove any of them without full build numbers, not just a marketing version like "Java 8" or "Java 17."
| Basis | What it covers | Proof required in the file | Expiry risk |
|---|---|---|---|
| NFTC (No-Fee) | Oracle JDK 17 and later, inside the free window | Full build number, install date, capture that build predates the NFTC cutoff for that version | High: windows close ~1 year after next LTS ships |
| OTN / legacy free build | Oracle JDK 8 up to 8u202; personal/dev-only use post-8u211 | Exact build number (8u202 vs 8u211), usage-type evidence (dev vs production) | Fixed: 8u202 is free forever, later builds are not |
| Bundled restricted-use | Java used only within WebLogic, EBS, PeopleSoft, JDE, Fusion Middleware | Product license, LMS/Support note quoting the bundled grant, proof the Java use stays inside the app boundary | Voided the moment Java runs anything outside the host product |
| Legacy subscription / perpetual | Prior NUP, Processor, or perpetual Java SE Advanced/Suite | Original ordering document, renewal proof, entitlement counts | Renewal conditional on Oracle usage validation |
The NFTC permits free use of Oracle JDK 17 and later, including commercial and production use, but it expires on a published schedule. JDK 25 shipped in September 2025; versions 21 through 24 remain free under the NFTC until September 2026, after which hosts still running those versions fall outside the no-fee grant. JDK 25 updates are planned to remain under the NFTC until September 2028, roughly one year after Java 29 ships in September 2027, at which point Oracle intends to move JDK 25 updates to the OTN license.
The critical proof point most companies miss is that NFTC coverage is per build, not per version line. For Oracle Java 17, the free-patch window ended in September 2024, and the last no-cost update was 17.0.12.0.2 released in August 2024. Any 17.x build downloaded before that date remains under the NFTC and is documentably free. Any 17.x build after it does not. So your proof file for a Java 17 install must capture the exact build number and, ideally, the download or install date, demonstrating the build predates the cutoff. Our full version-by-version map lives in which Java versions are free, and the free-versus-paid line detail sits in which Java versions trigger a bill.
Java 8 is where the proof file earns its keep, because a Java 8 install reports its version as 1.8 whether it is free or licensable. Only the exact build number answers the question. Oracle JRE 8u202 and earlier remain free for commercial use under the old Binary Code License. From 8u211 onward, the same installer carries the OTN license, free for personal and development use but chargeable for business use. That means two servers that both report "1.8" can have completely different license outcomes, and the only distinguishing evidence is the build number your inventory captured.
A Java 8 install reports 1.8 whether it is free or billable. The build number is the entire case. If you did not capture it, you have no proof, and Oracle knows it.
For post-8u211 builds you claim under OTN as development or personal use, the proof file needs a second layer: evidence of the usage type. A build number alone shows the license, but OTN's free grant is conditional on non-production use. So for those hosts you need to document that the environment is genuinely development or test, not production serving business operations. Combine that with your reconstructed download history so that where Oracle cites its own download logs, you can match a specific download to a specific, documented free build.
Oracle products including WebLogic Server, E-Business Suite, PeopleSoft, JD Edwards, and Fusion Middleware components all include Java SE rights as part of their standard entitlements. But these are restricted-use rights: they cover Java use only within the specific application boundary of the licensed product. WebLogic Server EE, for example, includes a restricted-use license for Oracle Java SE Advanced, and Oracle's own documentation states that Java SE and all associated components are restricted for use with WebLogic Server. This is a real and valuable basis, and it removes a meaningful slice of installs from the paid count, but only if you prove both the entitlement and the boundary.
The trap that voids the bundled defense is that WebLogic and EBS servers are rarely dedicated. They also run scripts, agents, monitoring tools, batch processes, and sometimes standalone Java applications. Every one of those that uses the Oracle JDK sits outside the WebLogic restricted-use right and needs its own Java SE entitlement. So a bundled-rights proof entry is not just "this server runs WebLogic." It is: the product license, the Oracle Licensing Information manual or Support note quoting the bundled grant, and evidence that the Java on that host is used only by the covered product. Keep a snippet on hand such as "a restricted-use license of WebLogic Server Standard Edition is included with product X," because during an audit you may need to demonstrate that Java usage on a server is covered by your EBS or WebLogic license, and Oracle will not volunteer that language for you.
One documented exception is worth flagging in the file: Oracle Coherence uniquely provides a full-use Java SE license, entitling you to use Java SE not just for Coherence but for general purposes. Most bundled grants are restricted-use; Coherence is the outlier. If you hold Coherence, capture that entitlement, because it is materially more valuable than a WebLogic-style restricted grant.
Oracle removed NUP and Processor SKUs from its price list, so new Java subscriptions must use the employee-based metric. But organizations with existing legacy subscriptions were grandfathered and may renew under legacy terms, and older perpetual entitlements (Java SE Advanced or Java SE Suite) that some companies still retain do not vanish because Oracle prefers the new model. If you have them, they are leverage, and they belong in the proof file with original ordering documents and entitlement counts.
Two cautions must be documented alongside any legacy claim. First, Oracle's FAQ states legacy customers may renew "subject to confirmation that current usage is reflective of license counts in such existing order," which in practice means Oracle attaches a usage-validation requirement, effectively an audit trigger, to each legacy renewal. Second, that same FAQ is not contractually binding; the renewal right lives in your ordering document, not in a marketing PDF. So your proof file should reference the contract language that grants the right, not the FAQ. The reason this matters commercially is that Gartner reports most clients find the new subscription two to five times more expensive than the legacy model, so a defensible legacy position is often worth more than any single install-level saving.
The reason to build this file pre-emptively, not during an audit, is that Oracle often has far less evidence than it implies. Download logs are not deployment evidence: a download record shows a binary left Oracle's server, not that it is installed, running, or used for business operations. When Oracle leads with download data, your proof file lets you answer install by install: this build is NFTC-free, this build is 8u202 and free forever, this host is covered by WebLogic, this deployment sits under a legacy subscription. Each answered install is one Oracle cannot fold into the deployed population it uses to justify a headcount subscription.
Keep the proof file organized so that entries are self-contained and legally defensible. Where possible, hold the working analysis under privilege rather than in an open shared drive, following the approach in keeping Java audit records under privilege. And be deliberate about what leaves your organization: the proof file is your internal ammunition, not a data dump for Oracle, so pair it with a clear line on what to provide and what to refuse when Oracle sends a data request.
Download logs prove a binary left Oracle's server. They do not prove deployment. Your proof file is what turns their inference into your evidence.
Done properly, the proof file does not lower a per-install rate, because there is no per-install rate. It does something more valuable: it shrinks the population Oracle can credibly call deployed, and a smaller defended population is the direct lever on your employee count and your bill. Build it before the audit letter arrives, because reconstructing this evidence under a 30-day audit clock is exactly the scenario Oracle counts on.
Because the install list is what Oracle uses to argue your population is deployed, which is the word that justifies subscribing your whole headcount. Documenting free and already-licensed installs removes them from the deployed count Oracle anchors against. It does not change a per-install price, because there is not one; it protects the employee number that actually drives the bill.
Only if the specific build predates the version's NFTC cutoff. For Java 17, the last free build was 17.0.12.0.2 released in August 2024, and any 17.x build after that falls outside the no-fee grant. Your proof file must capture the exact build number and install date, not just "Java 17," or you cannot demonstrate the coverage.
By the exact build number. Oracle JRE 8u202 and earlier are free for commercial use under the old Binary Code License; 8u211 and later carry the OTN license, free only for personal and development use. Both report as version 1.8, so the build number is the entire case. For post-8u211 builds you must also document non-production usage.
No. Bundled Java rights are restricted-use: they cover Java only within the licensed product's boundary. Scripts, agents, monitoring tools, batch jobs, and standalone Java on the same host sit outside the grant and need their own entitlement. Your proof file must show both the bundled right (from an Oracle manual or Support note) and that Java use stays inside the product.
Oracle grandfathered existing legacy subscriptions and permits renewal under legacy terms, but its FAQ attaches a usage-validation condition, effectively an audit trigger, to each renewal. The renewal right lives in your ordering document, not the non-binding FAQ, so reference the contract. Since the new model is typically two to five times more expensive, a defensible legacy position is often worth protecting.
Usually less than it implies. Oracle's download logs show a binary left its server, not that it is installed, running, or used for business. That gap is precisely why a pre-built proof file matters: it lets you answer each install with its license basis and prevent Oracle from converting a download inference into a deployment claim.
Oracle Exadata can lock you into full core licensing across X9M, X10M, and Cloud at Customer. The buyer side strategy to size the platform and cut the bill.
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.
