Which Java Versions Are Free and Which Trigger a Bill

Java is not free or paid. A specific binary, from a specific distributor, at a specific build number, carries a specific license text, and that text is the only thing that decides whether you owe Oracle money. This page maps that text line by line, and names the runtimes that are never an Oracle exposure.

Why is "is Java free" the wrong question?

Because "Java" is a specification, not a product you can license. What you actually run is a build, produced by a distributor, shipped with a license file. Free or paid is a property of that file.

Three facts settle it, 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 at all.
2. Which release and build. Not "Java 17" but 17.0.12 or 17.0.13. Adjacent builds can sit on opposite sides of the line.
3. Which license text shipped with it. The file in the installation directory, not what someone remembers about the download page.

The four license texts you have to be able to tell apart

Two of those four are free for production. Only one of the two has no clock attached to it. That single sentence is most of what a Java governance policy needs to say.

You do not license Java. You license a build, from a distributor, under a license text. Two of those three facts are usually unknown in an enterprise estate, and the unknown ones are the expensive ones.

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

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

What to look at, in order

• The license file in the installation root. It will name 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 can record the build number rather than the marketing version.
• The full version output. Run the runtime with the version flag and capture the entire output, not the first line.
• The origin. Where the artefact came from, which package repository or internal mirror served it, and who approved it.

Record all four per host in the same row. A version number on its own is not evidence of anything, and an inventory built only from version numbers will not survive contact with a licensing conversation.

The vendor string that misleads everyone

The java.vendor property is not a license signal. Several free builds report Oracle Corporation because they descend from the OpenJDK codebase that Oracle leads, and a scanner keyed on that property will produce a long list of false findings.

Treat the vendor property as a hint and the license file as the fact. If your discovery tooling cannot read files inside the installation directory, it cannot answer the licensing question, whatever its dashboard says. The mechanics of a file level sweep are covered in the discovery gap and shadow install guide.

Runtimes that are not an Oracle exposure

Every one of the following is an OpenJDK derived build under GPL version 2 with the Classpath Exception, free for commercial production use. Finding them is good news, and they should be cleared out of 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, Alibaba Dragonwell.
• IBM Semeru, which pairs OpenJDK class libraries with the Eclipse OpenJ9 virtual machine.
• The JetBrains Runtime. It ships inside JetBrains tooling, it is an OpenJDK build, and it is not an Oracle licensing exposure. It appears on flagged lists constantly because the vendor string and the directory name look unfamiliar.
• OpenJDK builds published by Oracle itself under the open source license, which are a different artefact from the Oracle JDK even though the same organisation produced both.

That last one causes real confusion, so be precise about it. Oracle publishes both a GPL licensed OpenJDK build and a commercially licensed Oracle JDK. Same company, same version numbers, different license file.

Which Oracle branded builds are free and which are paid?

The map below covers the Oracle branded lines an enterprise is likely to hold. Read it by build, not by release, because the boundary always sits between two adjacent build numbers.

Oracle publishes the underlying dates in its Java SE support roadmap and the free terms themselves in the No Fee Terms and Conditions. Check both against your own build inventory rather than against a summary, including this one.

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 because 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 about the software changed in a way an operations team would notice. The license changed. Any organization with a functioning patch process moved past 8u202 during 2019 and, absent a subscription, acquired an exposure that grew quietly every year afterwards.

This is the highest yield finding in Oracle's Java work: widely deployed, trivially provable from a build string, and almost never documented on the customer side. If Oracle branded JDK 8 above 8u202 is in your production estate, treat it as live rather than theoretical.

The commercial features flag that made even free JDK 8 chargeable

Here is the part almost nobody 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 an unlock flag and required a paid Java SE Advanced or Suite entitlement.

Flight Recorder, Java Usage Tracker, the enterprise installer and the Advanced Management Console all lived behind that gate. A profiling exercise that switched on the unlock flag in production, on a build everyone believed was free, is a genuine finding on an otherwise clean estate.

Search your startup scripts, container entrypoints and application server configuration for the unlock flag before you conclude that your Binary Code License era estate is safe. 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 quietest exposure in the estate?

Because there is no build number to remember. Every Oracle branded JDK 11 build shipped under the Oracle Technology Network terms, so there is no free production door anywhere in the line and no cliff to detect.

