Embedded Oracle JDK in third party applications. Who is licensed, and when migration makes sense.

A bundled Oracle JDK covers you only if the vendor holds redistribution rights for your version. Get that in writing, fix it in the renewal contract, and contain the runtime before you consider migrating it.

A commercial application arrives with an Oracle JDK inside its installer. You cannot swap that runtime out without putting the vendor's support at risk, and Oracle prices any uncovered Oracle Java against your whole employee count. The fix for that exposure sits in the vendor's contract, and this guide shows how to get it there.

If you are planning an embedded JDK migration, the order of work matters. Get the vendor's answer in writing, contain the runtime on your own side, and then move to an OpenJDK build the vendor certifies, on the vendor's release schedule.

Who is licensed when a vendor ships Oracle Java inside its product?

The vendor is, and you are covered only through the vendor's own agreement with Oracle, if one exists. A binary landing on your server does not create a license in your name.

Oracle says as much in its JDK License General FAQs. Your application vendor may hold an ISV agreement that allows it to supply Java to run its product, in which case you need no separate Oracle license for Java running that application. Oracle then tells you to contact the vendor to find out.

Look at where that leaves the burden of proof. Oracle has asked you to establish a fact that only two other parties can see, and it keeps the right to price the answer if you cannot produce it.

The four ways an Oracle runtime ends up inside someone else's software

• Redistributed. The vendor ships an Oracle JDK inside its installer or container image. This is the only pattern where a pass through right can exist at all.
• Required. The installer tells you to download Oracle JDK yourself. You accepted Oracle's terms directly, so this was always your own license question.
• Inherited. An older release bundled a legacy Oracle JRE under the retired Binary Code License, and the position was never looked at again when the product was upgraded.
• Mislabeled. The vendor ships an OpenJDK build such as Temurin or Corretto, the scanner reports it as "Java", and an install with no Oracle exposure enters the audit count.

Only the first pattern is a true ISV question. The other three are discovery and attribution problems, and they account for most of the volume in a first pass scan.

Why "it came with the product" settles nothing

The phrase describes how the software was delivered. It says nothing about who holds the right to run the Java inside it.

Oracle does not audit your vendor on your behalf, and the vendor's Oracle agreement is confidential, so the claim cannot be tested by anyone in your building. A product datasheet transfers no license. The vendor shipped the runtime, and without paper to show otherwise, Oracle will bill you for it.

What have we seen in bundled Oracle Java reviews in 2024 and 2025?

Across roughly 40 to 60 Oracle Java reviews I led in 2024 and 2025, the runtime shipped by another vendor was consistently the slowest line to close. Four patterns came up again and again:

• Few written answers. Roughly half of vendors answered the licensing question in writing at all, and the first reply almost always came from a support engineer with no authority to bind the company.
• Rights tied to old releases. Where the vendor did hold redistribution rights, those rights were scoped to named releases, and the customer had already upgraded past them.
• The side use caused the dispute. The contested install was rarely the vendor's own process. It was a second, internal use of the vendor's JVM by a script someone wrote in 2019.
• Timing decided the value of the letter. A vendor letter obtained before Oracle made contact changed the conversation. The identical letter obtained after it did not.

That last pattern sets the timing for everything below. Each step costs less, and counts for more, if it is done before Oracle's first email arrives.

What does a vendor's bundled Java license actually cover?

It covers your use of that vendor's application, on the terms the vendor's Oracle agreement carries, and nothing beyond it. The scope follows the product. The server and the JVM sit outside it.

Oracle's own stack works the same way. If you license certain Oracle middleware or database products, you may already hold restricted use rights to run the bundled Java for those products, and only those products.

The general purpose test

Ask one question of every bundled runtime you find. If the vendor's application were uninstalled tomorrow, would this process still need that JVM?

If the answer is yes, the process is general purpose use, and the vendor's rights do not reach it. These are the uses that fail the test most often:

• A scheduled job that calls the java executable in the vendor's product directory because it was the one on the box.
• A global JAVA_HOME or PATH entry pointing at the vendor's runtime, so every other process on the host inherits it by default.
• A monitoring agent, a build agent or an internal jar file running on the same JVM because no one wanted a second install.
• A developer laptop with an IDE configured against the runtime that arrived with a licensed desktop application.
• A second commercial application pointed at the first vendor's JVM during an upgrade, often without a change record.

