Tomcat is free. The Java underneath it may not be

Apache Tomcat is one of the most widely deployed pieces of software in the enterprise — the default servlet container for a generation of Java web applications. It is also genuinely free: an Apache Software Foundation project, distributed under the Apache License 2.0, with no per-server, per-user or per-employee fee of any kind. That fact is true, and it is also the source of a costly misunderstanding. Because Tomcat is free, teams routinely assume the whole stack is free. But Tomcat does not run on its own — it runs on a Java runtime, and that runtime is a separate product with its own licence. The licensing risk in a Tomcat estate is never Tomcat. It is always the Java underneath it.

Two layers, two licences

The single most important idea in Tomcat licensing is that you are looking at two distinct layers of software, each governed by its own terms.

The first layer is Apache Tomcat itself — the servlet container, the application server software that receives HTTP requests and runs your web applications. The second layer is the Java runtime — the JDK or JRE that Tomcat is a Java program running inside. Tomcat is written in Java; it cannot start, let alone serve a request, without a JVM beneath it. These two layers are produced by different organisations, distributed separately, and licensed under completely different terms. Conflating them — treating “our Tomcat servers” as a single licensable thing — is the root error. The correct mental model is always: free application server, on top of a Java runtime whose licence must be checked separately.

Apache Tomcat’s own licence

Tomcat’s side of the story is short and reassuring. Apache Tomcat is released by the Apache Software Foundation under the Apache License 2.0 — a permissive open-source licence that allows free use, modification and distribution, in production and for commercial purposes, with no fee and no usage metric. There is no Tomcat “subscription,” no Tomcat audit, and no Tomcat compliance exposure. Running a thousand Tomcat instances costs exactly the same in licence terms as running one: nothing.

This is worth stating plainly because it is the part teams remember — and it is correct. Where the memory goes wrong is in extending “Tomcat is free” to “therefore the server is free.” Tomcat’s free licence covers Tomcat. It says nothing whatever about the Java runtime Tomcat sits on, which is a different product entirely. The Apache License protects the layer Apache produces; it cannot and does not reach down to the layer Oracle produces.

The JVM is where Java licensing lives

Underneath every Tomcat instance is a Java runtime, and that runtime is where every licensing question actually lives. The runtime can be one of several things, and the licensing consequences differ sharply:

• Oracle JDK — a recent release within its NFTC free-use window: free for now, but on a clock.
• Oracle JDK — Java 8 or 11, or a release past its NFTC window, used in production: this requires a paid Java SE Subscription.
• A free OpenJDK distribution — Eclipse Temurin, Amazon Corretto, Azul Zulu and others: free in production, with no Oracle requirement at all.

The same Tomcat configuration, the same web application, the same traffic — and the licensing outcome swings from “zero cost” to “organisation-wide subscription” based purely on which of these runtimes is installed. Tomcat is constant across all three; the JVM is the variable. Any assessment of a Tomcat estate that does not record the exact Java distribution and version on every node is not really an assessment at all.

The bundled-JDK trap

There is one pattern that turns this from a theoretical risk into a real one, and it deserves singling out: the bundled or co-installed Oracle JDK. Tomcat needs a Java runtime to be present, and over years of installs, the path of least resistance has often been to grab whatever JDK was easiest — and for a long time, that was Oracle’s. Installation guides, internal runbooks, automation scripts and golden images frequently default to downloading Oracle’s JDK to satisfy Tomcat’s requirement.

The result is an estate where Tomcat — free — is quietly running on Oracle JDK — chargeable — on dozens or hundreds of production servers, with no one having made a deliberate licensing decision at any point. Because Tomcat is the visible, named component, the Oracle JDK underneath it is effectively invisible to asset management. This is exactly the kind of accumulated, undecided exposure that an Oracle Java detection exercise surfaces — and it is entirely avoidable. The fix is not to stop using Tomcat; it is to be deliberate about the runtime Tomcat runs on.

Tomcat licensing scenarios

Putting the two layers together, here is how common Tomcat deployments actually stand.

Every row has the same Tomcat licence and the same free Tomcat. The entire spread of outcomes — from genuinely free to a subscription sized on your whole headcount — comes from the runtime column. And note the multiplier: under the employee metric, a single Tomcat server on chargeable Oracle JDK is enough to require a subscription covering every employee in the organisation.

Making a Tomcat estate free

The good news is that Tomcat estates are among the easiest Java deployments to make fully free, because Tomcat itself is completely indifferent to which compliant JDK it runs on. Tomcat is standard Java; it runs identically on Oracle JDK and on any OpenJDK distribution built from the same source.

That means migrating a Tomcat estate off chargeable Oracle Java is, in most cases, a low-risk operation. You are not changing the application server, the web applications, the configuration, or the architecture — you are swapping the JDK beneath an unchanged Tomcat for an OpenJDK build of the same major version. Functional behaviour is preserved by design, since both runtimes pass the same compatibility tests. For most Tomcat estates, replacing Oracle JDK with Temurin, Corretto or Zulu is a straightforward, well-trodden change — and it removes the Java licensing exposure entirely. It is one of the highest-value, lowest-effort moves available in Java cost management.

A structured approach

Bringing a Tomcat estate under control follows a clear sequence:

1. Inventory the runtime, not the container. For every Tomcat instance, record the exact Java distribution and version it runs on. The Tomcat version is almost irrelevant; the JDK is everything.
2. Flag the Oracle JDK instances. Separate Tomcat-on-OpenJDK (free) from Tomcat-on-Oracle-JDK. The latter is your exposure.
3. Classify the Oracle JDK instances. Determine which are within an NFTC free window and which are chargeable Java 8, 11, or past-window releases.
4. Plan the runtime swap. For chargeable instances, plan migration to an OpenJDK build of the same major version — a low-risk change Tomcat fully supports.
5. Standardise going forward. Fix the golden images, runbooks and automation so future Tomcat installs default to a free OpenJDK runtime, not Oracle’s.

Common mistakes

• “Tomcat is free, so we’re fine.” Tomcat is free. The Java runtime under it is a separate product. The two licences are unrelated.
• Inventorying Tomcat but not the JDK. Asset records that list “Tomcat 9” without the runtime miss the entire licensing exposure.
• Defaulting to Oracle JDK in install scripts. Automation that grabs Oracle’s JDK to satisfy Tomcat’s requirement seeds chargeable Java across the estate silently.
• Assuming a runtime swap is risky. Tomcat runs identically on any compliant JDK of the same major version. Swapping Oracle JDK for OpenJDK is a well-understood, low-risk change.
• Forgetting the multiplier. One Tomcat instance on chargeable Oracle JDK can trigger a subscription sized on your entire workforce. There is no “small” exposure here.

Getting independent help

Apache Tomcat is free, and that is not in doubt. But Tomcat is only ever half the stack. Underneath every Tomcat instance is a Java runtime, and that runtime — not the container — carries every licensing consequence. An estate of free Tomcat servers running on Oracle JDK 8 is an estate with a Java SE subscription liability hiding in plain sight, accumulated through years of installs where Oracle’s JDK was simply the default. The reassuring part is that Tomcat’s indifference to the runtime makes it one of the easiest deployment patterns to fix — a same-version OpenJDK swap usually removes the exposure entirely.

Independent, buyer-side advisers inventory the runtime under every Tomcat instance, separate free from chargeable, and plan the migration to free OpenJDK without disrupting production. Our Java Compliance Assessment finds the Oracle JDK hiding under your Tomcat estate; our Java Migration service moves it to a free footing. Across 340+ Java engagements, that approach has contributed to a 68% average reduction in audit claims and more than $180M in client savings.

Frequently asked questions