What the development carve out actually permits

The Technology Network terms permit use for developing, testing, prototyping and demonstrating applications, and 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 is baked into a base image, the image is promoted, and a permitted use has silently become a prohibited one with no download event to mark the moment.

Where development ends and production begins

• Build and release infrastructure. A build agent producing artefacts that ship to production is a live question, not an obviously free one. Take a view and document it.
• Performance and user acceptance environments that process real business data are the weakest place to argue non production.
• 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.

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

It closed on 17, and it is open with an end date on 21 and 25. The No Fee Terms give a release free production use, including for commercial organizations, for a defined 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 ties the free period for a release to roughly one year after the following long term support release becomes available. JDK 17's period ended in September 2024. JDK 21's runs into September 2026. JDK 25's runs into September 2028.

This is a designed treadmill, not an accident. Each release is free long enough to become your standard and then stops being free while you are still running it.

The patch that changes your license without changing your version

The crossing is almost always invisible. You are on JDK 17, you stay on JDK 17, and a quarterly security update moves you from 17.0.12 to 17.0.13. The version in your CMDB is unchanged. The license is not.

Build the control at the point of change. A patch that moves an Oracle branded build across a published boundary should require the same approval as a purchase, because that is functionally what it is.

What is in the free terms fine print?

Two clauses matter more than the rest, and both surprise people who assumed free means 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 retroactively become chargeable because the window later closed.

What creates exposure is installing a build published after the window closed. This distinction is worth getting right, because it means the remediation is a patching decision rather than a panic about everything you already run.

Prior paid versions and redistribution

• 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 you had a subscription covering that release, do not assume the free terms rescue you retrospectively.
• Redistribution. The free terms allow redistribution on conditions, including keeping the license intact. If you ship software to customers with a runtime inside it, read the conditions properly rather than assuming the right transfers.
• No support. Free terms software carries no Oracle support and no service request rights. Free is a license position, not an operating model.
• Management tooling. Oracle's Java management service is licensed separately from 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 is updated as releases move. Read the version current on the day you decide, and keep a dated copy with your decision record.

Where the common advice on free Java versions is wrong

We disagree with the standard remedy, which is to chase the free line by version and roll back when you cross it. Version chasing accepts the wrong axis. Oracle sets those boundaries, moves them on a published schedule, and every release you standardize on will eventually stop being free while it is still in production, which means a version led policy guarantees you will have this conversation again in about two years. The durable axis is distributor. Choose a build whose license has no end date, make it the default in your base images and package repositories, and the question stops recurring. Rolling back a patch, by contrast, buys a few months of licence comfort at the price of a known vulnerable runtime, and it does nothing about the period the paid build was already running.

Which builds end the problem permanently?

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

What the Classpath Exception actually 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 your own code. With it, running and linking against the runtime does not impose obligations on your application.

The text is short and worth reading once, at the OpenJDK legal page. It is the single most useful licensing document in the Java ecosystem and almost nobody in procurement has seen it.

Choosing between the free distributions

• Update cadence. Confirm the distributor ships quarterly security updates for the release lines you run, and how quickly after the upstream drop.
• Long term support coverage. Check how many years the distributor commits to for each release line, because they 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 openly at adoptium.net, which is worth reading before you shortlist anything. A wider comparison of the options and their migration profiles sits in the guide to Java options beyond the Oracle subscription.

What the migration actually involves

For the overwhelming majority of workloads it is a runtime swap, not a rewrite. The class libraries are the same upstream codebase, so applications built against a given release generally run unchanged on another build of that release.

Plan for the exceptions rather than the norm: anything depending on features that were Oracle specific, older desktop deployment technologies, and vendor supported applications where the vendor certifies a specific runtime. Get the vendor certification question answered early, because it drives the schedule.

What does staying on a paid Oracle build actually cost?

Whatever your total headcount costs, not whatever your Java footprint costs. Since January 2023 the product Oracle sells for a paid position is the employee based subscription, and the count is your workforce rather than your users.

The published ladder, and what sits above it

The published ladder opens at $15.00 a month for each head in the smallest band and bottoms out at $5.25 across the 40,000 to 49,999 band. Anything larger is not published, and support comes with the subscription.

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

