Oracle Java free vs paid, build by build. What needs a subscription in 2026.

Free or paid is decided by the license file on a specific build from a specific distributor. Oracle JDK 8 above 8u202, all of JDK 11, JDK 17 above 17.0.12 and JDK 21 updates from October 2026 need a subscription. OpenJDK builds never do.

Why is "is Java free" the wrong question to ask?

Because Java is a specification, and a specification is not something you license. What runs on your servers is a build, produced by a distributor and shipped with a license file. Free or paid is a property of that file.

Three facts settle the status of any single installation, and they have to be answered in this order.

1. Who built the binary. Oracle, or one of a dozen distributors shipping OpenJDK. This decides whether Oracle has any commercial interest in the installation at all.
2. Which release and which build. The answer is 17.0.12 or 17.0.13, never just "Java 17", because adjacent builds can sit on opposite sides of the line.
3. Which license text shipped with it. Read the file in the installation directory. What someone remembers about a download page from years ago is not evidence.

Most inventories we review record the second fact in shortened form and skip the other two. The two missing facts are the ones that decide what you owe.

The four license texts you need to tell apart

Almost every Java binary in an enterprise carries one of four license texts. Two of them allow free production use, and only one of those two has no clock attached.

A Java governance policy can be one page if it starts from this table. Allow the GPL builds by default, treat NFTC builds as free with an expiry date, and route anything under the OTN terms through an approval.

How do you read the license off a Java binary you already have?

Open the installation directory and read the license file. Every mainstream JDK ships its license as a plain file in the root of the installation, and that file is the controlling document for that copy of the runtime.

What to record for every installation

• The license file in the installation root. It names the Oracle No Fee Terms and Conditions, the Oracle Technology Network agreement, or the GNU General Public License version 2 with the Classpath Exception. That name is your answer.
• The release file in the same directory. It carries the implementor and the full version string, so you record the build number instead of the marketing version.
• The full version output. Run the runtime with the version flag and keep every line of the output.
• The origin. Which package repository, internal mirror or vendor installer served the files, and who approved it.

Keep all four in one row per host. A version number on its own proves nothing, and an inventory built only from version numbers will not survive the first licensing conversation with Oracle.

Commands and files that show what you actually run

Each of these works on a standard installation and takes seconds per host. Script them once and run them everywhere, container images included.

• java -version. The second line names the runtime. Oracle JDK prints "Java(TM) SE Runtime Environment", while OpenJDK builds print "OpenJDK Runtime Environment", usually followed by the distributor's build name such as Temurin or Corretto.
• java -XshowSettings:properties -version. Lists java.vendor, java.vm.vendor, java.home and java.runtime.version, which gives you the vendor claim, the full build and the installation path in one output.
• The release file. A plain text file in the JDK root holding JAVA_VERSION and, on most current builds, IMPLEMENTOR. Older JDK 8 builds may lack the implementor field, so rely on the version output there.
• Package managers. rpm -qa or dpkg -l on Linux, and the installed programs list on Windows, show what arrived through packaging. Runtimes unpacked from an archive will not appear, so a file level scan is still required.
• Container images. Run java -version inside each image in your registry, because the runtime baked into an image is what ships to every node that pulls it.

Why the java.vendor property misleads scanners

The java.vendor property is not a license signal. Several free builds report Oracle Corporation because they come from the OpenJDK codebase that Oracle leads, including the OpenJDK builds Oracle itself publishes at jdk.java.net. A scanner keyed on that property produces a long list of false findings.

Treat the vendor property as a hint and the license file as the fact. A discovery tool that cannot read files inside the installation directory cannot answer the licensing question, whatever its dashboard says.

The mechanics of a file level sweep are in the discovery gap and shadow install guide, and the visible differences between the two build types are listed in our guide to telling Oracle JDK from OpenJDK.

Which runtimes are never an Oracle exposure?

Every build below is derived from OpenJDK and licensed under the GPL with the Classpath Exception, free for commercial production use. Finding them is good news, and they should come off any exposure list before anyone starts pricing.

• Eclipse Temurin from the Adoptium project, including the older AdoptOpenJDK builds.
• Amazon Corretto, Microsoft Build of OpenJDK, Red Hat build of OpenJDK, Azul Zulu Community, BellSoft Liberica, SapMachine and Alibaba Dragonwell.
• IBM Semeru, which pairs the OpenJDK class libraries with the Eclipse OpenJ9 virtual machine.
• The JetBrains Runtime. It ships inside JetBrains tools such as IntelliJ IDEA and it is an OpenJDK build. It turns up on flagged lists constantly because its directory name and vendor string look unfamiliar.
• OpenJDK builds published by Oracle under the open source license. They are a different artifact from the Oracle JDK even though the same company produced both.

