The Oracle BCL license: complete, explained.

For nearly twenty years, the Oracle Binary Code License — the BCL — was the agreement under which the world ran Java. It was the licence on the JDK and JRE that millions of enterprises downloaded, installed and embedded without a second thought, because for most of its life it permitted free commercial use. That history is exactly why the BCL is dangerous today. The change that ended free use under it was widely missed, and the legacy installations still running under BCL terms are now one of the most common findings in an Oracle Java audit. This guide explains the BCL in full: what it was, what it allowed, what changed in 2019, how it relates to the OTN and NFTC licences that followed, and what to do about the BCL-era Java still in your estate.

What the BCL is

The Oracle Binary Code License Agreement for the Java SE Platform Products — commonly the BCL — is the licence agreement that historically governed the use of Oracle's pre-built Java binaries: the Java Development Kit (JDK) and the Java Runtime Environment (JRE). It is important to be precise about what it covered. The BCL did not license “Java” the language or platform, which is an open specification. It licensed the binary distribution — Oracle's compiled, packaged JDK and JRE that an enterprise downloaded from Oracle and installed.

The name itself is the key. “Binary Code License” signals that this is the agreement attached to the binaries, as distinct from the source code (which is governed by the open-source licence of the OpenJDK project). When you accepted the click-through agreement during a JDK installation, or when your automated provisioning pulled an Oracle JDK, the BCL was the contract that defined what you could and could not do with it.

The BCL was a single, named agreement, but its terms were not frozen — Oracle revised it over the years, and it also incorporated “Supplemental License Terms” that adjusted the permissions for particular components and versions. That evolving quality matters, because two installations both nominally under “the BCL” can carry materially different permissions depending on the exact version and download date.

A short history of the BCL

To understand why the BCL is a problem now, it helps to see where it sat in the timeline of Java licensing. Our full Java licensing history tells the longer story; the BCL's arc is this.

Java originated at Sun Microsystems, and for most of Sun's stewardship the Java runtime was distributed under terms that the industry treated, in practice, as free for general use. The BCL was the agreement carried forward as the standard licence for the Java SE binaries. When Oracle acquired Sun in 2010, it inherited the BCL and continued to use it as the licence on the JDK and JRE.

For most of the 2010s, the situation was stable and benign from an enterprise perspective. You downloaded the Oracle JDK, accepted the BCL, and ran it — in development, in testing, and in production — at no licence cost. This was not an oversight; the BCL of that era genuinely permitted it. An entire generation of enterprise Java estates was built on that understanding: Oracle Java is free, install it wherever you need it.

That stability is the trap. Because “Oracle Java is free” was true for so long, it became an unexamined assumption — baked into provisioning scripts, golden images, developer habits and procurement expectations. When Oracle changed the terms, the assumption did not change with them. The BCL's long, generous history is precisely what made the end of that history so easy to miss.

What the BCL permitted

Through most of its life, the BCL granted broad rights that explain why Oracle Java spread so widely. In its general-use form, the BCL permitted an enterprise to:

• Use the Oracle JDK and JRE for free for internal business operations — not merely for evaluation or development, but for running production applications.
• Install it widely across servers and desktops without counting installations or paying a per-unit fee.
• Redistribute the JRE with applications, subject to specific redistribution conditions in the Supplemental License Terms — which is why so many third-party software products historically shipped with a bundled Oracle JRE.

There were always conditions. The BCL prohibited modifying the binaries, removing proprietary notices, and using Java in certain high-risk applications without separate arrangements. Commercial features — a set of specifically identified, separately licensed capabilities such as certain profiling and management tools — were carved out and were never free under the BCL even when the core JDK was. But the central point stands: for the bulk of the BCL era, running the standard Oracle JDK and JRE in a commercial production environment carried no licence fee. That is the permission enterprises relied on, and that is the permission that ended.

The April 2019 change

The decisive event in the BCL story is Oracle's change to Java SE licensing in April 2019. This is the moment the BCL stopped being a free pass for new updates — and it is the moment most enterprises did not register at the time.

From Oracle Java SE 8 update 211 (April 2019) onward, Oracle changed the licence under which it released Java SE updates. New Oracle JDK updates were no longer issued under the free-for-commercial-use BCL. Instead they moved to the Oracle Technology Network (OTN) License Agreement for Java SE, which permits development and testing but requires a paid subscription for production and commercial use.

The practical effects were sharp and easy to misread:

• Older builds stayed under the BCL. Java SE 8 builds up to and including update 202, and earlier versions, remained governed by the BCL terms they were released under. They did not retroactively become paid.
• New builds were OTN, not BCL. Every Java 8 update from 8u211 forward — the updates that contained the latest security patches — came under OTN terms, meaning production use of those updated builds required a subscription.
• The free path and the secure path diverged. An enterprise could stay on a free, BCL-era build only by also staying on an old, no-longer-patched version. To get current security updates from Oracle, it had to accept the OTN licence and, for production, pay.

This is the heart of the BCL problem. The change was not announced as “Oracle Java is now paid” in terms most enterprises noticed. It was a licence change on a point release. Many organisations continued exactly as before — patching their Oracle Java 8 estate with the latest updates — without realising that the act of installing 8u211 or any later Oracle update had moved those installations from a free licence to a paid one.

BCL vs OTN vs NFTC

The BCL is one of three Oracle Java licences an enterprise will encounter, and confusing them is a common and costly mistake. Our full BCL/OTN/NFTC comparison goes deeper; the essential distinctions are these.

Reading the table, the BCL looks similar to the NFTC — both permit free commercial use. But the resemblance is misleading. The BCL of the free era permitted free production use of that build indefinitely, with no defined cut-off. The NFTC permits free use only for a limited window after each version's release, after which continued use of that same version needs a subscription. And the OTN licence sits between them as the genuinely restrictive one: it never permitted free production use at all.

The crucial practical insight is that an enterprise's estate is almost never under a single licence. A real-world Oracle Java estate is typically a mix: some genuinely free BCL-era Java 8, some OTN-licensed Java 8 updates and Java 11 installs that require a subscription, and possibly some NFTC-era Java 17+. Determining which licence governs each individual installation — by version and download date — is the only way to know your true position. A blanket assumption either way is wrong.

BCL and the Java 8 problem

Java 8 deserves its own section, because it is where the BCL legacy is most concentrated and most dangerous.

Java 8 was, and in many estates still is, the most widely deployed version of Java in the enterprise. It was released in 2014, in the heart of the free-BCL era, and a vast number of business-critical applications were built and certified on it. Many of them are still running on it today. That installed base is enormous, long-lived, and frequently undocumented.

The Java 8 problem is the collision of three facts. First, Java 8 is old enough that most enterprises feel they should keep it patched for security. Second, every Oracle Java 8 security update since April 2019 carries the OTN licence, not the BCL. Third, those updates are applied routinely — by patch management tools, by administrators following good practice, sometimes by the JRE's own auto-update mechanism — often without anyone evaluating the licence implication.

The result is that countless enterprises that believe they are running “free Java 8 under the BCL” are in fact running OTN-licensed Java 8 updates that require a paid subscription in production. They are not non-compliant through carelessness in the ordinary sense — they are non-compliant because they did the right thing on security and the licence changed underneath them. Our guides on installer download compliance and auto-update risk cover how the patched-but-unlicensed state arises.

It is worth being precise about one nuance, because enterprises sometimes draw false comfort from it. A genuinely BCL-era Java 8 build — say 8u202 — that has simply never been updated is, on its original terms, still under the BCL. The exposure is not created by having old Java 8; it is created by updating it past the April 2019 line. But this is cold comfort in practice. Running an unpatched, years-old Java 8 build to preserve a free licence means accumulating unpatched security vulnerabilities — an unacceptable posture for any production system. The only responsible versions of Java 8 to run are patched ones, and every patched Oracle Java 8 build is OTN-licensed. The free-but-insecure option is not a real option. That is the bind, and it is the reason a move to a free, fully patched OpenJDK build is so often the only sensible exit.

BCL and bundled JREs

There is a second BCL legacy that is even harder to see than patched Java 8, and it deserves its own treatment: Oracle Java embedded inside other software.

For many years, because the BCL permitted redistribution of the Java Runtime Environment under defined conditions, a great deal of commercial and internally built software shipped with its own copy of the Oracle JRE. Rather than depend on a system-wide Java install, applications bundled a private JRE so they could control exactly which Java version they ran on. This was standard practice, encouraged by the redistribution rights in the BCL Supplemental License Terms.

The consequence today is that an enterprise's Oracle Java footprint is almost always larger than its inventory of deliberately installed JDKs. Oracle JRE copies are tucked inside the installation directories of third-party desktop applications, line-of-business tools, engineering software and appliances — places no one thinks to look when assessing “our Java estate.” Each embedded JRE is an Oracle Java installation, and each is subject to the same licence analysis as any other: which version, which update level, BCL or OTN.