The base image row is the one buyers underestimate. Lifting a vendor's runtime into your own golden image turns a question about use into a question about redistribution, which our Oracle Java embedded and OEM licensing guide covers. Container teams should also read our note on Oracle Java in Docker base images.

Why does the scan report more Oracle Java than you actually have?

Scanners match on paths, file names and version strings. License status is invisible to them, so every copy looks alike whether it is licensed, bundled, dead or not Oracle at all.

Treat the first number as an upper bound on the argument. The real work lies in the gap between the headline count and the count that could ever need a license. These are the usual sources of inflation:

• OpenJDK builds reported as Oracle Java because the directory name or vendor string looks close enough.
• Runtimes inside Oracle's own products that are already covered by restricted use rights attached to the product license.
• Copies on decommissioned hosts, in backup directories and inside archived virtual machine images.
• Several JVMs inside a single vendor product counted as several installs, because a large application often ships more than one.
• Container images counted per layer or per running instance instead of per distinct build.

One Redress review of a mid size environment opened at 87 Oracle Java installations across 54 servers. Attribution sorted them into four groups, and only one group needed action.

Had the 72 closed installs stayed in the count, Oracle would have priced them at full rate alongside the real problems. Our guide to scoping errors that inflate exposure lists the other common causes.

How do you tell an embedded Oracle JDK from an OpenJDK build?

Run the runtime's own java executable with the version flag and read the second line of output. Oracle JDK reports "Java(TM) SE Runtime Environment", while OpenJDK builds report "OpenJDK Runtime Environment", usually followed by the distribution name.

Always call the executable by its full path inside the vendor's product directory. Calling plain java tests whatever runtime the PATH points at, which may be a different install entirely.

Other evidence worth collecting

• The release file. A plain text file at the root of most runtime directories lists JAVA_VERSION and IMPLEMENTOR. Oracle's own OpenJDK builds also name Oracle Corporation, so the vendor field alone does not settle the question.
• System properties. Running the executable with -XshowSettings:properties and -version prints java.vendor, java.vm.name and java.home, which confirms the directory a process loads from.
• Running processes. On Linux, the process list and the exe link under /proc for each Java process show which runtime every workload uses. On Windows, the command line column in Task Manager or Process Explorer does the same.
• The vendor's support matrix. Most vendors publish which Java distributions and versions they certify per release. It helps you date when a shipped runtime changed.

The process check matters most, because it is how you find the general purpose uses described above. Our guide to distinguishing Oracle JDK from OpenJDK covers older releases and edge cases.

How do you get proof from a vendor that will not show you its Oracle agreement?

Stop asking to see the agreement. 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 they cannot grant it. They often grant the second, because a statement about what they ship you is a product fact rather than a contract disclosure.

The five questions the written answer has to cover

1. The distribution and the version. Oracle JDK, Eclipse Temurin, Azul Zulu, Amazon Corretto or another build, with the exact string java -version reports for the release you run.
2. The license it ships under. An Oracle ISV or OEM redistribution agreement, the Oracle No Fee Terms and Conditions, the Oracle Technology Network license, or GPLv2 with the Classpath Exception.
3. Whether you need your own Oracle subscription. A plain yes or no, for this product, at this version, in this environment.
4. What changes on upgrade. Whether the answer holds for the next release, and what the vendor will do if Oracle's terms change under it.
5. Whether an OpenJDK substitution keeps support. Which builds are certified, and whether the vendor will support the product on one of them.

Send the request to the contract owner and to the vendor's legal or license compliance function in the same message, quoting your support agreement number. A request that goes only to a technical account manager tends to stall there.

Grading the answer you get back

Written answers are not equal in a dispute. Grade each response the day it arrives, because the grade decides whether the install is closed or still open.

If the vendor stays silent, write that down

Give the vendor 15 business days and one escalation. If nothing arrives, record the runtime as unresolved and treat it as uncovered until the vendor proves otherwise.

Keep the sent message, the escalation and the dates. A dated request the vendor ignored puts you in a far better position than a file showing the question was never asked.

What the vendor will tell you, and what to say back

• "Java is included." Ask which distribution, which version and which license. The word included describes delivery, and the licensing answer needs all three names.
• "We cannot share our Oracle contract." Agree, and say you are not asking for it. You want a statement about the runtime shipped to you.
• "Customers are responsible for third party components." Ask for that in writing too, against your version. It then becomes a cost of the product and goes into the renewal price discussion.
• "Any Java 8 or later will work." Ask for that in the published support matrix, naming an OpenJDK build, so a support engineer cannot later refuse a ticket because you left Oracle JDK.
• "Oracle has never raised this with our other customers." Repeat the request. Oracle audits you, and another customer's experience grants you nothing.

