Oracle Java Licensing: The Complete 2026 Guide

Oracle Java licensing has become one of the most expensive and least understood software risks on the enterprise balance sheet. Since Oracle moved Java SE to an employee-based subscription in January 2023, the question is no longer "do we have a Java license?" but "how large is our exposure, and how do we control it?" This guide explains every part of the Oracle Java licensing model in 2026 — what is free, what is paid, how Oracle audits, and where the savings are.

1. Why Oracle Java licensing changed

For most of Java's history, the runtime was effectively free. Sun Microsystems, and then Oracle after the 2010 acquisition, distributed the Java Development Kit (JDK) and Java Runtime Environment (JRE) under the Binary Code License — a permissive agreement that allowed broad use of "general purpose" computing at no cost. Enterprises installed Oracle Java everywhere and never thought about it as a licensed product.

That changed in stages. In 2019, Oracle ended free public updates for Java SE 8 in commercial settings and introduced the Java SE Subscription, sold per processor for servers and per Named User Plus for desktops. Then, in January 2023, Oracle replaced that model entirely with the Java SE Universal Subscription, priced on a single metric: the total number of employees in the organisation.

The shift matters because it decouples cost from usage. Under the old processor model, a company that ran Java on ten servers paid for ten servers' worth of processors. Under the employee metric, the same company pays for its entire headcount — every full-time and part-time worker, every agent, contractor and consultant who supports internal operations — regardless of whether they ever launch a Java application. For most enterprises the employee metric produces a bill three to ten times larger than the processor model it replaced.

Oracle frames this as simplification, and in fairness the counting is simpler. But the practical effect is that Java licensing is now a board-level cost line, and any organisation still running Oracle JDK binaries without a current subscription is carrying an audit liability that grows with every new hire.

2. The four Java licensing regimes

To understand your position you have to know which licence governs each Java installation. Oracle has used four distinct agreements over the years, and a typical enterprise estate contains binaries covered by all four at once.

Binary Code License (BCL)

