Skip to content

Oracle Java Licensing: BCL, OTN and NFTC Explained

Three different Oracle Java licences apply depending on which version you installed and when. What each one permits, when a no-fee licence stops being no-fee, and how to work out which of your JVMs are actually chargeable.

Oracle Java licensing catches organisations out for a structural reason: nothing about installing a JVM tells you which licence governs it. The binary looks the same, the command is the same, and the developer who installed it three years ago has left. The licence depends on which version was downloaded, when, and from where — and Oracle has changed the answer three times since 2019.

This is a guide to the three licences you will encounter, what each one permits, and how to work out which of your Java installations are actually chargeable.

Before the licence detail, the method. Java compliance is a discovery problem before it is a licensing problem, and organisations that get into trouble almost always get there by answering the licensing question about a population they had not finished counting.

Work in this order:

  1. Find every JVM. Not every Oracle JVM — every JVM. You cannot decide what is chargeable until you know what exists, and Java arrives bundled inside third-party applications as often as it is installed deliberately.
  2. Identify vendor, distribution and version for each one. “Java 8” is not an answer. 1.8.0_202 and 1.8.0_211 are separated by one update and by a different licence. Oracle JDK, Oracle OpenJDK builds, Eclipse Temurin, Amazon Corretto and Azul Zulu are different products with different terms.
  3. Establish where each installation came from. The download channel matters, because the same version number can be distributed under different terms.
  4. Meter usage. An installed JVM that nothing has executed in a year is a removal candidate, and removing it is cheaper than licensing it.
  5. Decide per installation. Remove, replace with a non-Oracle distribution, or licence. Then record the decision, because you will be asked to justify it.

Only after that is a licence position meaningful. Doing it the other way round — starting from Oracle’s licence definitions and then trying to find the installations they apply to — is how organisations end up over-declaring.

What is an Oracle BCL?

The Binary Code Licence, usually written BCL, is the licence most organisations were operating under without ever reading it. It governed Oracle’s Java SE releases historically, and it permitted free use — including commercial production use — for what Oracle defined as general purpose computing.

The BCL is why “Java is free” became institutional knowledge. For most of Java’s history, for most uses, it was true.

The relevant cut-off is Java 8 update 202, released in January 2019. That was the last Oracle Java 8 public update available for free commercial use under the older terms. Anything after it changed licence.

If you have Java 8 installations at 1.8.0_202 or earlier, they are not the problem. The ones that quietly took a later patch are.

What is the NFTC licence?

The Oracle No-Fee Terms and Conditions licence, introduced in September 2021 with Java 17, allows any user — personal, development or commercial — to download, install and use the Oracle JDK for any purpose, including commercial production deployment, at no charge.

That is genuinely free, and it is not a trap. But it is time-boxed, and the box is defined relative to Oracle’s release cadence rather than to a fixed date.

Oracle provides an LTS release under the NFTC from the date it ships until one year after the next LTS release ships. In practice:

  • Java 17 (September 2021) received NFTC updates until September 2024 — one year after Java 21.
  • Java 21 (September 2023) receives NFTC updates until September 2026 — one year after Java 25.
  • Java 25 (September 2025) receives NFTC updates until September 2028.

The window is roughly three years, and it moves. Anyone planning on the basis that “Java 21 is free” needs the second half of that sentence.

NFTC and OTN: what is the difference?

Between the BCL and the NFTC sits the Oracle Technology Network Licence Agreement for Oracle Java SE — the OTN licence — introduced in April 2019 and applied to Java 8 updates from 1.8.0_211 onwards and to Java 11.

The difference is the one that matters most in practice:

The OTN licence permits free use only for development, testing, prototyping and demonstrating applications, and for personal use. Production and commercial use require a paid subscription. There is no ambiguity in the wording, and there is no grace for having installed it by accident.

The NFTC licence permits free use for anything, including production, for the period described above.

So the two no-fee licences are not variations on a theme. One is free for everything and expires; the other is free only for non-production and does not expire. A JVM under OTN running a production workload is chargeable from the day it started running it. A JVM under NFTC running the same workload is not — until the window closes.

The trap is the transition. When an NFTC window ends, the release does not become chargeable. What happens is that subsequent updates for that release are published under the OTN licence instead. Stay on the last NFTC build and you are still compliant and no longer receiving security patches. Take the next patch and you have accepted OTN terms for a production system. Neither of those is a good place to be discovered in, which is why the end of an NFTC window is a planning deadline rather than a billing event.

Oracle Java licence types: risks, restrictions and strategy

