Oracle Java embedded and OEM licensing. A right to ship.

An embedded Java license is a redistribution right. It lets a named party ship a named Oracle runtime inside a named product, to a defined audience, counted on an agreed metric. Everything else about embedded Java follows from those four boundaries.

This guide covers what such a license permits, how an ISV or OEM actually obtains one, how to tell which license instrument you are standing on, and how the royalty and audit mechanics behave when Oracle checks.

What does an embedded Java license actually permit?

It permits one party to redistribute a specified Oracle runtime inside a specified product, to a specified audience, counted on a specified metric. Those four boundaries are the whole instrument.

Everything buyers argue about later, coverage, audits, royalties and exit, is an argument about where one of those four lines sits. Read the order form for the lines before you read it for the price.

The four boundaries every embedded agreement draws

What an embedded license never permits

• General purpose use by the end customer. The runtime may run the vendor's product. It may not run the customer's own code, scripts or second applications.
• Standalone distribution of the runtime. The Java binary cannot be handed over on its own, published in a repository, or shipped as a base image component.
• Sublicensing to another vendor. A partner who resells your product does not automatically inherit your redistribution right.
• Support substitution. An embedded right is not a support contract, and it does not entitle the end customer to raise a case with Oracle.
• Silent scope growth. New products, new territories and new deployment models require an amendment, not a footnote in a release note.

With embedded Java the question is never whether the runtime is free. It is whether you are allowed to ship it, and to whom.

How does an ISV actually obtain one?

Through a negotiated agreement with Oracle, not by accepting a download license. No click through license on oracle.com grants redistribution rights inside a commercial product.

That distinction is where most ISV exposure begins. Engineering accepted a download license in good faith, product management shipped, and nobody in the company ever signed a redistribution right.

The route, step by step

1. Describe the product and the shipment path. What the product is, how the runtime is packaged, and whether customers install it, receive it on a device, or consume it as a service.
2. Forecast the volume on the metric Oracle proposes. Devices, end customer installations, processors or employees at the end customer, depending on the shape of the business.
3. Negotiate scope before rate. Product family, version window, territory and hosted use are worth more over a term than a lower unit number.
4. Sign the order form with the redistribution language in it. Redistribution rights live in the order form or an addendum, not in the master agreement's general terms.
5. Report on the agreed cadence. Most embedded agreements carry a periodic declaration obligation, and the declaration is the audit trail.
6. Reset at renewal. Volumes, versions and product scope all drift, and renewal is the only cheap moment to correct them.

What it costs to answer the volume question badly

Understating the forecast to secure a lower entry price is the single most expensive habit in embedded contracting. Oracle reprices on the corrected figure, and the correction usually arrives during an audit rather than a renewal.

Overstating is not free either. A committed minimum on devices you never ship becomes a fixed cost with an escalator attached to it.

Why fewer ISVs hold one in 2026

• OpenJDK builds carry no Oracle royalty, and the redistribution terms under GPLv2 with the Classpath Exception are permissive by comparison.
• The commercial terms for Oracle JDK moved several times since 2019, which made a fixed multi year product roadmap harder to underwrite.
• End customers began asking the question, and an ISV that cannot answer it in writing loses deals to one that can.
• Device economics stopped supporting a per unit royalty on hardware with thin margins.

How is the OEM device model different?

The counting unit moves from installations to manufactured or sold devices, and the obligations move into the firmware. An OEM owns the security update path for a runtime it cannot easily reach once the device ships.

OEM contract anatomy

• Per device royalty. Paid on devices manufactured or devices sold, and the difference between those two words matters on any product with returns.
• Volume commitment. A minimum annual device count with step down banding above defined thresholds.
• Platform scope. Architecture specific entitlement across ARM, x86 and other targets.
• Support obligation. Device level support that includes the runtime, since the end user has no path to Oracle.
• Security update obligation. Firmware level delivery of Java security updates for the supported life of the device.
• Territory. Distribution geography, frequently global, and worth confirming for regulated markets.

Where embedded Java still ships on devices

• Point of sale terminals. Retail hardware running a Java application layer, with mixed Oracle JDK and OpenJDK adoption.
• Banking self service hardware. Cash machines historically ran Java SE Embedded, and many have moved to OpenJDK builds.
• Industrial controllers. Some programmable controllers shipped Java ME Embedded, though most have moved to native code.
• Set top boxes and media gateways. A large historical estate, now mostly migrated to Linux native stacks.
• Smart cards and secure elements. Java Card remains a distinct commercial agreement with its own per unit model.

How do you tell which license you are actually standing on?

You cannot tell from the binary. Six different license instruments produce a runtime that looks identical on disk, and only paperwork separates them.

Start from the shipment path rather than the install. Ask who put the runtime there, under what agreement, and who is obliged to answer for it.

The six instruments, and the evidence that identifies each

Four questions that identify the instrument

