The JDK 21 free window shuts on 16 September 2026, and the patch your security team must apply is what starts the bill

Java the language is free, OpenJDK is free, and every mainstream non Oracle build is free in production with no clock attached. What costs money is one vendor's build outside one licence window, and the price is set against your entire headcount rather than your Java usage.

Prepared by Redress Compliance · August 16, 2026 · Oracle advisory. 30 to 40 Java licensing reviews advised, 2024 to 2025.

Every row has a date because every row changed on one. The distinction is the licence file that shipped with the binary, not the version number on the box.

• Nothing breaks, and that is the shape of the trap. No build stops working, no licence check fires, and nothing on your estate changes on 17 September.
• The exposure starts at the next patch. The October critical patch update is the first paid build, and applying it is what converts a free install into a licensable one.
• You have two lawful positions afterwards: run the July 2026 build unpatched, or stop running Oracle's build. Only one of those survives a security review.
• Oracle does not need a purchase on the day the window shuts. It needs your security team to apply the next patch, which they will, because that is their job.
• The same mechanism already fired twice. The most common single finding in our reviews was a Java 8 install patched past 8u202, usually by a security team acting on a vulnerability ticket, and Java 17 repeated it after 17.0.12.
• The migrate before the date option has already closed. A typical move to a non Oracle build takes 3 to 9 months, so an estate starting now cannot complete before 16 September. The live choice is narrower than it was.
• Put 16 September 2026 in the change calendar as a hard gate for any Oracle JDK 21 estate, and decide now which side of it you intend to be on.

The standard advice is to stay inside the No Fee Terms window and simply upgrade to each new long term support release as it lands, keeping Oracle's build free forever. We disagree, and the reason is not that the grant is fake. It is entirely real. The problem is that it hands your upgrade calendar to a supplier, and across 30 to 40 Java reviews advised in 2024 and 2025, not one client managed to move an entire estate inside a window on Oracle's schedule, because the window is set by Oracle and your change freeze calendar is not.

What happens instead follows a consistent shape. Ninety percent of the estate moves, the last ten percent slips past the date for ordinary reasons, a vendor certification, a frozen platform, a team with other priorities, and then someone applies a patch. That patch is the trigger, and it is applied by the part of the organisation least likely to be watching licence terms and most likely to be acting correctly. In our reviews the single most common finding was a Java 8 install patched past 8u202 by a well meaning security team closing a vulnerability ticket. The control that protects the business is the control that creates the bill.

The asymmetry that follows is what makes this different from an ordinary licensing slip. Because the subscription is priced per employee rather than per install, one straggler prices the whole workforce. Isolating a stubborn application on an old build therefore buys time rather than money: the workload is contained, the metric is not. That is also why teams who believed they were covered by the No Fee Terms were frequently exposed anyway, running an older release that had already left its window because nobody owned the window as a calendar item rather than as a piece of technical trivia.

One consequence of the calendar deserves stating plainly for anyone reading this close to the date. A typical migration to a non Oracle build takes 3 to 9 months, which means an estate that has not already started cannot finish before 16 September 2026. The option to be clean by the deadline is no longer on the table. What remains is a choice between freezing at the July 2026 build and accepting an unpatched runtime for the duration of a migration that now runs past the date, or budgeting for the subscription over that period and treating it as the cost of a late start. Both are defensible. Neither is what a plan made a year earlier would have produced, and the difference between them is the price of having treated the window as a planning item rather than a calendar gate.

The evidential position deserves the same attention as the technical one. Not one client we reviewed had archived the licence text or the download page as it read on the day they downloaded, which is precisely the document that settles the argument later. Oracle's audit position keys off download and update records tied to your corporate domain, so if your security team has been diligently patching past the boundary builds, assume Oracle already knows. Read the LICENSE file inside the build you actually run, screenshot the current terms with a visible date, and record the install date and downloading account for every Oracle build in the estate. The metric change itself is covered in the Java licensing pillar, the audit sequence in Java audit defence, and the wider library in the Oracle practice.