This matters in two directions. On one hand, a private JRE bundled by a third-party vendor and used solely to run that vendor's product may be the vendor's licensing responsibility, depending on the redistribution arrangements — a point worth establishing rather than assuming. On the other hand, an embedded Oracle JRE that the enterprise itself extracted, copied, repurposed, or updated independently of the host application is squarely the enterprise's own Java use, with the enterprise's own exposure. Oracle's audits look specifically for embedded JREs, because they are numerous, easily overlooked, and frequently updated into OTN territory. Any honest BCL-era assessment has to count them.

Why the BCL creates audit exposure

Oracle's Java audits are, to a significant degree, built around exactly this BCL-era confusion. Understanding why turns an abstract licence-history lesson into a concrete risk.

When Oracle examines a Java estate — through a formal audit or a “soft” review letter — it is looking for Oracle JDK and JRE installations that are not covered by a subscription. The BCL legacy hands Oracle a target-rich environment for two reasons.

The first is the patched-Java-8 finding described above: large numbers of installations running post-April-2019 Oracle updates under OTN terms, which the enterprise wrongly believed were free BCL Java. Each one is, from Oracle's perspective, unlicensed production use.

The second is download records. When you download Oracle Java from Oracle's site, that download is associated with an account, and Oracle retains those records. An enterprise whose staff have downloaded post-2019 Oracle Java updates has, in effect, created evidence that Oracle can point to. Our guide on how Oracle detects Java usage covers this in detail.

The exposure compounds because of how Oracle prices a resolution. Oracle does not simply ask you to license the specific unlicensed installations it found. The current commercial vehicle is the Java SE Universal Subscription, priced on the employee metric — your entire headcount. So a finding of a few hundred BCL-era installations that were silently patched into OTN territory can become a demand to license every employee in the organisation, often with several years of backdated fees attached. A modest technical finding becomes a seven-figure claim. This is the mechanism behind the largest Java audit claims, and across more than 340 engagements it is the single most common root cause we see. The good news is that these claims are also highly reducible — our audit defence work averages a 68% reduction — because the BCL/OTN boundary, the count, and the backdating are all contestable. Our audit scope limitation guide explains how.

Do you still rely on the BCL?

The constructive question for any enterprise is: are we still depending on the BCL to justify free Java use — and is that dependence sound? Working through it requires a real inventory, not an assumption.

The steps are straightforward in principle:

1. Find every Oracle Java installation. Across servers, desktops, virtual machines, containers and embedded copies inside third-party applications. You cannot assess a licence position you cannot see.
2. Record the exact version and update level. Not just “Java 8” but the precise update — because 8u202 and 8u211 sit on opposite sides of the BCL/OTN line.
3. Distinguish Oracle builds from non-Oracle builds. An OpenJDK build from Temurin, Corretto, Zulu or another vendor is not under any Oracle licence at all and carries no exposure. Only Oracle's own builds are in scope.
4. Classify each Oracle installation by licence. Genuinely free BCL-era build; OTN-licensed build requiring a subscription for production; or NFTC-era build. This classification is your actual licence position.
5. Quantify the OTN-licensed production exposure. The installations in the second category are the ones that matter — the gap between what you believed and what you owe.

An enterprise that completes this exercise honestly almost always finds it relies on the BCL far less than it assumed, and on OTN-licensed builds far more. That is uncomfortable but valuable: it converts a vague worry into a defined, addressable number — and it is far better to find it yourself than to have Oracle find it for you.

The free alternative

The BCL story has a genuinely reassuring ending, and it is important to state it clearly: the loss of free Oracle Java does not mean the loss of free Java.

Java the platform remains open source. The OpenJDK project is the official reference implementation, and multiple vendors produce free, production-grade, fully licensed builds of it: Eclipse Temurin, Amazon Corretto, Azul Zulu, BellSoft Liberica, the Microsoft build of OpenJDK, the Red Hat build, and others. These are released under the GPLv2 with Classpath Exception licence — free to run in production, free to redistribute, with no employee metric, no subscription, and no Oracle audit exposure. They are TCK-certified, meaning they behave identically to the Java SE specification, and they receive the same quarterly security updates as Oracle's builds.

For an enterprise carrying BCL-era exposure, this reframes the whole problem. The question is not “how much must we now pay Oracle for the Java we always had for free” — it is “how do we move our estate to a free build that genuinely is free, permanently, and put the BCL legacy behind us.” Migrating an Oracle JDK 8 estate to a free OpenJDK 8 build is, at the same version, a low-risk distribution swap; our OpenJDK comparison and application compatibility guide set out how. The end state is an estate with no Oracle Java licence question at all.

Frequently asked questions

This article is general information on Oracle Java licensing history, not legal advice. Licence terms and Supplemental License Terms vary by version and download date; consult a qualified independent Java licensing specialist on your specific estate.