It runs on Oracle’s cloud, in your building. Java licensing still applies

Oracle Cloud at Customer is an unusual deployment model: Oracle’s own cloud infrastructure, racked and operated inside your data centre rather than in an Oracle region. For organisations with data-residency rules or latency-sensitive systems, it is an appealing middle ground. But the model creates a persistent licensing question for Java — because it sits at the intersection of “our data centre” and “Oracle’s cloud,” and intuition pulls in two directions. The instinct that “it’s Oracle’s cloud, so Oracle’s software comes with it” is exactly the instinct that leads to an unexpected Java SE claim. This guide sets out what Cloud at Customer does and does not change for Java licensing.

What Oracle Cloud at Customer is

Oracle Cloud at Customer — the family that includes Exadata Cloud@Customer, Compute Cloud@Customer and Oracle’s dedicated-region offerings — delivers Oracle Cloud Infrastructure (OCI) on hardware that physically resides in the customer’s own data centre. Oracle owns and manages the infrastructure; the customer consumes it as a cloud service, but the racks sit on-premises behind the customer’s own walls and network.

The appeal is real: customers get OCI’s service model and Oracle’s management while keeping data physically local for sovereignty, regulatory or latency reasons. But for software licensing, the hybrid nature is precisely the complication. Cloud@Customer is consumed like a cloud, located like on-premises, and managed by Oracle — and each of those three facts pulls a different intuition about who licenses the Java running on it. The contract, not the intuition, is what governs.

The “it’s Oracle’s cloud” myth

The single most expensive assumption around Cloud at Customer is that because the infrastructure is Oracle’s, the Oracle software running on it — including Java SE — is somehow bundled in. It is an understandable leap. The hardware is Oracle’s, the platform is Oracle’s, Oracle manages it; surely Java, an Oracle product, is part of the package?

It is not. Oracle Cloud at Customer is an infrastructure and platform service. What it provides is compute, storage, networking and the cloud control plane — not a blanket licence to every piece of Oracle software a customer chooses to install on top. Java SE is licensed under its own terms, by its own metric, entirely separately from the Cloud@Customer subscription. Installing Oracle’s JDK on a Cloud@Customer compute instance and using it for production creates exactly the same Java SE obligation it would create on any other server. The infrastructure being Oracle’s changes the operational model; it does not change the Java licence.

The employee metric is location-agnostic

There is a second, deeper reason Cloud at Customer changes nothing for Java: the metric Java SE is sold on does not care where Java runs. The current Java SE Universal Subscription is priced on the employee metric — the subscription is sized on your total organisation headcount, not on servers, processors, vCPUs, or locations.

That has a clarifying effect. Under the old processor-based Java metrics, the question “is this Oracle’s cloud, my data centre, or a public cloud?” affected how you counted. Under the employee metric, it does not. Whether your Java runs on-premises, in AWS, in Azure, in OCI, or on Cloud at Customer hardware in your own building, the licence requirement is the same: if any chargeable Oracle Java is in use, the subscription is sized on your whole workforce. Cloud at Customer does not raise the count and does not lower it. It is simply one more place Java can run — and the count is blind to place.

When Java is genuinely included

This does not mean Java on Cloud at Customer is always chargeable. There are legitimate routes to free or already-covered Java, and they are the same routes that apply anywhere.

• OpenJDK. A free OpenJDK distribution — Temurin, Corretto, Zulu — running on a Cloud@Customer instance carries no Oracle Java requirement at all. The infrastructure being Oracle’s is irrelevant; OpenJDK is free regardless of where it runs.
• NFTC-covered Oracle JDK. Oracle JDK 17 or later, used within its NFTC free-use window, is free on Cloud at Customer exactly as elsewhere.
• Java embedded in a licensed Oracle product. Where Java is supplied as a restricted-use runtime inside another fully licensed Oracle product, that embedded use is covered by the host product’s licence — on Cloud@Customer as anywhere.

What is not a route to free Java is “it runs on Oracle’s cloud hardware.” The valid exemptions are about the Java distribution, the version and its terms, or an embedding product — never about the underlying infrastructure’s ownership.

Oracle products on Cloud@Customer

Cloud at Customer is often chosen specifically to run Oracle’s database and middleware estate, and that raises a related Java question worth keeping separate. Several Oracle products ship with a restricted-use Java SE runtime — WebLogic Server is the most familiar example, and other Oracle products bundle Java too.

When such a product runs on Cloud at Customer, the Java embedded within it for that product’s own operation is generally covered by the product’s licence — the same restricted-use grant that would apply on-premises. The trap is not the embedded runtime; it is general-purpose Java use. If your teams install a full JDK on a Cloud@Customer instance and use it to run your own applications — not the bundled product — that is standalone Java SE use, and the restricted-use grant from the Oracle product does not stretch to cover it. The distinction between “Java embedded in product X, used for product X” and “Java installed generally, used for our own software” is exactly as important on Cloud@Customer as anywhere else.

How to license Java on Cloud@Customer

A sound approach treats Cloud at Customer instances exactly like any other Java-bearing server:

1. Inventory the Java on every Cloud@Customer instance. Identify the distribution and version — Oracle JDK or OpenJDK, and which release — on each compute instance, just as you would on-premises.
2. Classify each install. Is it free OpenJDK, NFTC-covered Oracle JDK, restricted-use Java embedded in a licensed Oracle product, or chargeable standalone Oracle Java SE?
3. Ignore the infrastructure ownership. The fact that the hardware is Oracle’s tells you nothing about the Java licence. Do not let it shortcut the classification.
4. Fold it into the single employee-metric position. Chargeable Java on Cloud@Customer does not create a separate subscription — it is part of your one organisation-wide Java SE position.
5. Prefer OpenJDK where you can. For general-purpose Java on Cloud@Customer instances, a free OpenJDK distribution removes the chargeable element entirely.

Common mistakes

• Assuming Java is bundled with Cloud@Customer. It is not. Cloud at Customer licenses infrastructure; Java SE is separate, with its own metric.
• Thinking Oracle-owned hardware exempts Java. The infrastructure’s ownership is irrelevant to the Java licence. Only the distribution, version and terms matter.
• Treating Cloud@Customer as a separate Java count. Under the employee metric there is one organisation-wide position. Cloud@Customer Java folds into it; it does not create a parallel subscription.
• Stretching a restricted-use grant. Java embedded in a licensed Oracle product covers that product’s use only — not your own applications running on a general JDK.
• Skipping the inventory. Cloud@Customer instances are sometimes left out of Java discovery because they “feel like cloud.” They must be inventoried like any server.

Getting independent help

Oracle Cloud at Customer is a genuinely useful model — cloud economics and operations with on-premises data residency. But its hybrid character is also a licensing trap for Java. The hardware being Oracle’s, the platform being Oracle’s, and Oracle running it all combine to suggest that Java must be included. It is not. Cloud at Customer licenses infrastructure; Java SE is a separate product with its own employee metric, and that metric is blind to where Java runs. Chargeable Oracle Java on a Cloud@Customer instance is chargeable for exactly the reasons it would be on any other server.

Independent, buyer-side advisers classify every Java install on a Cloud at Customer estate correctly — free, embedded, or chargeable — and fold the result into a single, defensible organisation-wide position. Our Java Compliance Assessment covers Cloud@Customer instances alongside the rest of your estate; our Java Migration service moves general-purpose Java to free distributions where that is the better path. Across 340+ Java engagements, that approach has contributed to a 68% average reduction in audit claims and more than $180M in client savings.

Frequently asked questions