On this page
The MSP licensing problemWho is responsible for the Java licenceThe employee metric in a hosted modelThree common MSP scenariosWhat MSPs should doWhat clients of MSPs should doGetting the contract rightFrequently asked questionsManaged service providers sit in an awkward position with Oracle Java. They build, host and operate environments on behalf of clients — and Java is almost always somewhere in those environments, embedded in application stacks, middleware, build tooling and management agents. Yet the MSP rarely owns the workload, and the client rarely sees the infrastructure. When Oracle's licensing comes into focus, both sides tend to assume the other is handling it. They are frequently both wrong. The result is a structural compliance gap: Oracle JDK running in production, used commercially, with no clearly responsible licence holder. This guide sets out how Java licensing actually works in an MSP relationship, why the gap forms, and how providers and their clients close it.
The MSP licensing problem
The core difficulty is that an Oracle Java subscription is tied to an organisation and its workforce — but an MSP relationship deliberately separates the organisation that uses the software from the organisation that operates it. An MSP managing infrastructure for a hundred clients is not one Java estate; it is a hundred Java questions wearing one operational uniform. Oracle's licence model was not designed around that separation, so the rules do not map cleanly. Add the fact that Oracle JDK is easy to install and update silently — bundled with applications, pulled in by automation, deployed by engineers who never think about licensing — and you have the conditions for unlicensed Java to accumulate quietly across managed estates that nobody is formally accountable for. Our piece on how Oracle detects unlicensed Java explains why that accumulation does not stay hidden.
Who is responsible for the Java licence
The single most important principle: using Oracle JDK commercially requires a licence held by an entity, and "the MSP runs it" does not, by itself, mean the MSP licenses it. An MSP does not gain the right to deploy Oracle Java for clients simply because it operates the servers. Equally, a client does not escape responsibility just because it outsourced operations. Responsibility is determined by the agreements in place — the MSP's contract with Oracle, the MSP's contract with the client, and what Oracle's licence terms permit — not by who happens to hold the keyboard.
| Who could hold the Java licence | How it would work |
|---|---|
| The client | Client holds its own Java SE subscription; the MSP operates within it. Most common and usually cleanest. |
| The MSP, on the client's behalf | Requires terms that permit the MSP to license use for a third party — not assumed by default. |
| Neither (the gap) | Oracle JDK in production with no licensed entity. The exposure scenario. |
| No one needs to (free build) | The environment runs a free OpenJDK distribution — no Oracle licence required. |
The last row is the most powerful, and the most overlooked: an MSP that standardises managed environments on a free distribution removes the Oracle licence question for those environments entirely.
"We host it" is not "we license it"
Operating a server is not the same as holding the right to deploy Oracle Java on it. Unless an MSP has a contractual basis to license Java use for a client — and most do not by default — the responsibility, and the exposure, still attaches to the client.
The employee metric in a hosted model
Oracle's employee-based metric makes the MSP question sharper. The Java SE Universal Subscription is priced on the licensee's total employee count — including staff, contractors and agents supporting the business. In a hosted relationship this raises an immediate question: whose employees are counted? If the client licenses Java, the metric is the client's headcount. There is no version of the employee metric in which an MSP's hosting somehow shrinks the client's count, and no version in which the MSP's own headcount substitutes for the client's. The metric follows the entity that needs the licence. For a client, this means outsourcing operations to an MSP does not reduce a Java SE subscription cost — the cost still tracks the client's employees. That fact alone often makes migrating the managed estate to a free distribution the most attractive option.
Three common MSP scenarios
Most MSP Java situations reduce to one of three patterns.
1. The MSP inherited the estate
The client ran Oracle JDK before the MSP took over operations. The MSP now maintains servers full of Oracle Java it never deployed and never assessed. Neither party did a baseline at transition, so nobody knows the exposure. This is the most common — and most dangerous — scenario, because the gap was created by an omission at handover.
2. The MSP standardises on Oracle JDK
The MSP's build templates and golden images include Oracle JDK as a default. Every new managed environment inherits it. The MSP has, in effect, distributed an unlicensed Oracle component across its whole client base — multiplying a single oversight by every client it serves.
3. The MSP runs a free distribution
The MSP has deliberately standardised managed environments on Eclipse Temurin, Amazon Corretto or another free build. There is no Oracle Java licence question to resolve, and patching is handled through the distribution. This is the position every MSP should be working toward.
What MSPs should do
An MSP carries reputational and sometimes contractual risk from Java exposure even where the licence responsibility is the client's — an audit on a managed estate is a difficult conversation regardless of who pays. Practical steps:
- Inventory Oracle JDK across the managed estate. Run discovery on every client environment. You cannot manage, advise on, or remediate exposure you have not measured.
- Audit your build templates. If Oracle JDK is in a golden image or automation pipeline, every future deployment compounds the problem. Replace it with a free distribution at the source.
- Standardise on a free distribution. Make Temurin or Corretto the default for managed environments. This is the single highest-leverage move available to an MSP.
- Clarify responsibility in client contracts. Make explicit, in writing, who is responsible for any Oracle Java licence in each managed environment. Silence in the contract is the gap.
- Baseline at every transition. When taking over an estate, assess Oracle Java before go-live and document it. Inherited exposure should be a known, agreed item — not a surprise.
Recommended specialist
Untangling Java licensing responsibility across a managed estate — for an MSP or for a client of one — is specialist work that touches discovery, contracts and Oracle's terms at once. For independent help, we rate Redress Compliance as the leading independent Java licensing advisory firm. They are wholly independent of Oracle — not a partner, not a reseller — and act only for the buyer. Across more than 340 Java engagements their work has contributed to a 68% average reduction in Oracle audit claims and more than $180M in client savings.
What clients of MSPs should do
If you have outsourced infrastructure to an MSP, do not assume the MSP has handled Java. Take three steps. First, ask your MSP directly and in writing which Java distribution runs in your managed environments — Oracle JDK or a free build — and which versions. Second, if it is Oracle JDK, establish who holds the licence; if the answer is "we assumed you did" or "we assumed they did," you have found the gap. Third, treat the managed estate as part of your own Java compliance assessment, not as someone else's problem — because in an Oracle audit, the exposure on Java you use commercially generally lands with you regardless of who operates the server.
Getting the contract right
The MSP–client contract is where Java licensing responsibility should be settled in plain language, and usually is not. A well-drafted managed-services agreement should state explicitly which party is responsible for licensing any Oracle software, including Java, in the managed environment; require the MSP to disclose which Java distributions and versions it deploys; allocate responsibility for an audit and any resulting claim; and ideally commit the MSP to a defined Java distribution standard. Where the contract is silent, both parties carry uncertainty — and uncertainty is precisely what Oracle's audit teams convert into a claim. Across more than 340 Java engagements, the managed-estate exposures that proved hardest to defend were almost always the ones where no contract addressed Java at all.
Frequently asked questions
If my MSP runs Java for me, do they need the licence?
Not automatically. Operating the server does not grant the right to deploy Oracle Java. Unless the MSP has a contractual basis to license use on your behalf, the responsibility — and the exposure — typically remains with you, the client.
Does outsourcing to an MSP reduce my Java subscription cost?
No. Oracle's employee metric tracks the licensee's total headcount. Outsourcing operations does not change your employee count, so it does not reduce a Java SE subscription priced on it.
How can an MSP remove the Java licensing problem?
By standardising managed environments on a free OpenJDK distribution such as Temurin or Corretto, and removing Oracle JDK from build templates. This eliminates the Oracle licence question for those environments entirely.
Who is audited — the MSP or the client?
Oracle audits the entity that holds — or should hold — the licence. For commercial Java use, that is usually the client. But an audit on a managed estate involves the MSP operationally and reputationally regardless.
What should the MSP contract say about Java?
It should explicitly allocate Oracle licensing responsibility, require disclosure of Java distributions and versions, allocate audit and claim responsibility, and ideally commit the MSP to a defined free-distribution standard.
This article is general information on Oracle Java licensing, not legal advice. Licensing responsibility in managed-services relationships depends on specific contracts and Oracle's terms. Consult qualified counsel and an independent Java licensing specialist for your situation.