That last item causes the most confusion, so be precise about it. Oracle publishes a GPL licensed OpenJDK build and a commercially licensed Oracle JDK with the same version numbers, and only the license file tells them apart.

Which Oracle JDK builds are free and which are paid?

Oracle JDK 8 is free through 8u202, Oracle JDK 11 is never free in production, and Oracle JDK 17 is free through 17.0.12. Oracle JDK 21 is free through 21.0.12.1, and JDK 25 stays free into September 2028. Read the map by build, because each boundary sits between two adjacent build numbers.

Oracle publishes the dates in its Java SE support roadmap and the free terms in the No Fee Terms and Conditions. Check both against your own build inventory. Oracle revises the roadmap as releases move, and any summary, this one included, can fall behind it.

Why does Oracle JDK 8 still produce the most findings?

Because the boundary sits in the middle of a release that half the enterprise world still runs, and crossing it was the responsible thing to do. Oracle JDK 8 update 202 was the last free build. Update 211 and everything after it requires a subscription for commercial use.

The cliff between 8u202 and 8u211

Nothing changed in the software that an operations team would notice. The license changed with the April 16, 2019 update. Any organization with a working patch process moved past 8u202 during 2019 and, without a subscription, took on an exposure that has grown every year since.

This is the highest yield finding in Oracle's Java audit work. It is widely deployed, provable from a build string, and almost never documented on the customer side. If Oracle JDK 8 above 8u202 runs in your production environment, treat it as a live issue with a named owner.

The commercial features that made free JDK 8 chargeable

This is the part almost no inventory checks. Oracle JDK 8 builds under the old Binary Code License were free for general purpose computing, but a set of commercial features sat behind a JVM option and required a paid Java SE Advanced or Java SE Suite entitlement.

Flight Recorder, the Java Usage Tracker, the MSI Enterprise JRE Installer and the Advanced Management Console all sat behind that gate. A profiling exercise that switched the option on in production, on a build everyone believed was free, is a real finding in an otherwise clean environment.

Before you conclude that your BCL era builds are clean, search these places for the text CommercialFeatures and FlightRecorder, which catches the JVM options that switched the features on.

• Environment variables that inject JVM options, such as JAVA_TOOL_OPTIONS and _JAVA_OPTIONS.
• Application server start scripts and their configuration files.
• Container entrypoints and Dockerfiles.
• systemd unit files and Windows service wrappers.
• Profiling runbooks written before 2019, which often told engineers to add the option during performance incidents.

What that paid entitlement covered, if you hold one, is set out in the guide to what a pre 2023 entitlement covers.

Why is Oracle JDK 11 the easiest Java exposure to miss?

Because there is no build number to remember. Every Oracle JDK 11 build shipped under the OTN terms, so the line has no free production build and no cliff for a scanner to detect.

What the development carve out permits

The OTN terms permit developing, testing, prototyping and demonstrating applications, plus personal use. They do not permit business, commercial or production data processing.

That carve out is why the binary spreads. A developer downloads it lawfully, it goes into a base image, the image is promoted, and a permitted use has become a prohibited one without any download event to mark the moment.

Where development ends and production begins

• Build and release infrastructure. A build agent producing artifacts that ship to production is an open licensing question. Take a view and write it down.
• Performance and user acceptance environments that process real business data are the weakest place to argue non production use.
• Disaster recovery and standby systems exist to run the business. Treat them as production for licensing purposes.
• Demonstration environments shown to customers sit close to the line once they carry real data.
• Container base images are the fastest path from a laptop to a production cluster, and the one with the least review.

Record the classification per environment and have the application owner sign it. The detailed boundary questions are covered in our guide to non production Java licensing.

What happened to the free window on JDK 17, 21 and 25?

It closed on JDK 17 in September 2024 and on JDK 21 in September 2026, and it is open on JDK 25 into September 2028. The No Fee Terms give a release free production use, commercial organizations included, for a period tied to the arrival of the next long term support release.

How the clock is set, and why it repeats

Oracle's published approach ends the free period roughly one year after the following long term support release becomes available. JDK 21 arrived in September 2023, so JDK 17 lost free updates in September 2024. JDK 25 arrived in September 2025, so JDK 21 lost them in September 2026.

Each release stays free long enough to become your standard and then stops being free while you still run it. That is why the JDK 25 free window needs a decision owner now, two years before it ends.

Where the JDK 21 line sits in September 2026