• Personal use is defined by purpose, not by device. Oracle's own examples are homework and a personal tax return. Business accounting is not personal use, and a finance analyst using a Java based tool at home for company work is commercial use.
• A corporate laptop is commercial use in every practical scenario, because the laptop exists for company work. The personal use grant does not travel with the person.
• Development use covers building the thing, not running the business. Writing code, unit tests, prototypes, and demonstrations are covered.
• A build agent producing a production artifact is not covered, nor is a staging environment that mirrors production for release validation, nor a performance test environment that certifies a production change.
• The developer laptop is argued in every review. Oracle's position in the reviews we have sat in is that a machine which exists to support a production system is not covered. That argument is winnable in places and expensive to lose everywhere.
• Desktop installs are the least governed part of most estates and the easiest for Oracle to evidence, because the update check phones home.

Across roughly 30 to 40 Java licensing reviews advised, almost nobody had chosen to be exposed. They had simply lost track of which licence a given install arrived under:

Teams that believed they were covered by the No Fee Terms were often running an older release that had already left its window, because nobody owned the window as a calendar item. And not one client had archived the licence text or download page as it read on the day they downloaded, which is the evidence that settles the argument later.

Four fields decide each install, and version number is not one of them: distributor, read from the IMPLEMENTOR field in the release file; exact build number, because 8u202 against 8u211 and 17.0.12 against 17.0.13 are the boundaries; install date and installing account, which bounds a retroactive claim; and host purpose, because production, staging, build agent, and developer machine each carry a different argument. Capture all four before you remove anything, since deleting a binary destroys the evidence that limits how far back a claim can reach.

Watch the briefing · 4:43How to Negotiate the Oracle Java Employee Agreement: Honest Leverage in a Captive DealWhat leverage exists once the per employee metric prices your whole workforce.

Which Java versions are free in 2026?

OpenJDK and every mainstream build of it are free in production with no window, including Eclipse Temurin, Amazon Corretto, Azul Zulu, BellSoft Liberica, and the Microsoft Build of OpenJDK. Oracle's own JDK is free only inside the No Fee Terms window, which covers JDK 25 until September 2028 and JDK 21 until 16 September 2026.

What exactly happens on 16 September 2026?

JDK 21 leaves the No Fee Terms and the July 2026 quarterly update was the last free build. Nothing breaks and nothing on your estate changes. The exposure begins when someone applies the October critical patch update, because that build carries the paid terms.

Is Java 8 still free?

Only up to and including 8u202, released January 2019. Any build from 8u211 onward needs a subscription. A Java 8 install reports its version as 1.8 whether it is free or licensable, so only the exact build number answers the question.

Was Java 11 ever free from Oracle?

Not for production. It shipped under the Oracle Technology Network licence at general availability in September 2018, and that licence permits only personal and development use, both narrowly defined. Oracle builds of Java 11 were paid from day one.

What are the two lawful positions after a window closes?

Run the last free build unpatched, or stop running Oracle's build. Only one of those survives a security review, which is why the window closing is effectively a migration deadline rather than a purchasing decision.

Are Oracle's own free OpenJDK builds safe to use?

Yes, they carry no licence risk at all and are free for any purpose including commercial production. The catch is the update tail: Oracle stops publishing updates roughly six months after release, so an estate standardised on them must move release to release every six months to stay patched.

Does isolating one application solve the problem?

It buys time, not money. Because the subscription is priced per employee rather than per install, one isolated Oracle workload still prices your whole workforce. Isolation contains the technical risk and leaves the commercial exposure untouched.

Is Java on a corporate laptop personal use?

No. Personal use is defined by the purpose of the activity, not the ownership of the device. Oracle's own examples are homework and a personal tax return. A company issued laptop exists for company work, so the install is commercial use in every practical scenario.

How do we find which installs are not free?

By distributor and patch level, not by version number. Read the IMPLEMENTOR field in the release file at the top of JAVA_HOME, record the exact build number, the install date and installing account, and the purpose of the host. Capture all four before removing anything.

Why does Oracle contact us when it does?

Because it can see the downloads. Update requests and downloads tied to your corporate domain are matched against subscription records, and the soft outreach that follows opens an audit funnel. If your security team has been patching past the boundary builds, assume Oracle already knows.