The Universal Subscription is built on a simple, expensive idea: that you license Java for everyone you employ rather than for the machines that actually run it. A carve out challenges that idea directly. It is an arrangement, scoped and documented, in which Oracle Java is licensed only for the specific workloads that truly depend on it, while the rest of the estate runs a free OpenJDK distribution and stays out of scope. Done well, a carve out turns a per employee bill across your whole workforce into a contained commitment that matches reality. Done carelessly, it leaks, and the boundary you thought you drew dissolves under audit. This article is about drawing one that holds.
For the licensing context behind every figure here, keep the Oracle Java licensing guide for 2026 to hand.
Why the carve out is the buyer's natural move
Since January 2023 Oracle has priced Java SE on the Universal Subscription, a per employee charge from 5.25 to 15.00 dollars per employee per month that counts every full time and part time employee, every contractor, and every temporary worker regardless of who uses Java. In most estates only a fraction of those people ever touch Oracle Java. The carve out exists to close that gap. By isolating the genuine Oracle dependency and licensing only that, you stop paying for thousands of people who never run the product. It is the same instinct that drives migration as leverage, which we cover in migration as Java negotiation leverage.
The carve out in one line. License the workloads that need Oracle Java, not the people who happen to be on your payroll.
Scope the boundary before you raise it with Oracle
A carve out is only as strong as the boundary that defines it, and that work happens before Oracle is involved. Sweep the estate, identify every place Oracle Java runs, and sort each one into two groups: workloads that have a genuine technical or contractual reason to stay on Oracle Java, and workloads that can move to a supported free distribution with no material difference. The first group is your carve out. The second group leaves scope entirely. The clearer and better evidenced that line, the harder it is for an audit to blur it later.
Make the boundary technical, not just contractual
A boundary written only on paper invites dispute. The strongest carve outs are enforced in the estate itself, so that the workloads inside scope are genuinely separated from those outside it. That means controlling where Oracle Java can be installed, defaulting every new deployment to the free distribution, and keeping a record that shows the separation holds over time. When the technical reality matches the contract language, the carve out survives the three year lookback that LMS reviews now apply in 2026. When it does not, every stray install outside the boundary becomes an argument for licensing the whole estate again.
A carve out at a glance
| Workload group | Java source | Licensing status |
|---|---|---|
| Workloads with genuine Oracle dependency | Oracle Java | Inside the carve out, licensed |
| General business applications | Free OpenJDK distribution | Out of scope |
| Developer machines | Free OpenJDK distribution | Out of scope |
| New deployments by default | Free OpenJDK distribution | Out of scope unless justified |
Negotiate the carve out into the contract language
Once the boundary is real, it has to be written into the order form so Oracle cannot quietly widen it. Define the licensed scope precisely, tie the metric to the carved out population rather than the whole workforce, and remove the language that would pull the rest of the estate back into scope. This is detailed work, line by line, and it is where carve outs are won or lost. Pair it with the discipline of negotiating terms rather than just the rate, which we set out in negotiating Java terms, not just the rate, and guard against the floors, true ups, and escalators that can inflate even a well scoped deal.
Defend the carve out after signature
A carve out is not a one time event. It is a position you maintain. Keep the default to the free distribution, keep new Oracle Java deployments gated behind a recorded justification, and keep the evidence current so that the next audit finds a boundary that still matches the contract. The estate that drifts is the estate that pays twice, first for the subscription and then for the audit that finds the drift. The estate that holds its boundary keeps its carve out and its savings.
Common ways a carve out leaks
A carve out fails quietly. It is drawn cleanly at signature and then erodes through ordinary activity. A developer installs Oracle Java on a machine that was supposed to run the free distribution. A new server is provisioned from an old image that still points at Oracle. An acquired business arrives with its own Oracle Java footprint that no one mapped. Each leak is small, and each one gives an auditor a reason to argue the boundary never held. The defense is constant: default new deployments to the free distribution, control who can install Oracle Java, and review the boundary on a schedule rather than only when an audit forces it.
Carve out versus full migration
A carve out is not the same as a full migration, and choosing between them is a real decision. A full migration moves every workload off Oracle Java and ends the subscription entirely, which is the cleanest outcome where it is achievable. A carve out keeps a small, licensed island for the workloads that genuinely require Oracle Java while moving everything else away. For many estates the carve out is the pragmatic answer, because a handful of workloads have a real dependency that is costly or risky to remove. The right choice depends on how large and how genuine that residual dependency is, and an honest estate sweep is what tells you.
Quantifying the carve out savings
| Scenario | Population licensed | Relative cost |
|---|---|---|
| No carve out | Entire workforce, all employees and contractors | Highest |
| Carve out | Only the genuinely dependent workloads | A fraction of the above |
| Full migration | None, subscription ended | Lowest ongoing, plus one time project cost |
The figures will vary by estate, but the shape rarely does. Because the metric counts your whole workforce rather than your Java users, removing the bulk of the estate from scope produces a saving out of all proportion to the effort. That is the economic case for the carve out, and it is why it is so often the buyer's strongest move.
Write the renewal protections into the same deal
A carve out that is not protected at renewal can be undone at renewal. When you negotiate the carved out scope, deal with the contract traps in the same breath: bound the annual true up so it cannot quietly drag the rest of the estate back into scope, remove or cap the minimum annual floor so you are not billed for capacity you carved out, and strip or cap the renewal escalator. A carve out and clean renewal terms belong in the same negotiation, because together they hold the line over time rather than for a single contract period.
How a buyer side advisor helps
Scoping and defending a carve out is exactly the kind of work where an independent buyer side advisor earns its place. We know which boundaries Oracle accepts, which contract language actually holds, and how to convert a clean separation into a smaller defended residual. We sit between you and Oracle and we never take vendor money. We work two ways, both built so the risk sits with us. A Fixed Fee starts from $18,000, agreed up front. Or choose Gainshare, a share of verified savings or avoided exposure, with zero retainer and no risk to you. We have defended more than $120M in Java exposure and over 300 Java audits, with more than 20 years of combined experience and an average reduction of 68 percent versus Oracle's opening number.
Where to go next
A carve out replaces a workforce wide bill with a commitment that matches what you actually run. Scope the boundary, enforce it technically, and write it into the contract. Tell us where Oracle Java truly lives in your estate and we will give you a quote and a plan to carve it out and defend it.