1. Who put the runtime on this machine? A vendor installer, an Oracle product installer, your build pipeline, or a person with a browser. Each answer points at a different instrument.
2. What does the version string say? The vendor name in the build output separates an Oracle JDK from an OpenJDK build faster than any inventory tool.
3. Would this process still need Java if the parent product were removed? If yes, no embedded right reaches it, whoever shipped it.
4. Can somebody produce paper for it today? Not eventually, today. An instrument nobody can evidence is an instrument you do not have.

Where "it came with the product" is actually right

There are three cases where the sentence holds, and they are worth knowing because they remove real volume from an audit count.

• The runtime inside an Oracle product. Certain Oracle database, middleware and application licenses carry restricted use rights to the bundled runtime for running that product.
• A vendor with a genuine redistribution agreement. Real agreements exist, and where the vendor confirms yours in writing, naming the version, the install is closed.
• An OpenJDK build the vendor shipped. Distributed under GPLv2 with the Classpath Exception, it carries no Oracle right to prove and no royalty to pay.

and where it usually is not

Everywhere else. The default case is a vendor that recommended Oracle Java, an engineer that downloaded it, and an organization that now owns the consequence.

If you are on the consuming side of that problem, the operational playbook sits on our page on third party applications that bundle Oracle Java. This page is about the license instrument itself.

How are embedded royalties structured?

Around a counting unit that follows the shape of the distribution, and the unit matters far more than the rate. Oracle does not publish embedded or OEM royalty rates, so treat any public per device number you are shown as a rumor rather than a benchmark.

What you can benchmark is structure: which unit is being counted, who counts it, and what the contract does when the count moves.

The metrics, and where each one goes wrong

The clauses worth more than the rate

• Escalator cap. A named percentage over a named term, applied to the whole line rather than a subset. An uncapped escalator compounds against a volume you may be shrinking.
• True down right. The right to reduce the committed quantity at a defined anniversary, without repricing whatever survives.
• An agreed counting method. Written down, with the data source named, so an audit is a reconciliation rather than an argument.
• Exit and transition. A notice window, and a defined obligation to downstream customers so an exit does not breach your own support commitments.
• Version window. Which releases the right covers, and what happens when Oracle's own terms move under you.

Should you ship Oracle JDK or an OpenJDK build?

For most embedded products in 2026, an OpenJDK build, because it removes the royalty and the redistribution question at once. The exceptions are narrow and worth naming.

Ship Oracle JDK where a downstream contract requires it by name, where a specialized Oracle runtime feature is genuinely load bearing, or where a regulated customer will not accept a community supported build without a named support entity behind it.

OpenJDK distribution catalog

What actually decides the choice

• Who your downstream customer will accept. Regulated buyers often want a named support entity, which narrows the field but rarely to Oracle alone.
• Security patch cadence. Oracle's quarterly cycle sets the rhythm, and free builds typically follow within weeks rather than months.
• Support window per release. Check the long term support horizon of the specific build, not the Java version in general.
• Platform coverage. Architecture and small footprint availability differ meaningfully across distributions for device products.
• Specialized runtime features. Low latency collectors and ahead of time compilation are real reasons to pay somebody, though not necessarily Oracle.

How does Oracle audit an embedded distribution?

Usually backward, starting at a downstream end customer and working up to the party that holds the redistribution right. The end customer receives the letter, and the ISV or OEM ends up in the settlement.

The sequence, and where you can intervene

1. The end customer gets the letter. Oracle contacts an organization running a product with Java inside it, and asks about the runtime.
2. The end customer escalates to the vendor. This is the moment the vendor's written statement either exists or does not, and it decides the next six months.
3. The vendor produces its agreement. Redistribution scope, version window, territory and metric are compared against what actually shipped.
4. Oracle turns to the vendor directly. The conversation moves upstream and becomes a commercial reconciliation rather than a compliance letter.
5. Settlement lands at the vendor level. Downstream positions are resolved through the vendor, which is why end customers should escalate early and in writing.

The defense moves that actually work

• Fix the scope before the numbers. Establish which product, which versions and which territory are genuinely in scope before discussing any count.
• Validate the metric against the order form. Oracle's opening count is often built on a metric the order form does not use.
• Separate the OpenJDK volume. Any portion of the fleet already running a free build carries no Oracle right to prove, and it usually is not small.
• Produce evidence, not assertions. Manufacturing records, shipment data and support entitlement data beat estimates in every conversation we have watched.
• Keep the audit and the renewal apart. Two workstreams, two timetables, and no concession in one paid for by the other. Our Java audit negotiations playbook covers the sequencing.

How do you unwind an embedded Oracle dependency?

In two tracks that have to finish together: a technical migration of the runtime, and a contractual amendment of the order form. Finishing one without the other is the most common failure we see.

Oracle's Java SE support roadmap and the No Fee Terms and Conditions set the version boundaries you are migrating around. Plan the amendment date against those, not against your own release calendar.

The five phases

1. Compatibility testing. Run the product across the target build and check JVM tuning, collector behavior, native library bindings and monitoring instrumentation.
2. Pilot. Move a defined cohort of downstream customers or devices and watch performance, stability and support volume for 60 to 90 days.
3. Rollout on the release cadence. Ship the new runtime with normal product releases rather than as a special event, which keeps customer support load flat.
4. Amend the order form. Reduce the contracted quantity to the Oracle JDK volume that actually remains. This is the step that changes the invoice.
5. Deprecate the dependency. Name the supported build in the product documentation and remove the Oracle JDK path from the supported matrix.

