A commercial application arrived with an Oracle JDK inside it, you cannot remove that runtime without losing vendor support, and Oracle prices the install against your whole headcount. The fix is contractual, not technical.
A commercial application arrived with an Oracle JDK inside it, you cannot remove that runtime without losing vendor support, and Oracle prices the install against your whole headcount. The fix is contractual, not technical. Who is licensed, what to put in the vendor contract, and what to do while you wait.
The vendor is, and you are covered only through the vendor's agreement, if one exists. Nothing about the binary landing on your server creates a license in your name.
Oracle sets this out in its own JDK License General FAQs. Your application vendor may hold an agreement that lets it supply Java to run its product. Oracle then instructs you to contact the vendor to find out.
Read that instruction as what it is. Oracle has told the customer to go and establish a fact that only two other parties can see, and has reserved the right to price the answer if the customer cannot produce it.
Only the first pattern is a genuine ISV question. The other three are a discovery and attribution problem, and they account for most of the volume in a first pass scan.
Because it describes delivery, not entitlement. Oracle does not audit your vendor on your behalf, and the vendor's agreement with Oracle is confidential, so the sentence cannot be tested by anyone in your building.
The vendor shipped the runtime. Oracle bills you for it. Nothing in a product datasheet transfers a license.
Your use of that vendor's application, on the terms the vendor's own Oracle agreement carries, and nothing beyond it. The scope is the product, not the server and not the JVM.
This is the same shape as the restricted use rights inside Oracle's own stack. If you license certain Oracle middleware or database products you may already run the bundled runtime to operate those products, and only those products.
Ask one question of every bundled runtime on the estate. If the vendor's application were uninstalled tomorrow, would this process still need the JVM?
If the answer is yes, that process is general purpose use and the pass through does not reach it. These are the uses that fail the test in practice:
What a vendor bundled runtime covers, and what it does not
| Use of the vendor's JVM | Covered by the vendor's license? | What actually decides it |
|---|---|---|
| Running the vendor's application as delivered | Possibly | Whether the vendor holds redistribution rights covering your version |
| A custom extension or plugin inside the vendor's product | Usually, with care | Whether the vendor's terms treat extensions as part of the product |
| Your own batch job using the same java binary | No | General purpose use falls outside any embedded scope |
| A second application pointed at the same runtime | No | Scope follows the product, not the installation directory |
| The runtime copied to another host as a base image | No | You became the redistributor at that point |
| Development and test copies of the vendor's product | Check the wording | Non production entitlement is separately worded in most ISV contracts |
The copied base image line is the one buyers under estimate. Lifting a vendor's runtime into your own golden image turns a consumption question into a redistribution question, which is the subject of our Oracle Java embedded and OEM licensing guide.
You stop asking to see the agreement. You ask the vendor for a written statement about your specific deployment, which it can give without disclosing a single confidential term.
Vendors refuse the first request because it is genuinely impossible to grant. They often grant the second one, because a statement about what they ship you is a product fact, not a contract disclosure.
Send it to the contract owner and to the vendor's legal or license compliance function, in the same message, quoting the support agreement number. A request that goes only to a technical account manager tends to die there.
Not all written answers are worth the same in a dispute. Grade every response the day it arrives, because the grade decides whether the install is closed or still open.
Evidence grades for a vendor Java statement
| Grade | What you were given | What it is worth |
|---|---|---|
| A | A clause in the order form, license agreement or a signed amendment | Closes the install and survives a change of account team |
| B | A letter from the vendor's legal or compliance function naming your version | Strong. Ask for it to be referenced at the next renewal |
| C | An email from the account manager confirming the distribution and license | Useful, and worth converting to grade B before you need it |
| D | A public support article or release note listing the bundled runtime | Evidence of fact, not of rights. Keeps the version question honest |
| E | A verbal assurance, a datasheet line, or "Java is included" | Nothing. Log the install as unresolved |
Give the vendor 15 business days and one escalation. If nothing arrives, record the runtime as unresolved and treat it as uncovered until proven otherwise.
Keep the sent message, the escalation and the dates. A dated request that the vendor ignored is a materially better position than an estate where nobody ever asked.
Under the Java SE Universal Subscription the unit of pricing is your employee count, not the install. That is why a single unattributed JVM is not a small problem.
Oracle's Java SE Universal Subscription counts full time, part time and temporary employees, plus the equivalent staff of agents, contractors, outsourcers and consultants who support your internal business operations. Current rates and tiers sit on our 2026 Java licensing cost page.
Proving coverage costs one email. Failing to prove it is priced at your entire headcount, every year, for a runtime you never chose.
That asymmetry is the whole argument for doing the contractual work early. The vendor conversation is cheap while it is voluntary and expensive once Oracle has a number on a slide.
Five clauses, and the only moment a vendor will reliably sign them is its own renewal or your next expansion order. Mid term, the vendor has no reason to reopen paper.
None of these clauses ask the vendor to disclose its Oracle agreement. They ask the vendor to stand behind what it ships, which is a normal supply obligation in every other part of the contract.
The five clauses that close a bundled Java exposure
| Clause | What it obliges the vendor to do | What it prevents |
|---|---|---|
| Runtime disclosure | Name the distribution, vendor, version and license for every runtime shipped, and refresh it each release | Discovering the answer during an audit instead of at purchase |
| Redistribution warranty | Warrant it holds the rights to supply that runtime to you for use with the product | The confidential agreement problem. You now rely on a warranty, not a rumour |
| Named indemnity | Indemnify third party license claims arising from the bundled runtime, Oracle named expressly | A generic IP indemnity that excludes exactly the claim you will receive |
| Change notice | Give 60 to 90 days written notice before the shipped runtime changes distribution or license family | A silent move from a free build to a commercial one inside a patch |
| OpenJDK support right | Support the product on at least one named OpenJDK build for the contract term | Being locked to Oracle JDK by a support matrix rather than by technology |
Many vendors will not warrant redistribution rights, and some genuinely cannot. Refusal is not the end of the negotiation, it is information about where the cost belongs.
That last one is worth saying plainly. A vendor telling you in writing that Java is your problem is a better outcome than a vendor telling you nothing, because it makes the cost visible and negotiable.
Your license position can change without anyone making a decision, because Oracle's free use terms are scoped to specific versions and dates. A routine vendor patch can move you across that line.
Oracle Java 17 is the clearest example. The last update covered by the Oracle No Fee Terms and Conditions was 17.0.12 in August 2024, and 17.0.13 in October 2024 moved to the commercial terms.
Oracle's Java SE support roadmap sets the same kind of boundary for later releases, with JDK 21 and JDK 25 each carrying a stated free use window before the terms change. Track those dates against every bundled runtime you own.
Because scanners match on paths, file names and version strings, not on license status. Every copy looks the same to a tool, whether it is licensed, bundled, dead or not Oracle at all.
Treat the first number as an upper bound on the argument, not as a finding. The gap between the headline count and the licensable count is where the work is.
One Redress review of a mid size estate opened at 87 Oracle Java installations across 54 servers. After attribution, 23 were misidentified OpenJDK builds, 18 were covered by existing Oracle product licenses, 31 sat on decommissioned workloads, and 15 needed action.
An 87 install finding collapsed to 15 real problems. The other 72 were noise that Oracle would have priced at full rate.
Contain, do not migrate. The vendor answer decides whether the runtime is a licensing problem at all, and most of the value comes from work you can do without touching the vendor's product.
The containment sequence below takes about 30 days on a typical estate and is entirely reversible. None of it requires vendor approval, because none of it changes the vendor's application.
The standard advice is to rip out the vendor's Oracle runtime and drop an OpenJDK build in its place. We disagree, at least as a first move. On a third party application you do not control the runtime, and the substitution usually costs you the vendor's support position.
The certification matrix, not the JVM, is what actually binds you. Replacing a runtime the vendor certified also does nothing about the period already elapsed, which is precisely the part Oracle prices.
The contractual route fixes both ends. A written coverage statement closes the history, and a vendor certified OpenJDK build closes the future.
Technical substitution is the right first move on runtimes you own. On somebody else's product it is the second move, and it follows the letter rather than replacing it.
Better than most buyers expect, provided the register exists before the question arrives. Attribution plus vendor letters converts an install count into a much smaller licensable number.
In one documented engagement Oracle opened at roughly 700,000 dollars for Java at a mortgage services company. Separating Oracle JDK from vendor supplied runtimes inside third party applications, and testing every assumption behind the count, ended with the claim withdrawn.
The pattern generalizes. Oracle's opening position prices the whole employee population even where Java runs on a fraction of the estate, so every install you can attribute or retire is a line that cannot be priced.
The same reclassification work drives the Illinois manufacturer's 5.346 million dollar exposure, and it sets up a clean departure, which we map in the Oracle Java SE exit guide.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
If the residual is large enough to matter, the next decision is whether to stay on Oracle Java at all, which is the subject of our 2026 Java to OpenJDK migration decision guide.
No. The vendor must hold an Oracle redistribution agreement that extends to you and to the exact version you run. Oracle's own JDK FAQ tells you to contact the vendor to confirm it, which means the burden of proof sits with you rather than with the vendor.
No. Embedded coverage, where it exists, is scoped to the vendor's application. The moment that JVM serves a batch job, an internal jar file or a second application, the use falls outside the vendor's license and is unlicensed on your account.
A written statement naming the distribution, the exact version string, the license it ships under, and whether you need your own Oracle subscription. Ask the contract owner and the legal or compliance function together, and give a deadline. You are not asking to see the vendor's Oracle agreement, which no vendor can share.
Record the runtime as unresolved and treat it as uncovered until proven otherwise. Keep the dated request and the escalation, contain the general purpose uses, and put the question on the vendor's renewal agenda where you have actual leverage.
Not as a first move on somebody else's product. Substituting a runtime the vendor certified usually costs you the support position, and it does nothing about the period already elapsed. Get the written answer first, then ask for a certified OpenJDK build in the contract.
Yes, and it is the most common way a covered install becomes an exposed one. Oracle's free use terms are version and date scoped, so a routine product patch that moves the embedded JDK past a boundary changes the terms with no invoice, no alert and no human decision.
No, that is the opposite problem. Packaging a Java runtime into software you distribute makes you the redistributor and puts you inside Oracle's OEM and ISV terms, which we cover in the embedded and OEM licensing guide.
Everything CIOs need to govern Oracle Java in 2026. Universal Subscription mechanics, the OpenJDK exit path, audit defense, and the 3 year plan that contains
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.