What does one uncovered bundled runtime cost?

It costs a Java SE Universal Subscription for the whole organization. The subscription is priced on employee count, so a single unattributed JVM opens a claim on everyone you employ, however little the runtime does.

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. Oracle says pricing starts at $15 per employee per month, with published tiers as low as $5.25. Current rates sit on our 2026 Java licensing cost page.

A worked example: one runtime, one application, 950 people

Say you employ 800 staff and use 150 contractors who support internal operations. One Oracle JDK sits inside a scheduling application that 40 people use, and the vendor cannot show redistribution rights for your version.

The 40 users of the application play no part in the calculation. The price follows headcount, and headcount rises and falls with hiring, whatever the Java footprint. In a larger organization the rate per employee falls, but the total climbs with the count; our tier pricing worked example walks through the bands.

Proving coverage costs one email. Failing to prove it is priced at your entire headcount, every year, for a runtime you never chose.

That imbalance is the case for doing the contract work early. The vendor conversation is cheap while it is voluntary and expensive once Oracle has a number on a slide. Who belongs in the count is its own argument, covered in our note on contractors and consultants in the employee count.

What should you write into the ISV contract?

Five clauses, and the only time a vendor reliably signs them is at its own renewal or your next expansion order. Mid term, the vendor has no reason to reopen paper.

None of the five asks the vendor to disclose its Oracle agreement. They ask it to stand behind what it ships, which is a normal supply obligation everywhere else in the contract.

Wording to put in front of the vendor's lawyers

• Disclosure. "For each release delivered, Supplier shall list every Java runtime included in the Software by distributor, version and license, and shall update the list with each release." Tying the list to releases puts version drift on paper.
• Warranty. "Supplier warrants that it holds all rights needed to distribute each included Java runtime to Customer for use with the Software." This replaces the question you cannot verify with a promise you can enforce.
• Indemnity. "Supplier's indemnity covers claims by Oracle or any other licensor arising from any runtime included in the Software, notwithstanding any exclusion for third party components." Standard IP indemnities often carve those components out.
• Change notice. "Supplier shall give Customer at least 90 days written notice before changing the distribution or license family of any included runtime." Ask for 90 and accept no fewer than 60.
• OpenJDK support. "Supplier shall support the Software on [named OpenJDK distribution and version] for the term." Naming the build stops a later argument over what counts as certified.

What to accept when the vendor refuses the warranty

Many vendors will not warrant redistribution rights, and some cannot. A refusal tells you where the cost belongs, and the negotiation continues from there.

• Disclosure only, with a price adjustment. If the vendor will not stand behind the runtime, licensing it is a cost of the vendor's product and belongs in the price discussion.
• A pinned version with a support commitment. Useful where the current build sits on the free side of a license boundary and you want it to stay there.
• A certified OpenJDK path with a date. The strongest fallback, because it removes the dependency instead of insuring it.
• A written statement that you must license Java yourself. Unwelcome, but valuable, because it turns an unknown into a number you can put on the renewal.

A vendor that tells you in writing that Java is your responsibility has left you better placed than one that says nothing. The cost is now visible, and you can price it into the renewal.

When to raise the Java question with each vendor

What happens when the vendor patches the embedded runtime?

Your license position can change without anyone deciding anything, because Oracle's free use terms are tied to specific versions and dates. A routine vendor patch can carry you across the line.

Oracle Java 17 is the clearest example. The last update under the Oracle No Fee Terms and Conditions was 17.0.12, released in July 2024. From 17.0.13 in October 2024, updates moved to the Java SE OTN license, which does not cover general production use without a paid subscription.

Oracle's Java SE support roadmap sets the same kind of boundary for JDK 21 and JDK 25, and JDK 21 is the one to watch now. A vendor that patches Oracle JDK 21 on its normal cycle will bring the October 2026 update, and its new terms, onto your servers. Ask each one what it plans before that patch arrives.

The controls that stop version drift

1. Record the version at every patch window. The version string, the date, the product and the host, held in the same register as the vendor answer.
2. Establish who controls the runtime. Some products update the JVM as part of the product patch, some leave it to the host team, and the difference decides who can pin it.
3. Pin where the vendor's rights are version scoped. If the letter names 17.0.12, then 17.0.12 is what you run until the letter is reissued.
4. Put the change notice clause to work. A vendor obliged to warn you before the runtime changes has to think about the license before it ships the patch.

