Most enterprises can run free OpenJDK builds and pay nothing for the runtime, because the free and paid versions run the same Java. You pay only when a specific need justifies it, such as a contractual response time, coverage for an older release, indemnification, or a specialized engine, and even then only on the workloads that warrant it.
Free and paid OpenJDK distributions are built from the same upstream source and pass the same compatibility suite. A free build is not a lesser Java. It is the same runtime offered without a support contract attached. So the question is never whether free Java works. It is whether a given workload needs something that only a paid agreement provides. For most of an estate, the answer is no, and the runtime cost is zero.
Paid distributions sell four things, and it helps a buyer to separate them.
| What you pay for | What it gives you | When it is worth it |
|---|---|---|
| Support response | A contractual time to answer and fix | Critical workloads that cannot wait |
| Older release coverage | Patches for releases free builds have dropped | Legacy systems you cannot move yet |
| Indemnification | A vendor that stands behind license risk | Risk and legal teams that require it |
| Specialized engine | A tuned runtime for latency or throughput | A few performance critical systems |
Free builds from major vendors publish security updates on the quarterly schedule and offer multi year support windows on long term support releases. For the bulk of server side and container workloads, that is enough. The worry that free Java means no updates does not hold against a vendor publishing fixes on a published cadence. Start from the free baseline and make the paid option prove its case, workload by workload.
There are real cases for paid. A trading system measured in microseconds may justify a specialized low latency engine. A legacy application stuck on an older release may need a vendor still patching it. A regulated function may require indemnification in writing. The discipline is to attach the cost only to the named workloads that need it, not to spread a support contract across the whole estate the way the Oracle Java subscription spreads cost across the whole headcount. Our guide to how to choose a Java distribution gives the scoring framework, and our look at long term support across Java distributions shows how far free coverage actually runs.
The reason this matters is the shape of the Oracle Java Universal Subscription. Since January 2023 it has priced Java on a per employee metric, counting every full time and part time employee, every contractor, and every temporary worker, regardless of who uses Java, at list prices from 5.25 to 15.00 dollars per employee per month. A paid OpenJDK agreement, by contrast, attaches to the workloads that need it and is priced on support, not on your headcount. That is the difference between a cost you control and a cost that scales with hiring.
Run free OpenJDK as the default and pay only where a workload needs response time, older release coverage, indemnification, or a specialized engine. Price support to the workload, never to your headcount. That is how the runtime cost stays near zero for most of the estate.
Knowing when to pay and when not to is part of shrinking the Oracle Java envelope. For the licensing context and the per employee numbers, read our Oracle Java licensing guide for 2026.
Book a Strategy Call and we will map which workloads, if any, justify a paid runtime and which run free, so you pay only where it counts.
Book a Strategy Call Download the guideFixed fee or gainshare, both backed by our guarantee. We sit between you and Oracle and we never take vendor money.
Get a QuoteWeekly intelligence on Oracle Java licensing moves and the buyer side defenses that work.