The last JDK 21 build under the No Fee Terms is 21.0.12.1, released on August 18, 2026, after the quarterly 21.0.12 update of July 21, 2026. Oracle plans to ship JDK 21 updates from the October 20, 2026 patch release onward under the OTN terms. The options for pinned systems are in our JDK 21 update guide.

Oracle has also started releasing extra security updates between the quarterly ones, on the third Tuesday of the month. The first was 21.0.12.1 itself, and the next is planned for November 17, 2026. A pipeline that takes every Oracle update will therefore install more paid builds, more often.

The patch that changes your license without changing your version

The crossing is almost always invisible. You run JDK 17, you stay on JDK 17, and a quarterly security update takes you from 17.0.12 to 17.0.13. The version in your CMDB stays the same while the license changes.

Build the control at the point of change. A patch that takes an Oracle JDK across a published boundary should need the same approval as a purchase, because in effect it is one.

What does the No Fee Terms fine print actually say?

Two points matter more than the rest: the license attaches to the build you obtained, and it does not rescue releases you received under a paid agreement. Both surprise people who assumed free meant unconditional.

The license attaches to the build, not to the calendar

A build you obtained while the free window was open remains free terms software. JDK 17.0.12 does not become chargeable because the window later closed, and Oracle's FAQ says you may keep using a release under the license you downloaded it under.

What creates exposure is installing a build published after the window closed. That makes the remedy a patching decision, and it removes any reason to panic about builds you already run.

Prior paid versions, redistribution, support and tooling

• Prior paid versions. Oracle's published position is that the free terms do not apply to a release you previously received under a paid agreement. If a subscription covered that release, do not assume the free terms rescue you retrospectively.
• Redistribution. The free terms allow redistribution on conditions, including keeping the license intact and charging no fee for it. If you ship software to customers with a runtime inside, read the conditions before assuming the right transfers. Our embedded and OEM Java guide covers that case.
• No support. Free terms software carries no Oracle support and no service request rights. A free license says nothing about who fixes a production incident at night.
• Management tooling. Oracle's Java Management Service is licensed separately and is not available under the free terms, so using it is not part of a free position.

Oracle's own JDK licensing FAQ is the primary source for these points and changes as releases move. Read the version current on the day you decide, and file a dated copy with your decision record.

Which Java builds end the licensing problem permanently?

Any mainstream OpenJDK build under GPL version 2 with the Classpath Exception. That license permits commercial production use, charges no fee and has no expiry, which removes both the build number cliff and the calendar.

What the Classpath Exception does for you

It is the clause that makes the license safe for commercial software. Without it, linking your application against the class libraries would raise questions about obligations on your own code. With it, running and linking against the runtime imposes no obligations on your application.

The text is short and worth reading once, on the OpenJDK legal page. It is the most useful licensing document in the Java world, and few people in procurement have read it.

How to choose between the free distributions

• Update cadence. Confirm the distributor ships quarterly security updates for every release line you run, and how soon after the upstream release they appear.
• Long term support coverage. Check how many years the distributor commits to for each release line, because the commitments differ.
• Certification. Ask whether the build passes the Java Technology Compatibility Kit, which most mainstream distributions do.
• Platform coverage. Architectures, container images and installer formats for the platforms you actually run.
• Commercial support, if you want it. Several distributors sell optional support on top of a free binary, which is a different commercial shape from a per employee subscription.

The Adoptium project publishes its build and certification process at adoptium.net, which is worth reading before you shortlist anything. A wider comparison of options and their migration profiles sits in the guide to Java options beyond the Oracle subscription, and a head to head of the three most common picks in our Corretto, Temurin and Zulu comparison.

What the migration involves

For most workloads it is a runtime swap with no code changes. The class libraries come from the same upstream codebase, so an application built for a given release generally runs unchanged on another build of that release.

Plan for the exceptions: anything that depends on Oracle specific features, older desktop deployment technology such as Java Web Start, and vendor supported applications where the vendor certifies one runtime. Get the certification question answered early, because it drives the schedule. In containers the swap happens once, in the base image, as set out in our Docker base image guide.

What does staying on a paid Oracle JDK build cost?

It costs a Java SE Universal Subscription priced on your total employee count. Since January 2023 that has been the only paid Java SE product Oracle sells, and it counts your whole workforce, including staff who never touch Java.

The published price ladder

The ladder opens at $15.00 per employee per month in the smallest band and falls to $5.25 across the 40,000 to 49,999 band. Pricing for larger organizations is not published, and support comes with the subscription.

