Oracle products that include a Java SE licence.

There is a partial exception to the rule that Oracle Java now costs money: some licensed Oracle products come with a Java SE entitlement bundled in. If you have paid for the right Oracle product, you may have a legitimate, no-extra-cost right to run Oracle Java — but only in a tightly defined way. This “restricted-use” entitlement is genuine, useful, and one of the most dangerous things in Java licensing, because the boundaries are narrow and the temptation to read them generously is enormous. This guide explains how the entitlement works, which products carry it, exactly where its edges lie, and how to use it without walking into an audit claim.

The restricted-use entitlement

When an enterprise licenses certain Oracle products — a database, an application, a piece of middleware — the licence for that product may include the right to use Oracle Java SE as part of running that product. Oracle has historically described this as a “restricted-use” entitlement, and the two words carry the entire meaning.

“Use” means it is a real right: you are not in breach by running Oracle Java in connection with that product, and you do not need a separate Java SE subscription for that specific, in-scope use. “Restricted” means the right is bounded — it permits Java use only for and with the product that grants it, and not for anything else.

The distinction that matters above all others is this: the entitlement licenses Java for the product, not for you. It is not a general Java licence that the product happens to unlock. It is a narrow permission to run the Java that the product itself needs in order to function. The moment your Java use steps outside the product, the entitlement stops covering it.

How the entitlement works

To use the entitlement safely you have to understand its logic, not just its existence.

Many Oracle products are themselves written in Java or depend on a Java runtime to operate. When Oracle sells you such a product, it would be incoherent to also demand a separate Java licence for the Java that the product cannot run without. So the product licence includes the necessary Java SE right — typically expressed in the product's licensing documentation or its accompanying terms, often by reference to Oracle's restricted-use Java provisions.

The entitlement is therefore best understood as derivative. It exists only because, and only to the extent that, the product needs Java. Its scope is defined by the product's need, not by your convenience. Three consequences follow:

• It is tied to a current, valid product licence. If you are not properly licensed for the product, the bundled Java right does not stand on its own.
• It covers the product's Java, in the product's deployment. The Java runtime that ships with or is required by the product, running where the product runs.
• It does not travel. It cannot be redirected to license Java elsewhere in your estate, even on the same servers.

The honest way to think about it: the entitlement is a door into one specific room, not a master key to the building. Walk through it for its intended purpose and you are fine. Try to use it to open other doors and it does nothing — except create the impression, in an audit, that you understood you needed Java licensing and reached for the wrong instrument.

Which products carry it

A fair and important caveat: the exact set of Oracle products that include a Java SE entitlement, and the precise terms of each, is defined by Oracle's product licensing documentation and changes over time. This guide describes the categories and the logic so you know what to look for — it is not a substitute for checking your specific products against Oracle's current terms.

The products that may carry some form of bundled or restricted-use Java SE right tend to fall into recognisable groups:

• Oracle middleware and application servers. Products in the Oracle Fusion Middleware family, including the application-server tier, are Java-based by nature and their licensing has historically addressed the Java runtime they require. WebLogic Server is the most prominent example and is discussed separately below.
• Oracle business applications. Various Oracle enterprise applications are delivered as Java applications and their licensing documentation addresses the Java they run on.
• Oracle Database and its tooling. Elements of the database stack and its associated tools use Java, and the database licensing has historically dealt with the Java those components require.
• Other Oracle products with a Java-based component. Across Oracle's portfolio, many products embed Java, and where they do, the product terms generally address it.

The pattern to take away is not a memorised list — it is a question to ask of every Oracle product you own: does this product include a Java SE entitlement, and if so, exactly what does its licensing documentation say that entitlement covers? The answer is specific to the product and the agreement, and it must be read, not assumed.

Where the boundaries lie

This is the heart of the matter. A restricted-use Java SE entitlement has edges, and the audit risk lives entirely at those edges. The boundaries that consistently catch enterprises are these.

The entitlement does not cover your own applications

If you have an Oracle product with a Java SE entitlement installed on a server, and you also run your own custom Java applications on Oracle Java — even on the same server — the entitlement does not cover those applications. Your applications are not the Oracle product. They need their own Java licensing.

The entitlement does not cover general-purpose Java use

Having a qualifying Oracle product somewhere in the estate does not create a general right to install Oracle Java freely across the organisation. The entitlement is local to the product, not a site-wide licence.

The entitlement does not cover other vendors' software

If a third-party application happens to run on a server that also hosts an entitled Oracle product, the entitlement does not extend to that third-party application's Java use. It covers the Oracle product only.

The entitlement does not survive the product

If you decommission the Oracle product, or let its support lapse such that you are no longer properly licensed for it, the Java entitlement that came with it goes too. Java left running after the product is gone is no longer covered.

The entitlement may be version- and component-bounded

The entitlement typically covers the Java the product actually requires — a particular runtime, used in a particular way. It is not a licence to deploy any Oracle Java version, for any purpose, on the strength of the product. The product's documentation defines the specifics.

