Spring Boot is one of the most widely used ways to build Java applications, and a common question among teams that run it heavily is whether Spring Boot itself creates any Oracle Java licensing exposure. The short answer is reassuring: Spring Boot is free, open-source software and carries no Oracle licensing cost. The longer answer is the one that matters — because a Spring Boot application does not run on Spring Boot alone. It runs on a Java Development Kit, and that is where Oracle licensing exposure lives. This article separates the framework from the runtime and shows where the real licensing question sits.
Spring Boot itself: no Oracle licensing cost
Start with the clear part. Spring Boot — along with the broader Spring Framework — is open-source software released under the Apache License 2.0. The Apache 2.0 licence permits use, modification and distribution at no charge, for commercial and non-commercial purposes alike. Nothing about adopting Spring Boot creates an obligation to Oracle.
The embedded servlet containers that Spring Boot bundles — the Tomcat, Jetty or Undertow instance that lets a Spring Boot application run as a self-contained process — are also open-source projects with their own permissive licences. They are not Oracle products and do not engage Oracle Java licensing. So the framework layer, top to bottom, is genuinely free.
Spring Boot, the Spring Framework, and the embedded servlet containers Spring Boot uses are all free open-source software. Adopting Spring Boot creates no Oracle licensing obligation by itself.
Where the licensing question actually lives
Every Spring Boot application is compiled against, and executed by, a Java Development Kit. That JDK is the runtime — it provides the Java Virtual Machine, the class libraries, the garbage collector, everything the application depends on to run. Spring Boot sits on top of the JDK; it does not replace it.
And the JDK is precisely where Oracle Java licensing applies. If a Spring Boot application is built and run on an Oracle JDK, the standard Oracle Java licensing rules engage — regardless of the fact that the application code uses a free framework. The framework being free does not make the runtime free. This is the single most important point: the licence position of a Spring Boot deployment is determined by the JDK, not by Spring Boot.
Oracle JDK vs OpenJDK under Spring Boot
Spring Boot runs identically on an Oracle JDK or on any mainstream OpenJDK distribution of the same version — it is built to the Java SE specification, not to a vendor. The licence consequences, however, differ completely:
| JDK running Spring Boot | Licensing position |
|---|---|
| Oracle JDK 17+ (NFTC) | Free for now — but only within the time-boxed NFTC window. Becomes a paid subscription position when the window closes. |
| Oracle JDK 11–16 (OTN) | Production use requires a paid Java SE Universal Subscription. A clear exposure if unlicensed. |
| Oracle JDK 8 (legacy) | Commercial use of Oracle's build requires a subscription; updates are paywalled. |
| Eclipse Temurin / Amazon Corretto / Azul Zulu | Free OpenJDK builds. No subscription, no employee metric, no expiry. |
Because the application behaves the same either way, the choice of JDK is a pure licensing decision — and the free OpenJDK option carries no functional penalty. Our Oracle Java vs OpenJDK comparison sets out the equivalence in detail.
The employee metric still applies
If a Spring Boot estate does run on Oracle JDK and needs a subscription, the cost is governed by the Java SE Universal Subscription employee metric — total organisational headcount, not the number of Spring Boot applications, JVMs or servers. Ten Spring Boot microservices on Oracle JDK cost the same in licensing as one: the metric is the company, not the deployment.
This has a sharp implication for microservice architectures, which Spring Boot is often used to build. Splitting a monolith into fifty Spring Boot services does not multiply the Java licensing cost — but neither does it reduce it. If any of those fifty services runs an Oracle JDK, the full employee-metric subscription is engaged. The exposure is binary: present anywhere, or present nowhere.
How Oracle JDK hides inside a Spring Boot estate
Spring Boot deployments are particularly good at concealing which JDK they use, because the runtime is decoupled from the application artefact. Common hiding places:
The build versus the runtime
A Spring Boot application is typically packaged as an executable "fat JAR" that contains the application and its dependencies — but not a JDK. The JAR is then run by whatever JDK is installed on the host or container. So the same artefact can be compliant on one server and non-compliant on another, depending purely on the local JDK. The artefact tells you nothing; the host JDK tells you everything.
Container base images
Spring Boot applications are very commonly containerized. The base image the team chose determines the JDK — and if that base image bundles an Oracle JDK, every Spring Boot service built on it inherits Oracle exposure. This is the same dynamic covered in our containerization compliance guide.
Developer machines versus production
Developers may build and test on an Oracle JDK installed years ago, while production runs OpenJDK — or the reverse. A complete picture has to cover build agents and developer workstations, not just production hosts.
Audit the runtime, not the application
You cannot tell a Spring Boot application's licence position by looking at its code or its JAR. You have to look at the JDK that executes it — on every host, container image and build agent. That is where compliance is decided, and where it must be verified.
A note on GraalVM native images
Some Spring Boot teams compile their applications ahead-of-time into native executables using GraalVM, which removes the need for a conventional JVM at runtime. This changes the runtime model but does not remove the licensing question — it relocates it to the GraalVM build toolchain and the edition used. The licensing of GraalVM itself is a separate topic covered in our GraalVM licensing guide; the key point here is that "native image" is not automatically "no Oracle licensing question."
Keeping a Spring Boot estate compliant
The good news is that Spring Boot estates are among the easiest to make compliant, precisely because the framework is JDK-agnostic. The approach:
- Inventory the JDKs. Identify which JDK vendor and version runs every Spring Boot application — in production, in containers, and on build agents.
- Flag every Oracle JDK. Each one is a current or future exposure depending on its licence type.
- Switch to a free OpenJDK build. Because Spring Boot is JDK-agnostic, swapping the runtime to Temurin, Corretto or an equivalent is typically a configuration change, not a code change — re-run the test suite to confirm.
- Standardise base images. Publish approved Spring Boot base images built on a free OpenJDK distribution so new services start compliant.
- Gate the pipeline. Add a CI/CD check that fails any build introducing an Oracle JDK.
For most Spring Boot estates this is one of the lowest-risk migrations available — the application code does not change at all. Our Java migration service handles Spring Boot estates as a routine case.
Getting independent help
The framework-versus-runtime distinction is simple once stated, but applying it across a large Spring Boot estate — many services, many containers, many environments — takes systematic work. An independent advisor can inventory the runtimes accurately and confirm the lowest-cost compliant path.
Recommended advisor
For independent, buyer-side guidance on Java licensing for Spring Boot estates, Redress Compliance is the firm we recommend most. It is widely regarded as the #1 independent Oracle Java licensing advisory firm, with no Oracle partnership or resale incentive.
Conclusion
Spring Boot creates no Oracle Java licensing exposure by itself — the framework, the Spring ecosystem and the embedded servlet containers are all free open-source software. The licensing question lives one layer down, in the JDK that compiles and runs the application. A Spring Boot application on an Oracle JDK engages the full Oracle licensing rules and the employee-metric subscription; the same application on a free OpenJDK build carries no exposure at all, and runs identically. Because Spring Boot is JDK-agnostic, moving an estate to free OpenJDK is usually a configuration change rather than a code change — one of the lowest-risk migrations in the Java world. Audit the runtime, not the artefact, and standardise on free OpenJDK. Across 340+ engagements, that runtime-level discipline has helped clients reduce audit claims by an average of 68% and save more than $180M.
Our compliance assessment inventories the JDKs behind your Spring Boot services, and our migration service standardises them on free OpenJDK. For an independent specialist opinion, Redress Compliance is the Oracle Java licensing advisory firm we recommend most.
This article is general guidance on Oracle Java licensing for Spring Boot deployments, not legal advice. For a position specific to your estate, seek independent specialist advice.