The risk register worth keeping

• Performance variance at first run. Real, usually modest, and usually converges once the collector and heap settings are retuned for the new build.
• Patch cadence differences. Free builds generally follow Oracle's quarterly cycle closely, but confirm the specific distribution's record rather than assuming.
• Native library rebuilds. Code compiled against Oracle JDK headers occasionally needs a rebuild, and it is cheaper to find that in phase one.
• Downstream contract language. Customer support agreements that name Oracle JDK by name need amendment before you change what you ship.
• The amendment window. Order forms rarely allow mid term reductions, so the migration plan has to land against a renewal date.

Where the common advice on embedded Java licensing is wrong

The standard advice is that bundling the JDK inside your product is fine because the runtime is free to use. We disagree. The free terms govern use, and redistribution inside a commercial product is a different act with different paper behind it.

The reversal matters in both directions. Plenty of teams pay a royalty on devices that have carried an OpenJDK build for two years, because migrating the runtime felt like the finish line.

Map every shipment path, decide for each one whether it needs an Oracle right at all, and then make the contract match. The word that decides everything is redistribution, not price.

What should a buyer do next?

1. Pull every agreement that mentions redistribution. ISV order forms, OEM agreements, and any Java SE subscription carrying embedded rights.
2. Map the four boundaries on each one. Product, version window, territory and audience, metric and committed volume. Write them on one page.
3. Inventory what actually ships today. Per product release, per device generation, with the distribution and version string recorded rather than assumed.
4. Reconcile the two. Every gap is either an exposure to close or money you are paying for nothing, and both are worth the same to the business.
5. Decide the runtime per product line. Oracle JDK where a downstream contract genuinely requires it, an OpenJDK build everywhere else.
6. Put the amendment on the renewal calendar. Book the true down conversation against the renewal date, not against the engineering milestone. The sequencing is covered in our Oracle contract renewal strategy guide.
7. Give your customers a written answer. A vendor that can state its Java licensing basis in one paragraph wins deals from vendors that cannot.
8. Benchmark before you sign anything. Structure first, rate second, using the Benchmark Program and the Java license calculator.

Frequently asked questions

What is an Oracle Java embedded license?

It is a redistribution right, not a use right. It permits a named party to ship a named Oracle runtime inside a named product, to a defined audience, counted on an agreed metric. The party holding it is the ISV or OEM that redistributes, and the end customer is covered only through that party's agreement.

Can ISVs still embed Oracle Java SE in 2026?

Yes, under a negotiated agreement with redistribution rights written into the order form. No click through download license grants those rights, which is where most ISV exposure starts. The metric follows the product shape, and it is settled in the negotiation rather than taken from a price list.

Does an embedded license let the end customer use the runtime for anything else?

No. The right follows the product, so it covers the customer's use of that application only. It never covers general purpose use of the same binary elsewhere on the machine, which is the single most common breach we find on a customer estate.

What does the OEM model cost per device?

Oracle does not publish embedded or OEM royalty rates, and any figure quoted publicly should be treated as a rumor. What you can control is structure: the counting unit, the escalator cap, the true down right and the agreed counting method. Those clauses move more money over a term than the unit rate does.

How does Oracle audit an embedded Java distribution?

It usually starts downstream and works upward. An end customer receives the letter, escalates to the vendor, and the vendor's agreement is then compared against what actually shipped. Settlement lands at the vendor level, which is why an end customer should escalate to the vendor in writing on day one.

Is OpenJDK the right choice for embedded distribution?

For most products, yes. Builds such as Eclipse Temurin, Amazon Corretto, Microsoft Build of OpenJDK and Azul Zulu are distributed under GPLv2 with the Classpath Exception and carry no Oracle royalty. Keep Oracle JDK only where a downstream contract names it or a specialized runtime feature is genuinely load bearing.

We migrated to OpenJDK. Why is Oracle still invoicing us?

Because the order form still commits you to a volume. A runtime migration changes what you ship, and only an amendment changes what you pay. Reductions are rarely available mid term, so the amendment has to be planned against a renewal date rather than an engineering milestone.

Where does Java ME and Java Card fit?

Both sit outside the Java SE embedded discussion under their own commercial agreements. Java ME targets resource constrained devices and Java Card targets smart cards and secure elements, each with per unit models. Treat them as separate contracts with separate audit exposure.

How Redress engages on embedded Java

Redress engages on embedded Java licensing through Vendor Shield, the Oracle services practice, the Renewal Program, and the Benchmark Program.

Read the related Java licensing reference, the Java audit negotiations playbook, the Java knowledge hub, the Oracle knowledge hub, the ULA decision framework, the Java license calculator, the contract renewal strategy, the contract negotiation service, the database licensing guide, the benchmarking page, the about us page, and the contact page.