Every one of these boundaries is a place where an enterprise, acting in good faith, can drift out of entitlement without noticing — because the Java looks the same, the server looks the same, and the assumption “we're covered, we have the Oracle product” feels reasonable. It is exactly that reasonable-feeling assumption that an audit is designed to test.

Common and costly mistakes

Across more than 340 Java licensing engagements, the same misreadings of the restricted-use entitlement recur. Naming them is the best way to avoid them.

1. “We have an Oracle product, so our Java is free.” The most common and most expensive error. The entitlement covers the product's Java, not the organisation's Java. Custom and third-party applications on Oracle Java are not covered.
2. Co-locating workloads under the entitlement. Installing other applications on the same server as the entitled Oracle product and assuming they shelter under it. They do not — the entitlement follows the product, not the hardware.
3. Treating the entitlement as a migration excuse. Deciding not to migrate off Oracle Java because “the product covers us,” when the product covers only a fraction of actual Java use.
4. Keeping Java after retiring the product. Decommissioning the Oracle product but leaving its Java runtime in service for something else.
5. Relying on memory instead of documentation. Assuming an entitlement exists, or assuming its scope, without reading the product's current licensing terms. Entitlements and their wording change.

The common thread is over-reading. The entitlement is real, and it is worth using — but it is worth exactly what its terms say and not a word more. An enterprise that treats it as broader than it is has, in effect, granted itself a Java licence Oracle never gave it.

A worked example

An illustration makes the boundary concrete. Consider a mid-sized enterprise of 6,000 employees. It runs a properly licensed Oracle middleware product on a cluster of servers, and that product carries a restricted-use Java SE entitlement. On the same servers, the operations team has — quite naturally, over years — also installed Oracle Java to run a set of in-house batch jobs, an internal reporting application, and a third-party monitoring tool. The Java binary is the same Oracle JDK across all of it. The team's working assumption is simple: “we have the entitled Oracle product here, so the Java on these servers is covered.”

Under the entitlement's actual terms, that assumption holds for exactly one of those workloads — the entitled Oracle product itself. The in-house batch jobs are the enterprise's own applications: not covered. The internal reporting application is the enterprise's own application: not covered. The third-party monitoring tool is another vendor's software: not covered. Three of the four Java workloads on those servers are outside the entitlement, even though they share the hardware, the operating system and the very same Oracle JDK install with a workload that is covered.

The financial shape of this is the part enterprises underestimate. Oracle does not bill the correction as “license three workloads on this cluster.” It bills it through the headcount-priced subscription — all 6,000 employees — typically with backdated fees covering the years the uncovered Java has been running. A situation the enterprise experienced as “a few extra jobs on a server we already pay Oracle for” converts, in an audit, into a multi-year, whole-organisation Java SE claim. The lesson is not that the entitlement is worthless — it genuinely covers the middleware product — but that its value is precisely bounded, and everything outside that boundary needs its own answer.

WebLogic and middleware

Oracle WebLogic Server deserves specific attention because it is the entitled product enterprises most often ask about, and the one where the boundary is most often misjudged. Our dedicated WebLogic and Java licensing page covers it in full; the essentials here.

WebLogic Server is a Java application server — it cannot run without a Java runtime, and Oracle's licensing of WebLogic has historically addressed the Java SE that WebLogic itself requires. So a properly licensed WebLogic deployment generally has a legitimate right to the Java SE that WebLogic uses to operate.

The misjudgement is scope. WebLogic is an application server, so enterprises deploy their own Java applications onto it. The instinct is that because WebLogic carries a Java entitlement, everything running on WebLogic is covered. That instinct should be checked carefully against the actual terms. The safest framing is the consistent one: the entitlement covers the Java that the WebLogic product needs to run; whether and how far it extends to the Java workloads you deploy onto WebLogic is a specific question that must be answered from the licensing documentation, not assumed. Given how much custom Java typically runs on a WebLogic estate, the difference between the generous reading and the correct reading can be very large.

A second WebLogic-specific point concerns standalone Java outside WebLogic. Enterprises that run WebLogic sometimes also run Oracle Java directly — a JDK installed on the same or neighbouring servers to run scripts, utilities or applications that have nothing to do with WebLogic at all. The WebLogic entitlement does not reach that standalone Java. The presence of a licensed WebLogic estate is not a general permission to install Oracle Java across the surrounding infrastructure. Each standalone Oracle JDK install is its own licensing question, independent of WebLogic.

The entitlement and cloud deployments

Cloud and virtualised deployments add a layer of complexity to the restricted-use entitlement, and it is worth addressing directly because so many entitled Oracle products now run on cloud infrastructure.

The underlying principle does not change in the cloud: the entitlement covers the Java that the entitled Oracle product needs to run, wherever that product runs. Moving a properly licensed entitled product from a data-centre server to a cloud virtual machine does not, in itself, dissolve the entitlement — but it does not expand it either. The entitlement still follows the product, and only the product.

What the cloud changes is the ease of drift. Cloud environments make it trivial to spin up additional instances, clone machine images, and scale workloads horizontally. An image built to host an entitled Oracle product — Oracle JDK included — can be cloned many times over, and each clone that ends up running something other than the entitled product is an uncovered Java installation. Auto-scaling, disaster-recovery copies, and development or staging replicas of a production image all multiply the footprint of an Oracle JDK that was originally placed there for one entitled purpose. The entitlement does not multiply with the images.