The band by band arithmetic is in the employee tier pricing table, and the metric itself in the employee metric guide.

Worked example: what a few paid builds cost at two company sizes

Say an inventory finds Oracle JDK 17.0.13 on one reporting server at Company A, a hypothetical business with 600 employees. Company B, also hypothetical, has 42,000 employees and 30 servers running Oracle JDK 8 above 8u202. Neither holds a Java subscription.

The last row is the one to show your CFO. At list price, Company A pays $108,000 a year to keep one server on an Oracle build, and moving that runtime to a free distribution removes the whole line. Company B's quote would be the same with 3 paid builds or 3,000.

What have we seen in Oracle Java version and license reviews in 2024 and 2025?

In the 30 to 40 Java license reviews Fredrik Filipsson worked through in 2024 and 2025, no client could initially state, per host, which license text governed the installed runtime. Most could state a version, and a version alone answers none of the questions on this page.

• The first exposure list is mostly wrong. Between 45 and 70 percent of installations first flagged as Oracle exposure changed category once someone read the license file inside the JDK.
• One build number dominates JDK 8. 8u202 sits behind most JDK 8 findings, because every Oracle JDK 8 installation patched since April 2019 sits above it.
• Four license texts at once. A typical company holds builds under all four texts at the same time.
• Patching teams crossed the line in good faith. They moved builds forward for sound security reasons, no one had told them a build number was also a commercial boundary, and no control existed to flag the crossing.

You do not license Java. You license a build, from a distributor, under a license text, and the two facts an inventory usually leaves out are the expensive ones.

Why we advise against chasing the free line version by version

The usual remedy is to track Oracle's free line release by release and roll back a patch whenever a build crosses it. We disagree, because it accepts the axis Oracle controls. Oracle sets those boundaries and shifts them on a published schedule, so every release you standardize on will stop being free while still in production.

A version led policy therefore guarantees the same conversation about every two years. The durable choice is the distributor: pick a build whose license has no end date and make it the default in base images and package repositories.

Rolling back a patch buys a few months of license comfort at the price of a known vulnerable runtime, and it does nothing about the period the paid build already ran.

What will Oracle's Java team say about free builds, and how should you reply?

Expect the conversation to start from the widest reading of your inventory. These are lines buyers commonly hear in Java discussions, with replies that keep the discussion on the license file and the build number.

Before any tooling goes near Oracle, read our note on the JMS self report trap. What you volunteer early is hard to take back later.

What does each Java inventory finding mean, and what should you do this week?

Sort every finding into one of the rows below, and keep the evidence for each classification next to it: the license file name, the build string and the date the build arrived.

Common mistakes when classifying Java builds

• Pricing before clearing. A raw scan sent to finance, or worse to Oracle, turns false positives into a starting number for the vendor.
• Recording "Java 17" without the build. 17.0.12 and 17.0.13 need different answers, and a CMDB that stores only the release cannot give them.
• Missing bundled runtimes. Many applications ship their own JDK inside the installation folder. Its license is whatever that vendor's build carries, and the application vendor's own contract may already cover it, as explained in our guide to embedded JDKs in third party applications.
• Leaving desktops out of the count. Windows PCs with the Oracle JRE and its auto updater switched on were offered builds above 8u202 under the new license, and every user who accepted moved that PC onto the OTN terms. A server only inventory misses all of them.

What to do next

1. This week: inventory to the build number and the license file. Capture distributor, full build string, license file name and installation path for every runtime, container images and bundled JDKs included.
2. Clear the false positives first. Remove every OpenJDK derived build from the exposure list before you price anything. This is usually the largest single reduction, and it costs nothing.
3. Flag the three paid conditions. Oracle JDK 8 above 8u202, Oracle JDK 11 outside development, and Oracle JDK 17 above 17.0.12. Attach an owner and a date to each.
4. Search for the commercial features options across start scripts, container entrypoints and application server configuration, including on builds you believe are free.
5. Before October 20, 2026, give every Oracle JDK 21 system a target. Move it to Oracle JDK 25 under the free terms or to a free distribution at the current patch level, and diarize September 2028 for JDK 25 with a decision owner named now.
6. Pick one free distribution and make it the default in base images, package repositories and build templates. The default image is what holds over time; a policy document on its own does not.
7. Put a gate on the patch pipeline so an Oracle JDK crossing a published boundary triggers an approval instead of an automatic deployment.
8. Settle the headcount before any pricing talk. If contractors and consultants sit inside your count, resolve that number first using the analysis of who counts as an employee. Governance for the whole Java footprint, including download control, sits in the Java knowledge hub.

Frequently asked questions