Java 8 licensing: the end of free BCL updates.

Java 8 is, by a wide margin, the most consequential version of Java for licensing risk. It is old, it is everywhere, and it sits at the centre of a licensing change that many enterprises never properly absorbed. The version itself is free; specific updates to it are not. That distinction — between the release and its patches — is where Oracle audits of Java 8 find their money. This guide explains the Binary Code License Java 8 was distributed under, the January 2019 change that ended free commercial updates, and what you should do if Java 8 is still running in your estate.

Why Java 8 still matters

Java 8 was released in 2014 and remains, more than a decade later, one of the most widely deployed Java versions in enterprise environments. Long-lived applications were built on it, certified against it, and never moved. It is common to find Java 8 running quietly on production servers, build agents, desktops, and inside other software — often unnoticed.

That ubiquity is precisely why Java 8 is the focus of so much Oracle audit activity. An auditor who finds Java 8 has found something nearly every large organisation still has somewhere, and the licensing rules around it changed in a way that creates exposure for anyone who did not adjust. If you are assessing Java licensing risk, Java 8 is the first place to look.

Java 8 under the BCL

For most of its life, Java 8 was distributed under the Oracle Binary Code License (BCL). The BCL was the licence that made Java feel free for a generation of developers and enterprises: you downloaded Oracle’s JDK or JRE, you ran it — including in production — and Oracle published regular public updates at no charge.

This is the source of a deeply embedded assumption that still causes trouble: “Java is free.” For a long time, for Java 8, that was broadly true. The BCL permitted general-purpose use, and the public updates were free. Enterprises built that assumption into their operations and never revisited it. The problem is that the BCL, and the free-updates arrangement around it, did not last — and the assumption did.

The January 2019 cliff

In January 2019, Oracle ended free public updates of Java 8 for commercial use. This is the single date that defines Java 8 licensing risk. After this point, an organisation using Java 8 in a commercial or production setting that wanted to keep receiving Oracle’s security and bug-fix updates had to pay for them — through a Java SE subscription.

It is important to be precise about what did and did not change. The change was about updates, not about the existing software. Oracle did not declare every Java 8 installation retroactively unlicensed. The Java 8 builds released before the cutoff remained licensed as they were. What ended was the free supply of new updates for commercial users. From January 2019, “keeping Java 8 patched” and “keeping Java 8 free” became, for commercial use, mutually exclusive unless you migrated to a non-Oracle build.

Oracle did continue free Java 8 updates for personal use for some time afterward, which added to the confusion: the same update file could be free for a home user and paid for a business. The licence depends on who is using it and for what, not on the bytes of the download.

Why update 8u202 is the line

If Java 8 licensing has a single number worth memorising, it is 8u202. Oracle’s Java 8 update releases are numbered — 8u201, 8u202, 8u211, and so on. Update 8u202, released in January 2019, was the last free public update of Java 8 available for commercial use. The updates that followed — 8u211 onward — were published on a footing that required a subscription for commercial or production use.

This makes the build number the decisive fact in any Java 8 compliance question. An Oracle Java 8 installation at update 8u202 or earlier is generally in a free position for the period it covers. An Oracle Java 8 installation at 8u211 or later, used commercially without a subscription, is the classic exposure. “We run Java 8” tells you almost nothing; “we run Oracle Java 8 update 8u341” tells you there is a licensing question to answer.

The Java 8 audit trap

The Java 8 audit trap is almost never deliberate. It is created by ordinary, well-intentioned IT behaviour colliding with a licence change nobody flagged. Two patterns dominate.

The first is routine patching. A security-conscious administrator, told to “keep Java up to date,” downloads and installs the latest Java 8 update. The intention is good security practice. The licensing effect is to move the machine from a pre-2019 free build to a post-2019 paid build — without anyone realising a licence was now required.

The second is auto-update. Java 8 on desktops frequently had auto-update enabled, and auto-update did exactly what it was designed to do: pulled newer builds, crossing the 8u202 line silently. Our guide on Java auto-update compliance risk covers this directly.

The result is an estate where some Java 8 installations are free and some are paid, with no record of which is which. When Oracle audits — and Java 8 is a favourite target — it looks precisely for post-8u202 builds in commercial use. Our guide on how Oracle detects Java explains the discovery methods. The trap is not that anyone broke the rules on purpose; it is that the rules changed under a behaviour everyone considered responsible.

Your three options on Java 8

If you have Oracle Java 8 in your estate — and most enterprises do — there are three honest options, and only three.

1. Freeze on a pre-8u202 build

Keep Oracle Java 8 only at update 8u202 or earlier and never patch it further. This stays within the free position, but it means running software that receives no further security updates — a genuine risk for anything internet-facing. It can be defensible for isolated, low-risk systems; it is not a strategy for a production estate.

2. Buy a Java SE subscription

Pay Oracle for the right to keep Java 8 patched. This is compliant and gives you supported updates, but it is the employee-metric subscription — priced on total headcount, not on how many systems run Java 8 — so it is expensive, and it does not solve the underlying problem of being on a decade-old release.

3. Migrate to a free OpenJDK 8 build

Replace Oracle Java 8 with a non-Oracle OpenJDK 8 distribution. This keeps you on Java 8 — same version, same compatibility — while removing both the cost and the audit exposure. For most enterprises this is the right answer, and it is the subject of the next section.

The free OpenJDK 8 alternative

The most important fact for any organisation stuck on Java 8 is that Java 8 is still available, free, and supported — just not from Oracle. Several vendors publish OpenJDK 8 distributions: Eclipse Temurin 8, Amazon Corretto 8, Azul Zulu 8, BellSoft Liberica 8, Microsoft’s build, and others. These are compiled from the OpenJDK 8 source, are binary-compatible with Oracle’s Java 8, and continue to receive security updates — at no licence cost.

Switching from Oracle Java 8 to, say, Temurin 8 or Corretto 8 is a like-for-like move on the same major version: the lowest-risk migration available, because you are not changing Java version at all, only the vendor of the build. It keeps your decade-old applications running exactly as they do today, keeps them patched, and eliminates the Java 8 licence cost and audit exposure together. Our guide to which Java versions are free for commercial use and our Temurin comparison cover the options, and a structured move is exactly what the Java Migration service delivers.

Getting independent help

Java 8 exposure is widespread, accidental, and entirely resolvable — but only once you can see it accurately. The work is unglamorous: finding every Oracle Java 8 installation, recording the exact build number, separating pre-8u202 from post-8u202, and choosing the right path for each. Independent, buyer-side advisers do this without an Oracle partnership or a resale incentive shaping the conclusion.

Across 340+ Java engagements, that independent work has helped enterprises identify Java 8 audit exposure before Oracle did, migrate cleanly to free OpenJDK 8 builds, and — where an audit had already landed — reduce the claim by an average of 68%. Our Java Compliance Assessment establishes the build-level picture, and our Audit Defence service, backed by a money-back guarantee, defends Java 8 claims if Oracle raises one.

Frequently asked questions