The same caution applies to Oracle Java running on cloud infrastructure for general-purpose reasons — a JDK baked into a base image, a build agent, a container — that happens to coexist with an entitled product elsewhere in the same cloud account. Coexistence in a cloud tenancy is not coverage. Our guide on Java licensing on cloud VMs covers the broader cloud picture; the entitlement-specific point is simply that the cloud's elasticity makes a bounded entitlement easier than ever to over-stretch without noticing.

The audit exposure

The restricted-use entitlement is a focus of Oracle Java audits for a precise reason: it is the place where enterprises most often have a partial right and behave as though they have a complete one. That gap is highly auditable.

In an audit, Oracle will look at the Oracle Java running across your estate and ask, installation by installation, what licenses it. Where you point to a product entitlement, Oracle will test whether the Java in question is genuinely the product's Java, used within the product's scope. Every installation that turns out to be your own application, a third-party application, or general-purpose Java use — sheltering under an entitlement that does not reach it — becomes an unlicensed installation in Oracle's findings.

And, as everywhere in Java licensing, the remedy is priced through the Java SE Universal Subscription on the employee metric — your whole headcount, often with backdated fees. An over-read entitlement does not produce a small, proportionate correction; it produces the same headcount-based claim as any other Java finding. A handful of out-of-scope installations can become a seven-figure demand. Our guides on how Oracle detects Java, audit scope limitation and the audit defence service cover the response — and the reassuring point is that entitlement-based claims are among the more contestable, because the precise scope of the entitlement, the classification of each installation, and the count are all arguable. Audit defence work across these engagements has averaged a 68% reduction in the claim.

Reading the entitlement terms

Because the restricted-use entitlement lives or dies on its exact wording, an enterprise relying on one needs to know where that wording is and how to read it. This is not a detail to delegate to assumption — it is the primary evidence of your licence position.

The terms of an Oracle product's Java SE entitlement are not found in a single universal document. They are assembled from several sources, and all of them have to be read together: the ordering document or licence agreement for the specific Oracle product, the product's own licensing or program documentation, and Oracle's general licensing definitions that those documents reference. The entitlement is frequently expressed by reference rather than spelled out in full — a product's documentation may state that it includes a restricted-use Java SE right and then point to a separate set of terms that defines what “restricted use” means.

Three things are worth establishing precisely when reading those terms. The first is the permitted purpose: the documentation will tie the Java right to running, supporting or administering that specific product, and the exact wording of that tie is the boundary of the entitlement. The second is any component or version limitation: whether the entitlement covers a particular Java runtime delivered with the product, or Java use more broadly in connection with it. The third is the dependency on the product licence itself: the entitlement is conditional on holding a valid, supported licence for the product, so a lapse on the product side is also a lapse on the Java side.

A practical caution: Oracle's product licensing documentation changes over time, and the terms that applied when you first licensed a product may not be identical to the current ones. The version of the terms that governs your use is generally the one tied to your agreement — which is another reason to keep the original ordering documents and licence agreements accessible, not just the current web versions. When the wording is ambiguous, that ambiguity should be resolved deliberately, with specialist input, rather than resolved optimistically in your own favour. An entitlement read carefully and documented is a defensible asset in an audit; an entitlement assumed from memory is not.

How to verify your position

The way to use the restricted-use entitlement safely is to verify it deliberately, not to rely on it by reflex. A sound process:

1. Inventory all Oracle Java. Find every Oracle JDK and JRE installation across servers, virtual machines, containers and embedded copies. You cannot map entitlements onto an estate you cannot see. Our detection guide describes what a thorough inventory covers.
2. Identify which Oracle products you hold that may carry a Java entitlement. List your licensed Oracle products and, for each, read the current licensing documentation to determine whether a Java SE entitlement exists and what it says.
3. Map Java installations to entitlements. For each Oracle Java installation, determine whether it is genuinely the Java of an entitled product, used within that product's scope. Be strict — strictness here is protection.
4. Isolate the uncovered installations. Everything not genuinely covered — custom applications, third-party software, general-purpose use, Java outliving a retired product — is your real Java licensing exposure.
5. Decide on the uncovered estate. For the genuinely uncovered Java, the choice is the same as anywhere else: license it through a subscription, or migrate it to a free OpenJDK build that needs no entitlement at all. For most estates the migration is both cheaper and cleaner.

Done properly, this exercise usually delivers two findings at once. It confirms which Java really is covered by an entitlement — a legitimate saving you can defend — and it surfaces the uncovered Java before Oracle does, while you still have every option open. That sequencing is the whole game: an entitlement you have verified is an asset; an entitlement you have assumed is a liability.

Frequently asked questions

This article is general information on Oracle product entitlements, not legal advice. The products that include a Java SE entitlement, and the precise terms of each, are defined by Oracle's licensing documentation and change over time; consult a qualified independent Java licensing specialist on your specific products and agreements.