Commercial software that ships or silently requires Oracle Java is the single most common source of accidental Java liability we see in audits. This guide shows you how to find it, who actually owns the license, and how to force the fix onto the vendor.
Commercial software that ships or silently requires Oracle Java is the single most common source of accidental Java liability we see in audits. This guide shows you how to find it, who actually owns the license, and how to force the fix onto the vendor.
When Oracle rewrote Java licensing on January 23, 2023 and moved to the Java SE Universal Subscription, it did more than triple many bills. It made a single chargeable Java install detonate across your entire workforce. The employee-based metric counts all full-time, part-time, and temporary employees, plus the employees of your agents, contractors, outsourcers, and consultants that support internal business operations. Server footprint is irrelevant. As one analysis put it bluntly, if even one employee has a commercial Oracle Java install on one machine, the company becomes liable to pay for all its employees.
That is the exposure math you must hold in your head for the rest of this article. A 5,000-employee firm running Oracle Java on 40 servers pays roughly $630,000 a year at list. Move that Java to 100 servers and the bill does not change. The price is your headcount, not your usage. So the risk in bundled software is not the app. It is the possibility that a third-party product quietly installed or pulled down a chargeable Oracle Java binary and lit the fuse on your whole employee count.
One chargeable Oracle Java install prices your entire workforce. The bundled runtime you never chose can cost the same as the ones you did.
The frustrating part is that you often did not choose this. A vendor shipped an installer that dropped Oracle JDK into a program directory, or the application checks for and downloads Oracle Java at runtime. You never touched java.com. Yet Oracle audits do include embedded Java. Oracle checks all Java usage, including runtimes bundled by vendors, and its download telemetry logs IP addresses, corporate domain associations, and automatic update check-ins from every copy not affirmatively disconnected. Bundled does not mean invisible. It means undocumented until Oracle documents it for you.
This is the question that decides whether you pay or the vendor does. The default answer from reading independent software vendor (ISV) agreements is simpler and harsher than most buyers expect. Two cases emerge. Where the ISV agreement specifically names Java and states the runtime is licensed and redistributed as part of the product, the license is the responsibility of the party that provided the software, meaning the vendor. Where the agreement makes no mention of Java, the license typically falls on the party that performed the download, meaning you.
That silence is where most of the money lives. Many ISVs never negotiated a redistribution right with Oracle, so their software either quietly downloads Oracle Java at install or expects you to supply it. In both scenarios the paperwork is silent, and Oracle will argue the liability is yours. To legitimately bundle and redistribute Oracle Java, a vendor must join the Oracle Partner Network and sign a special OEM or embedded (ESL) licensing agreement, with the Oracle cost embedded in the ISV's own pricing so the end customer never pays Oracle directly. If your vendor holds that agreement, you may already be covered. If it does not, you are exposed and probably do not know it.
Restricted-use and ISV embedded Java only help if they take your chargeable footprint to zero. This is the point buyers keep missing. A properly ESL-licensed embedded runtime is fine only if there is not a single other chargeable Oracle Java install anywhere else in the estate. If one general-purpose Oracle JDK is sitting on a developer laptop, the ESL cover on your CRM does nothing to stop the whole-workforce pricing. Treat embedded Java as a way to keep specific applications compliant, not as a shield for the enterprise. The enterprise shield is zero chargeable installs, full stop.
| ISV agreement wording | Who Oracle holds liable | Your position |
|---|---|---|
| Names Java, states runtime is licensed and redistributed | The vendor | Get written proof of the OEM/ESL agreement; keep it for audit |
| Silent on Java, product downloads Oracle JDK/JRE | You (the downloader) | High risk; demand indemnity or push to OpenJDK bundling |
| Requires you to supply your own Java | You | You must license or migrate; vendor bears none of it |
| ESL/embedded, Oracle cost inside vendor pricing | Vendor (via OEM deal) | Covered for that app only; still zero other installs |
You cannot decide who pays for something you cannot see. Bundled Java hides in program subdirectories, embedded runtimes named to look like anything but Java, and application launchers that pull Java at runtime. A standard software inventory will miss most of it. You need a filesystem-level scan for java executables and release files, tied back to the parent application, which is exactly the discipline we lay out in the Oracle Java inventory guide. Do this before any audit letter arrives, because in an audit the burden of proof falls on you.
For each Java instance you find, classify it three ways. First, is it Oracle-branded Java or an OpenJDK build such as Temurin, Corretto, Zulu, or Liberica? OpenJDK builds carry no Oracle subscription requirement. Second, if it is Oracle, is it under the No-Fee Terms and Conditions (NFTC) or a paid license? Third, is it bundled by a vendor or was it installed by your own team? SoftwareOne's field experience is honest about how this goes: in the best cases a bundled instance yields proof it is already licensed, in others the licensing information is enlightening but ambiguous, and sometimes the research is entirely inconclusive because the publisher never anticipated the question. Plan for the ambiguous and inconclusive cases, because they are the majority.
While you inventory, cut Oracle's evidence supply. Oracle's download and update-check telemetry drives a large share of claimed exposure. Blocking those check-ins does not erase past downloads, but it stops the estate from silently generating fresh evidence, and it stops unmanaged copies from pulling post-cliff updates. Work through the telemetry and update check-in guide as a parallel workstream, not an afterthought.
Even where a bundled runtime is currently free under the NFTC, it is on a timer. The NFTC covers Oracle JDK 17 and later, and permits free commercial and production use under its conditions, including redistribution provided you do not charge for it. That sounds safe until you read the schedule. The last NFTC version of Java 17 shipped in September 2024. Every Java 17 update from 17.0.13 onward now requires a paid subscription. JDK 21 follows the same pattern: Oracle will distribute the last free NFTC update to JDK 21 in July 2026 (with the OTN license applying to subsequent updates from September 2026).
This is where bundled software quietly bankrupts you. If a vendor's application ships Oracle JDK 17 and its own patch pipeline updates that runtime past 17.0.13, that update crosses the cliff and becomes chargeable. The estate buys subscriptions one automated update at a time, and nobody signed off on any of it. This risk is not theoretical, it is scheduled, and it is why version pinning and vendor control matter more than they used to.
The NFTC cliff turns a passive estate into a converting one. Post-cliff updates arrive through patch pipelines you do not watch, and each one is a subscription trigger.
The clean exit for bundled Java is not for you to buy an Oracle subscription. It is for the vendor to ship an OpenJDK build instead. The four leading distributions, Eclipse Temurin, Amazon Corretto, Azul Zulu, and BellSoft Liberica, are all free for production commercial use, all TCK-verified, and all built from the same OpenJDK source. None requires an Oracle Java SE subscription. There is rarely a technical reason a well-built application cannot run on a certified OpenJDK build of the same major version, and our published comparison of OpenJDK alternatives sets out the support and migration trade-offs.
Your leverage with the vendor is strongest at three moments: renewal, a support ticket about the runtime, and any new purchase. Use them. The ask is specific: certify your product on a named OpenJDK build, ship that build in the installer, and confirm in writing that no Oracle Java download or check-in occurs. If the vendor resists, escalate the commercial point. Their choice to embed unlicensed Oracle Java is transferring a per-employee liability onto you, and you will price that liability into any renewal or reject the product. In 25 years negotiating these deals, the vendors who bundle Oracle Java without an OEM agreement fold quickly once the buyer quantifies the exposure and puts indemnity language on the table.
Where the vendor will not or cannot move fast enough, you migrate the runtime yourself by replacing the bundled Oracle JDK with a certified OpenJDK build of the same major version, then validating the application. That is a controlled engineering task, and it must be tested rather than assumed. Run each affected application through the discipline in the application compatibility testing guide before you touch production, and sequence the work using the estate phasing approach so you are not gambling the whole estate on one weekend. The full end-to-end method lives in the OpenJDK execution guide.
The enforcement environment is not soft anymore. In 2026 the soft outreach has given way to formal audit notices issued through Oracle's Global Licensing and Advisory Services (GLAS), formerly LMS, and the letters are arriving. Reporting indicated that nearly three out of four Oracle Java users say they have been audited in the past three years, with some businesses reporting four Oracle Java audits a year. Across roughly 35 to 45 Java audits defended in 2024 to 2025, three patterns recurred: Oracle's first finding priced 100% of employees even where Java ran on 10% to 20% of machines, download evidence from java.com accounts drove 30% to 50% of claimed exposure, and settlements landed 40% to 70% below the opening figure once migration to OpenJDK was shown as credible.
Read that last point again, because it is the buyer's whole strategy in one sentence. Credible migration is the discount. Oracle's average initial compliance claim runs three to ten times what organizations actually owe, and organizations that respond without preparation typically pay 40% to 60% more than those with expert guidance. The bundled-Java case is defensible precisely because you can often show the runtime was placed by a third party, was under NFTC, or has since been replaced. But you can only show that if you inventoried first and documented the removal.
Be realistic about the terms Oracle will and will not concede. In one defended case, a firm argued only 800 of its 10,000 employees actually used Java. Oracle held the line: any use found means all employees must be licensed. After hard negotiation the firm settled on a discounted multi-year subscription covering all 10,000, with most back fees waived but a penalty still paid. The lesson is not that usage arguments are worthless, it is that the winning move is to remove the chargeable footprint entirely so there is no use to price, then negotiate from there.
If you are weighing whether to remediate at all or simply pay, run the numbers with clear eyes using the migration economics work and the broader Oracle Java SE exit map. In our experience the bundled-Java case almost always favors migration, because the alternative is paying a per-employee subscription for a runtime you never chose to install.
Usually yes, unless the vendor holds an Oracle OEM or embedded (ESL) redistribution agreement that specifically covers you. If the ISV contract is silent on Java, Oracle treats the party that downloaded the runtime as liable, which is normally you. Get written proof of the vendor's redistribution right, and if none exists, treat the install as chargeable.
Under the Java SE Universal Subscription, yes. The metric counts all employees plus contractors, agents, and consultants regardless of how many machines run Java. A single chargeable install anywhere in the estate can trigger whole-workforce pricing, which is why the only reliable shield is zero chargeable Oracle Java installs.
Yes, and it is the cleanest fix. Ask the vendor to certify and ship a TCK-verified OpenJDK build such as Temurin, Corretto, Zulu, or Liberica, and to confirm in writing that no Oracle download or check-in occurs. Use renewals and new purchases as leverage, and price the liability into the deal if the vendor refuses.
Only until the cliff. NFTC covers JDK 17 and later, but Java 17 became chargeable from update 17.0.13 in October 2024, and JDK 21 loses free NFTC updates after July 2026. If the vendor's patch pipeline pushes updates past those points, the runtime becomes chargeable, so pin the version or migrate to OpenJDK.
Yes. Oracle checks all Java usage including runtimes bundled by vendors, and its telemetry logs download IPs, corporate domains, and automatic update check-ins. Bundled does not mean invisible. Inventory the estate and block check-ins before an audit so you control the evidence rather than Oracle.
In defended audits from 2024 to 2025, settlements landed 40% to 70% below Oracle's opening figure once a credible OpenJDK migration was shown. Oracle's initial claims commonly run three to ten times what buyers actually owe, so demonstrated removal of the chargeable footprint is the single strongest lever you have.
When third party support is the right call for Oracle Database, Apps, and Middleware. Rimini Street, Spinnaker, the savings math, and the leverage even non sw
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.