The BCL governed Oracle (and Sun) Java SE through Java 8. It permitted free use for "general purpose" computing but restricted embedded and specialised uses. Critically, the BCL covered Java 8 only up to update 202 (released January 2023's predecessor era — specifically Java 8u202, the last free public BCL update). Any Java 8 update after 8u202 used in a commercial setting requires a paid subscription. Many enterprises still run 8u202 believing they are safe, then patch to a later update and unknowingly cross the licensing line.

Oracle Technology Network License (OTN)

For Java 11 through Java 16, Oracle distributed the JDK under the OTN License Agreement for Oracle Java SE. The OTN licence permits free use only for development, testing, prototyping and demonstrating — and for personal use. Any production or internal business use under OTN is a paid use. This is the single most common compliance gap we see: organisations that downloaded Oracle JDK 11 for free, deployed it to production, and never realised the OTN terms forbid exactly that.

No-Fee Terms and Conditions (NFTC)

Beginning with Java 17 in September 2021, Oracle introduced the NFTC licence. NFTC does allow free production use — including commercial use — but only for a limited window: the current release and one year after the next Long-Term-Support (LTS) release ships. Once that window closes, continued use of those binaries (including security updates) becomes a paid use. NFTC is the most permissive modern Oracle licence, but it is a treadmill: you stay free only if you keep upgrading on Oracle's schedule.

Java SE Universal Subscription

The paid product. The Universal Subscription covers all Java SE versions, all support and updates, on desktop, server and cloud, for the term of the agreement. It is priced per employee (see the next section) and is the licence Oracle expects every commercial Java user to hold.

3. The employee metric explained

The Java SE Universal Subscription is sold per Employee for Java SE Universal Subscription — Oracle's defined term, and it is far broader than a payroll headcount. Oracle's definition includes:

• All full-time and part-time employees;
• All temporary employees;
• Agents, contractors, consultants and outsourcers who support your internal business operations.

In other words, if a person helps run your business in any capacity, Oracle counts them — whether or not they ever use Java, and whether or not they even use a computer. A logistics firm with 8,000 warehouse staff pays for 8,000 employees even though Java runs on a handful of back-office servers.

Pricing is tiered and decreases per-employee as volume rises. Published list pricing starts at $15.00 per employee per month for the smallest band and falls in steps for larger organisations. The headline numbers are sobering:

These figures are list price and indicative only — Oracle's tier breakpoints and rates change, and negotiated discounts vary widely. The point is the order of magnitude: for a mid-to-large enterprise, an Oracle Java subscription is a six- or seven-figure annual commitment. That is why so many organisations are now weighing migration to free OpenJDK builds against the cost of staying on Oracle's metric.

The employee metric does not ask how much Java you use. It asks how many people you employ. For most enterprises that single design choice tripled the cost of Java overnight.

4. Legacy processor and Named User Plus metrics

The 2023 employee metric did not retroactively cancel older agreements. Organisations that bought a Java SE Subscription between 2019 and 2022 hold contracts priced on two legacy metrics:

• Processor — used for server deployments. The processor count is derived from physical cores multiplied by an Oracle "core factor", the same approach used for Oracle Database. Virtualised environments can inflate this dramatically if soft partitioning is not recognised.
• Named User Plus (NUP) — used for desktops, counting individual authorised users with a per-processor minimum.

If you still hold a legacy processor or NUP agreement, you have a decision to make at renewal. Oracle generally will not renew legacy-metric Java contracts; it pushes customers onto the employee metric. Whether you accept that, renegotiate, or migrate away depends entirely on the ratio between your Java footprint and your employee count. A company with heavy Java use and few employees may be better off; a company with light Java use and a large workforce will almost always pay far more. Modelling that comparison before you talk to Oracle is essential — see our guide to the processor versus employee metric.

5. Which Java versions cost money

The most practical question for any IT team is simple: which of the Java versions we run actually require payment? The answer depends on the version, the update level, and how you use it.

Two traps deserve emphasis. First, the Java 8 update trap: 8u202 is free, but the moment a patching tool or an installer pulls 8u211 or later, that machine needs a subscription. Second, the NFTC expiry trap: Oracle JDK 17 was free under NFTC, but once the window closed, the very same binaries — including their security patches — reverted to OTN terms and became paid. Running "the version that used to be free" is not a defence.

6. OTN vs NFTC: the free-use line

The difference between OTN and NFTC is the difference between a compliance gap and a legitimate free deployment, so it is worth being precise.

Under OTN, free use is limited to development, testing, prototyping and demonstrating applications, plus personal use. Production, internal business operations and any commercial deployment are not free. If you find Oracle JDK 11 running a production payroll system, that is a paid use under OTN — full stop.

Under NFTC, free use explicitly includes commercial and production use. The catch is duration. NFTC binaries are free until one year after the next LTS release. After that date, those binaries fall under OTN-style paid terms. NFTC therefore rewards organisations that upgrade promptly and penalises those that freeze on an older release.

For a deeper breakdown of each agreement, see our explainers on the OTN License Agreement and the NFTC License.

7. How Oracle finds unlicensed Java

Oracle does not need to install anything on your network to know you are running Java. It already holds several powerful data sources:

• Download records. Every Oracle JDK download from oracle.com is tied to an Oracle account. Oracle knows which company downloaded which version and when.
• Update and telemetry traffic. Oracle Java's auto-update mechanism and the Advanced Management Console phone home. Connections from your corporate IP ranges are visible to Oracle.
• Support history. Past support tickets, prior Oracle contracts and My Oracle Support activity all flag you as a Java user.
• The soft audit. Oracle's License Management Services and territory sales teams send "review" emails — friendly-sounding requests to confirm your Java usage. These are audits in everything but name.

When Oracle opens a formal review, it typically asks you to run its scripts or deploy its Java Usage Tracker and return the output. What you share, and how, materially affects the size of the eventual claim. Our detailed walkthrough — How Oracle Detects Unlicensed Java Usage — covers each detection channel and how to respond.

8. Java licensing in the cloud

Moving Java workloads to AWS, Azure or Google Cloud does not move the licensing problem. Under the employee metric the location of the workload is irrelevant — you pay per employee regardless of where Java runs. Under legacy processor agreements, cloud deployments are counted using Oracle's cloud-specific rules, which generally count vCPUs and apply Oracle's "Authorized Cloud Environment" policy.

The practical risks in the cloud are:

• Marketplace and base images. Many cloud VM images and managed services ship with Oracle JDK pre-installed. Spinning up such an image can create Oracle Java usage you never chose to install.
• Auto-scaling. Elastic workloads multiply Java instances automatically. Under processor metrics this can quietly inflate your count.
• OCI. Oracle's own cloud includes some Java SE entitlement for certain services, but the rules are specific and do not extend to non-OCI use.

The clean answer in nearly every cloud scenario is to standardise on a free OpenJDK build — Amazon Corretto on AWS, Microsoft Build of OpenJDK on Azure, or Eclipse Temurin anywhere. Our cloud-specific guide, Java on Cloud VMs: AWS, Azure and GCP Licensing, works through each provider.

9. Java in Docker and Kubernetes

Containers are a notorious blind spot. A Docker image built FROM an Oracle JDK base layer carries Oracle's licence terms with it. Every container started from that image is a Java installation. In a Kubernetes cluster that scales to hundreds of pods, a single Oracle-based image can generate enormous notional usage.

The fix is straightforward and free: base your images on an OpenJDK distribution. Eclipse Temurin publishes official container images; Amazon Corretto and Microsoft both publish container-ready builds. Auditing your container registry for Oracle-derived base images is one of the highest-value, lowest-effort compliance actions available.

10. Free alternatives: OpenJDK distributions

The most important fact in Oracle Java licensing is that you almost never have to pay it. Java is an open standard, and OpenJDK — the reference implementation Oracle itself builds from — is available as free, production-grade, fully supported distributions:

• Eclipse Temurin (from the Adoptium project) — the most widely adopted vendor-neutral build.
• Amazon Corretto — free long-term support from AWS, with quarterly security updates.
• Microsoft Build of OpenJDK — free, supported builds optimised for Azure and beyond.
• Azul Zulu — free community builds, with optional paid commercial support.
• Red Hat build of OpenJDK — included with Red Hat subscriptions.

These distributions run the same Java bytecode as Oracle JDK. For the overwhelming majority of applications, migration is a swap of the runtime with no code changes. The differences worth checking are niche: certain commercial features (the old Java Flight Recorder packaging, the deprecated browser plugin and Web Start) and a handful of distribution-specific update cadences. Our comparison, OpenJDK vs Oracle JDK, covers compatibility in detail.

11. How to cut your Java licensing cost

There are five proven levers for reducing Oracle Java cost, and most enterprises can pull several at once:

1. Migrate to OpenJDK. The largest savings, and permanent. Replacing Oracle JDK with Temurin or Corretto eliminates the subscription entirely for those workloads.
2. Right-size the employee count. Oracle's definition of "employee" is broad, but it is not infinite. Defining the contracting entity precisely, and challenging inflated counts, can materially reduce the metric.
3. Eliminate accidental Oracle JDK. Remove Oracle binaries that crept in through installers, bundled software and container images. You cannot be charged for software you no longer run.
4. Negotiate the rate and the term. Oracle's list price is a starting position. Discounts, multi-year price locks and capped renewals are all negotiable — with leverage.
5. Time the renewal. The strongest negotiating position is a credible migration plan. Oracle discounts hardest when the alternative to a deal is losing the customer entirely.

The order matters. A migration plan is both a cost-saving measure and the leverage that makes every other lever work. This is the core of renewal advisory and negotiation work.

12. What to do if you receive an audit letter

If Oracle sends a Java audit notice or a "Java usage review" email, the first 48 hours set the tone for everything that follows. The principles:

• Acknowledge, do not engage on substance. Confirm receipt politely. Do not answer technical questions, do not agree to timelines, and do not run Oracle's scripts on the spot.
• Route it to one owner. All Oracle communication should flow through a single named person. Scattered replies from engineers create admissions you cannot retract.
• Run your own assessment first. Establish your true position internally before you disclose anything. You cannot negotiate a number you do not know.
• Get independent advice. An advisor who knows Oracle's audit playbook will often reduce the claim by more than their fee — many times over.

Oracle's opening claim is almost never the number you will actually pay. Across hundreds of engagements, our recommended advisors have cut Java claims by an average of 68%. For the full process, see Java Audit Defence, which carries a money-back guarantee: if the claim cannot be reduced, the fees are refunded.

13. Java licensing in virtualised environments

Virtualisation is one of the most contested areas of Oracle licensing, and it carries directly into Java for any organisation still holding a legacy processor-metric agreement. Oracle's published position distinguishes between hard partitioning — technologies Oracle recognises as genuinely limiting where software can run — and soft partitioning, which Oracle does not recognise for licensing purposes.

The practical consequence is severe under the processor metric. If Oracle JDK runs on virtual machines inside a VMware cluster, Oracle's contractual position is often that every physical host the VMs could run on must be counted — not just the hosts where Java actually runs. In a large vSphere estate with cluster features that allow VMs to migrate freely, that interpretation can multiply the processor count many times over. Organisations are frequently astonished to be told that a handful of Java VMs implicate an entire data centre's worth of cores.

Two points temper this. First, the employee metric ignores virtualisation entirely — if you are on the 2023 subscription, where Java runs simply does not affect the count. Second, even under the processor metric, Oracle's soft-partitioning position is a contractual interpretation, not settled law, and it can be challenged with evidence of how the environment is actually architected and constrained. Either way, virtualised Java estates should never be assessed casually; the gap between Oracle's opening interpretation and a defensible count is often the single largest line in a Java claim.

14. Java hidden inside other Oracle products

Not all Java in your estate was installed deliberately. Many Oracle products — and many third-party applications — ship with a Java runtime embedded inside them. This creates two distinct situations that must not be confused.

Where Oracle Java SE is bundled with a fully licensed Oracle product and used only to run that product, the Java component is generally covered by the product's own licence — a "restricted use" entitlement. Java embedded in a licensed Oracle middleware product, used solely to run that middleware, is typically not a separate chargeable item. The danger is scope creep: the moment that bundled Java is used for anything beyond the product it came with — a custom script, a second application, a general-purpose workload — the restricted-use protection falls away and a full Java SE Subscription is required.

Third-party software is a different and larger trap. Independent vendors routinely bundle Oracle JRE inside their own installers. If the vendor has not itself licensed that Java for redistribution and your use, the Oracle JRE sitting inside a third-party application can become your compliance liability. Inventorying which applications carry an embedded Oracle runtime — and confirming whether the vendor's licensing covers it — is an unglamorous but essential part of any serious assessment.

15. The most common Java compliance mistakes

Across hundreds of engagements, the same handful of mistakes recur. Recognising them is the fastest way to find your own exposure.

• Assuming "we never bought it" means "we don't owe it." Unlicensed use is still use. The absence of a purchase order is the problem, not the defence.
• Believing a frozen Java 8 estate is safe without verifying it. Patch tools and security mandates routinely advance machines past 8u202 with no decision recorded.
• Treating OTN-licensed Java as free. Oracle JDK 11–16 in production is paid use, full stop — the free OTN path covers only development and testing.
• Letting NFTC versions age out. Java 17 was free under NFTC, then reverted to paid terms. Running "the version that used to be free" is not a defence.
• Running Oracle's audit scripts on request. Volunteering detailed usage data before assessing your own position hands Oracle its strongest evidence.
• Ignoring containers and cloud images. An Oracle JDK base layer copied into a Dockerfile can generate enormous notional usage across a scaled cluster.

None of these is exotic. They are ordinary operational habits that quietly became compliance failures when Oracle changed the rules. The remedy in every case is the same: inventory, verify, and replace Oracle JDK with free OpenJDK builds.

16. Building a defensible Java licensing strategy

A Java strategy is not a one-off clean-up; it is a standing posture. The organisations that handle Oracle Java well treat it as a managed risk with a clear owner, in four stages.

Discover. Build and maintain a complete inventory of every Java installation — version, update level, governing licence, where it runs, and what it runs. You cannot manage what you cannot see, and an inventory that is six months stale is no inventory at all.

Decide. For each Java installation, make a deliberate call: keep on a free OpenJDK build, retire, or — in the rare case where Oracle JDK is genuinely required — license it knowingly. The default should be OpenJDK; Oracle JDK should be the documented exception.

Migrate. Execute the move to OpenJDK in planned waves, server estate first, then desktop. Standardise on one distribution, host it internally, and rewire build pipelines and patch management so the free build is the path of least resistance.

Govern. Put controls in place so the problem does not return: an approved-Java policy, blocked access to Oracle JDK downloads, container base-image scanning, and a periodic re-scan. This is the substance of continuous Java management — the discipline that turns a one-time fix into a permanent state.

Done properly, this strategy ends the Java licensing problem rather than merely surviving the next audit. It is also the strongest possible position from which to negotiate, because an organisation that demonstrably does not need Oracle Java has nothing Oracle can take away.

Frequently asked questions

Related reading