What should you do while you wait for the vendor to answer?

Contain the exposure and leave migration for later. The vendor's answer decides whether the runtime is a licensing problem at all, and most of the value comes from work that never touches the vendor's product.

The sequence below takes about 30 days in a typical environment and can be reversed at any point. None of it needs vendor approval, because none of it changes the vendor's application.

1. Attribute every runtime to exactly one parent product. An install with no named parent is the most expensive row in the inventory, so resolve those first.
2. Break the general purpose uses. Unset global JAVA_HOME, remove the vendor runtime from the system PATH, and repoint internal scripts at a runtime you control.
3. Freeze the version on anything a vendor letter names. Then confirm the freeze survives the next product patch cycle.
4. Delete dead copies. Decommissioned hosts, stale images and old installer caches cost nothing to remove and drop out of the count.
5. Stand up a runtime you own. Give internal workloads an OpenJDK build so borrowing the vendor's JVM stops being the easy option. Our Corretto, Temurin and Zulu comparison covers the choice of distribution.
6. Keep a dated register. Product, host, version, vendor answer, evidence grade and date. This register is the record that decides the argument later.

Why we would not start by swapping in OpenJDK

The usual advice is to rip out the vendor's Oracle runtime and drop an OpenJDK build in its place. On a third party application we think that is the wrong first step. You do not control that runtime, and an uncertified substitution usually costs you the vendor's support.

The certification matrix is what binds you, more than the JVM itself. Replacing the runtime also does nothing about the period already elapsed, which is the part Oracle prices. The contract route covers both: a written coverage statement closes the history, and a vendor certified OpenJDK build closes the future.

On runtimes you own, technical substitution should come first. On another company's product it comes second, and it follows the vendor's letter.

How does this position hold up when Oracle asks?

Better than most buyers expect, provided the register exists before the question arrives. Oracle's opening position prices the whole employee population even where Java runs on a fraction of the servers. Attribution and vendor letters shrink that to the installs that could ever need a license, and every install you attribute or retire is one Oracle cannot price.

In one engagement, Oracle opened at roughly 700,000 dollars for Java at a mortgage services company. Separating Oracle JDK from the runtimes vendors had supplied inside third party applications, and testing every assumption behind the count, ended with the claim withdrawn.

What Oracle's Java team will say, and how to answer

• "We see Oracle JDK on these hosts." Ask for the hosts and version strings behind the statement, then answer host by host from the register: parent product, vendor answer, evidence grade.
• "Your vendor's agreement does not extend to you." Ask Oracle to put that in writing for the named product and version. Then take it to the vendor, whose warranty or indemnity now applies.
• "The subscription counts employees, so the number of installs is irrelevant." The installs decide whether you need the subscription at all. Every install attributed to a covered product or removed takes away a basis for the claim.
• "You owe fees for the years you used it." Ask which installs and dates the claim rests on. Attributed and decommissioned installs drop out of the back period too, and our note on pushing back on back fee demands covers the rest.

The same reclassification work drove the result behind the Illinois manufacturer's 5.346 million dollar exposure. It also sets up a clean departure from Oracle Java, which we map in the Oracle Java SE exit guide.

What to do next

1. List every Java runtime with a named parent product. Anything without a parent goes to the top of the queue, because that is what Oracle prices first.
2. Send the five question request to every vendor that ships one. Contract owner and legal together, quoting the support agreement number, with a firm reply date.
3. Grade each reply the day it lands. Grade A or B closes the install, grade C gets converted at the next renewal, and grade D or E leaves the install open.
4. Break every general purpose use of a vendor runtime this month. Global JAVA_HOME, shared PATH entries, internal scripts and IDE configurations.
5. Pin versions where a vendor answer names one. Check the pin holds through the next product patch, and ask each vendor shipping JDK 21 about the October 2026 update now.
6. Put the five clauses on the next renewal agenda for each vendor. Disclosure, warranty, named indemnity, change notice and an OpenJDK support right.
7. Model the residual. Compare what remains against our three migration patterns cost model and the 9 to 14 month migration timeline, then set a decision date. If the residual is large, weigh staying on Oracle Java at all with our 2026 Java to OpenJDK migration decision guide.
8. Review the whole register every quarter. Vendors change what they ship, and an answer that was true in March may not hold in October.

Frequently asked questions