Java Critical Patch Updates without a license.

There is a worry that drives a lot of unnecessary Oracle Java spending, and it goes like this: "We must stay on top of Java security patches, and Oracle owns Java, so we must pay Oracle to keep getting them." It is an understandable assumption and it is wrong. Java security patches — the fixes delivered through Oracle's quarterly Critical Patch Update cycle — are available to a properly run enterprise without an Oracle subscription. What requires a licence is using Oracle's specific JDK build in certain circumstances. The patches themselves are not gated behind a payment. This guide draws that line precisely, so an enterprise can stay fully patched without paying for permission it does not need.

The question behind the question

"Can I get Java Critical Patch Updates without a license?" is really two questions wearing one coat. The first is technical: can I keep my Java runtime patched against known vulnerabilities without an Oracle contract? The answer is an unambiguous yes. The second is about Oracle specifically: can I keep applying patches to Oracle's JDK build without a subscription? The answer there is more nuanced and depends on the version and how it is used.

The conflation of those two questions is what Oracle's commercial position quietly benefits from. An enterprise that does not separate them assumes the only way to stay secure is to pay Oracle. Separate them, and the path to a fully patched estate at no licence cost becomes obvious.

What a Java Critical Patch Update is

A Java Critical Patch Update, usually shortened to CPU, is the bundle of security fixes Oracle releases for Java on a fixed quarterly schedule — historically in January, April, July and October. Each CPU addresses vulnerabilities discovered in the Java platform since the previous cycle, and the security advisory that accompanies it lists the issues fixed and their severity ratings.

The critical point for licensing is where those fixes come from. Java is an open-source platform; its reference implementation is OpenJDK. Security fixes are developed in the open-source OpenJDK project and flow into the update releases of the relevant OpenJDK version. Oracle builds its own JDK from that OpenJDK source — and so does every other distribution vendor. The security content of a quarterly update is therefore, in substance, OpenJDK content. It is not proprietary to Oracle's build. That is why the same fixes appear in Eclipse Temurin, Amazon Corretto, Azul Zulu and the rest, on the same quarterly cadence. Our deeper OpenJDK versus Oracle JDK comparison covers this relationship in full.

CPUs and the Oracle JDK licence

Where the licence does bite is on Oracle's own JDK build for certain versions. For older Java SE versions that have passed their public free-update date, Oracle delivers the quarterly patched builds under terms that, for commercial production use, require a paid Java SE subscription. In practice this means: if you are running Oracle's JDK 8 or JDK 11 build in production and pulling Oracle's patched releases, Oracle's position is that you need a subscription. The patches exist; Oracle's licensed delivery of them, for those versions and that use, is the chargeable part.

This is the narrow, real licensing fact behind the broad, misleading impression. It is not "Java patches cost money." It is "Oracle's build of certain post-free-update versions, used commercially, requires a subscription — and the patched releases come with it." The distinction matters because the moment you stop using Oracle's build for those versions, the subscription requirement disappears while the patches remain available to you from another source.

The free NFTC window

There is also a route to Oracle's own JDK with free patches: the No-Fee Terms and Conditions. Since Java 17, Oracle has released the current JDK versions under the NFTC licence, which permits free production use — including free quarterly updates — for a defined period. The pattern is that each release receives free Oracle updates until roughly a year after the next long-term-support version arrives, after which it ages out and continued patched use of Oracle's build requires a subscription.

So within the NFTC window, you genuinely can run Oracle's JDK and receive its Critical Patch Updates at no cost. The catch is the window. NFTC is free until it is not, and an estate that stands still on an NFTC version will eventually find that version out of the free window — at which point either it migrates to the next version, moves to a free OpenJDK build, or starts owing Oracle. Treating NFTC as a permanent free ride is the most common way enterprises drift into unintended exposure. Our comparison of BCL, OTN and NFTC sets out exactly how the windows work.

CPUs on free OpenJDK builds

The clean, durable answer to "Java patches without a licence" is a free OpenJDK distribution. Builds such as Eclipse Temurin, Amazon Corretto, Azul Zulu, the Microsoft build and others take the same OpenJDK security fixes and ship them, for the supported LTS versions, on the same quarterly cadence — at no licence cost and with no subscription, for production use.

This is not a degraded form of patching. For the LTS versions these distributions support, you receive the quarterly security content that addresses the same vulnerabilities as Oracle's CPU. The fixes originate in the same OpenJDK project. An estate standardised on a mainstream free distribution stays fully current against known Java vulnerabilities without any payment to anyone.

The one scenario where money may re-enter is a workload stuck on a very old Java version past the free community support horizon. There, an optional commercial support contract from an OpenJDK vendor can extend patched delivery — but that is an optional, usage-priced service, not a licence, and it is far cheaper than a headcount-priced Oracle subscription. The better long-term answer for such workloads is usually to migrate them to a current version.

The patching trap to avoid

There is a genuine danger here, and it is not the licence — it is the gap. The trap looks like this: an enterprise hears that Oracle's JDK now needs a subscription, decides not to pay, and then simply stops patching — leaving Oracle's old JDK build in place, unpatched, because applying Oracle's new patched build would (correctly) imply a subscription. That is the worst of every world: the security exposure of an unpatched runtime, with the licensing exposure of Oracle's JDK still sitting in the estate.

Running an unpatched Java runtime to avoid a licence is never the right move. Known Java vulnerabilities are actively exploited, and an out-of-date JDK is a real attack surface — a subject we cover in our guide to the security risks of running unlicensed Java. The correct response to "we will not pay Oracle" is not "we will stop patching" — it is "we will move to a free OpenJDK build and keep patching from there." The decision to leave Oracle's subscription and the decision to stay patched are not in tension; they are the same project.

Staying fully patched, licence-free

Pulling it together, here is how an enterprise stays current on Java security without an Oracle subscription:

• Know what you run. Establish, through a compliance assessment, every place Oracle's JDK and other Java builds run, and on which versions. You cannot patch — or de-risk — what you have not mapped.
• Migrate Oracle JDK to a free OpenJDK build. For the workloads on Oracle's JDK, move to a mainstream free distribution. This removes both the subscription requirement and the patching dilemma in one step. Our migration guide covers execution.
• Adopt the quarterly cadence. Build the four annual CPU dates into your patch process, so the free distribution's updates are applied promptly across the estate.
• Handle legacy versions deliberately. For workloads on Java versions past free community support, either migrate them to a current version or take an optional paid extended-support contract — a service cost, not a licence.

Across more than 340 Java licensing engagements, enterprises that combined migration to free OpenJDK with a disciplined quarterly patch cadence stayed fully current on Java security while removing the subscription entirely — contributing to a 68% average reduction in audit claims and more than $180M in total client savings. Security and licence-freedom are not a trade-off. Done properly, you get both.

Frequently asked questions

This article is general information on Oracle Java licensing and Java security patching, not legal or security advice. Oracle's update terms, free-update dates and NFTC windows are determined by Oracle and change over time; verify current details before acting. Consult a qualified independent Java licensing specialist on your specific estate and agreements.