Where a subscription is required, the current commercial offering is the Oracle Java SE Universal Subscription, introduced in January 2023. Its defining characteristic is the metric: it is counted per employee, not per Java user, per device or per processor.

That is the single most important thing to understand about Oracle Java commercially, because it breaks the intuition every other software licence has trained into you. Under the previous Java SE Subscription — named user plus for desktops, processor for servers — reducing your Java footprint reduced your bill. Under the Universal Subscription, an organisation with four Java servers and one with four hundred can be counted identically, because the count is a function of headcount rather than deployment. Oracle’s definition of employee is also broad, extending beyond permanent staff.

Three consequences follow, and they should shape your strategy:

  • Partial compliance is expensive. Licensing “just the production servers” is not an option the metric supports. If you need the subscription at all, you need it at organisational scale.
  • Removal has to be complete to be worth anything. Getting from four hundred Oracle JVMs to four saves nothing. Getting to zero saves everything. This makes Java migration an unusually binary project, and it should be planned as one.
  • Non-Oracle distributions become strategically significant. Eclipse Temurin, Amazon Corretto, Azul Zulu and other OpenJDK builds implement the same specification under their own terms. Migration is not free — it costs testing, and some vendor applications certify only against a specific JDK — but for many workloads it is the cheaper answer, and the calculation is worth doing properly rather than assuming.

The risk to plan around is not really the audit. It is discovering, halfway through a negotiation, that you do not know how many JVMs you have or where they came from, and having to accept Oracle’s count because you cannot produce your own.

When are NFTC licences not valid?

An NFTC licence stops covering you in more situations than the headline suggests. The common ones:

  • The free-update window has closed for that release. Updates published after the window fall under the OTN licence, so applying one to a production system moves it onto commercial terms.
  • The release was never under the NFTC. Java 8 and Java 11 predate it entirely. No amount of patching brings them under it.
  • You are running a non-LTS release past its short support life. Interim feature releases get six months of updates; they are not a basis for a production standard.
  • You are relying on the NFTC to cover a distribution it does not govern. The licence attaches to specific Oracle builds. Commercial features and Oracle-specific components outside those builds are licensed separately.
  • You have redistributed the JDK in circumstances the terms do not permit. The NFTC allows redistribution, but with conditions, and embedding Java inside a product you ship is a different conversation from installing it internally.

The practical test is not “are we on a free version” but “which exact build is on each machine, under which licence did it arrive, and what is it being used for”. That is three data points per installation, and there is no way to answer them from memory.

Getting the data

This is where Java compliance becomes an ITAM problem rather than a legal one.

You need discovery that reaches every platform Java runs on — which in most organisations means Windows, macOS and Linux, plus AIX, HP-UX or Solaris in the datacentre, where Java is frequently oldest and least documented. CerteroX ITAM runs a native agent across all six of those operating system families, alongside agentless and command-line inventory for locked-down systems and standalone inventory for anything air-gapped, so the population you count is the whole population rather than the part that was easy to reach.

You need recognition precise enough to distinguish builds, not just products. CerteroX SAM resolves installations against a Software Recognition Database of over 3.5 million titles, with release date, end-of-support and extended-support dates attached — which is what turns a list of JVMs into a list of licensing decisions.

And you need usage. AppsMonitor meters execution with first-used and last-used tracking and a rolling 90-day utilisation figure, which is how you separate the JVMs that need a decision from the ones that need uninstalling.

Certero is also a verified third-party tool vendor with Oracle License Management Services. In Certero’s own published wording: being a verified third-party toolset means that Oracle’s audit team can accept data from Certero during an official audit, as an alternative to installing Oracle License Management measurement tools. That is a conditional rather than a guarantee, but it changes the starting position of the conversation.

If the Java question is open in your organisation, the useful first step is not a licensing opinion. It is a count you trust.

Related reading

Other posts covering the same ground.

  • Device-based licensing and access control

    Locking an application down at user level does not make you compliant with a per-device licence. In a Citrix or RDS environment, one user with access can cost you a licence for every device in the organisation.

    • ITAM
    • SAM
    • Governance
    4 min
  • Gartner Myth Buster – Part 1

    A third-party summary of a vendor can be wrong, and it stays wrong for as long as people read it. The case for checking a vendor's facts at source — and the current, sourced record for Certero.

    • ITAM
    • SAM
    • Governance
    7 min
  • The role of good data in software audits

    An audit is won or lost on the quality of your inventory long before the letter arrives. Six ways data goes wrong, and what it takes to have the answer already in hand.

    • ITAM
    • SAM
    • Governance
    8 min
From reading to evidence

Put the hardest claim here
to a technical person.

Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.

No gated download at the end of it.