The consequence for this page is simple. One unlicensed Oracle branded build anywhere in production does not create a small bill sized to that build. It creates a conversation sized to your entire organization, which is why a handful of developers can produce a headcount sized invoice and why the forecast increase is worth modelling before anyone talks to Oracle.

8u202

The build number behind most JDK 8 findings

45–70%

Of flagged installs reclassified after reading the license

4

License texts a typical estate holds at once

Source: Redress Compliance advisory engagement file, 2024 to 2025, alongside Oracle's published release notes.

The free line is knowable to the build number. Money is lost not because the rules are hidden but because a patch pipeline crosses a commercial boundary that no control was ever built to detect.

What should a buyer do next?

1. Inventory to the build number and the license file. Version alone is not an answer. Capture distributor, full build string, license file name and installation path for every runtime.
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 branded JDK 8 above 8u202, any Oracle branded JDK 11 outside development, and Oracle branded JDK 17 above 17.0.12. Attach an owner and a date to each.
4. Search for the commercial features unlock flag across startup scripts, container entrypoints and application server configuration, including on builds you believe are free.
5. Diarize the two open windows. September 2026 for JDK 21 and September 2028 for JDK 25, with a decision owner named against each date now.
6. Pick one free distribution and make it the default in base images, package repositories and build templates. Standardization is the control; policy documents are not.
7. Put a gate on the patch pipeline so an Oracle branded build crossing a published boundary triggers an approval rather than an automatic deployment.
8. Do not roll patches backwards to reclaim free status. It creates a security exposure, and it does not undo the period the paid build was in service.

If contractors and consultants sit inside your headcount, resolve that number before any pricing conversation begins, using the analysis of who counts as an employee. Governance for the whole estate, including download control, sits in the Oracle Java advisory hub.

Related advisory: the full topic guide.

Frequently asked questions

Is Oracle JDK 8 free to use in production?

Only up to build 8u202, released January 2019. From 8u211 the line moved to the Oracle Technology Network terms, which do not permit commercial production use without a subscription. Most enterprises patched past 8u202 during 2019 for sound security reasons and acquired the exposure at that moment.

Why does Oracle JDK 11 have no free production option?

Because every build in the line shipped under the Technology Network terms. Those terms permit development, testing, prototyping, demonstration and personal use, and exclude business and production data processing. There is no build number that changes this, which is what makes the line so easy to miss.

Do I owe anything for Oracle JDK 17.0.12 that I installed while it was free?

On the ordinary reading of the free terms, no. The license attached to the build you obtained while the window was open, and a later closure does not reach back to it. The exposure comes from installing 17.0.13 or later without an entitlement, so check what your patch pipeline has deployed since October 2024.

Is OpenJDK really free forever?

Yes, under GPL version 2 with the Classpath Exception, which permits commercial production use with no fee and no expiry. What you buy separately, if you want it, is support. Distributors such as Eclipse Temurin, Amazon Corretto, Azul Zulu, Microsoft, Red Hat, BellSoft and IBM all ship builds under that license.

Is the JetBrains Runtime an Oracle licensing risk?

No. The JetBrains Runtime is an OpenJDK build shipped with JetBrains tooling, and it carries the open source license rather than an Oracle one. It appears on flagged inventory lists regularly because of how it is packaged, and it should be cleared off the exposure list rather than counted.

Does the free terms license cover Java 8, 11 or 17 today?

No for 8 and 11, and only up to 17.0.12 for 17. The free terms began with JDK 17 in 2021 and were never retroactive, so no build of Oracle JDK 8 or 11 has ever been covered by them. Oracle's licensing FAQ is the primary source if you need to evidence this internally.

Does running Java in a container or a virtual machine change the license?

No. The license follows the binary inside the image, not the platform hosting it. A container image with an Oracle branded paid build inside it carries that license everywhere it runs, which is precisely why base image standardization is the most effective control available.

Can we just downgrade to a free build if we find a paid one?

You can, and it is usually the wrong move. Rolling back reintroduces known vulnerabilities, and it does not remove the period during which the paid build was running in production. Migrating that workload to a free distribution at the current patch level addresses both the license and the security position at once.