Java ULA versus the employee subscription

By the Meridian advisory team, former Oracle LMS and GLAS licensing analysts. Updated 4 June 2026.

What is the difference between a Java ULA and the employee subscription?

A Java ULA grants unlimited Java deployment for a fixed term and certifies into perpetual licenses that you then own. The Java SE Universal Subscription is a recurring subscription priced by total employee count, not by how much Java you actually run, and it protects you only for as long as you keep paying. The two models are built on opposite principles. A Java ULA, like any ULA, converts deployment into a permanent entitlement at the end of its term. The employee subscription converts your whole headcount into a perpetual annual bill, regardless of whether Java runs on ten servers or a thousand. That single design choice is what makes the comparison matter so much for any organisation holding a Java ULA today.

How a Java ULA works at certification

A Java ULA behaves like other Oracle ULAs. During the term you deploy Java without counting, and at the end you certify the deployed quantity into a perpetual entitlement, typically expressed in the metric your agreement uses. The certified licenses are then yours, and you continue to pay support on them but not a fresh subscription fee tied to headcount. As with any certification, the value depends on measuring the deployment properly and documenting it, and the same discipline that maximises a database certification applies to Java. The certified count is the asset you walk away with, so it is worth getting right.

How the employee subscription works

The Java SE Universal Subscription is priced on the total number of employees in the organisation, a definition that typically includes full time staff, part time staff, temporary workers, agents, and contractors who support internal operations, not just the people who use Java. Because the metric is headcount rather than deployment, the cost is driven by the size of the organisation and rises with it, and it continues for as long as the subscription is in force. It is genuinely simple to administer, but for an organisation with a large workforce and a modest Java footprint it can be expensive relative to the Java actually in use, and it never produces an owned entitlement.

Should you certify a Java ULA or move to the employee subscription?

It depends on your Java footprint and your employee count, and the answer usually favours certifying. If you hold a Java ULA, certifying into perpetual licenses captures the value of the deployment you built during the term and avoids converting your headcount into a perpetual annual fee. The employee subscription is rarely the better destination for a ULA holder, because it abandons the ownership the certification would deliver and reprices Java on a metric that has nothing to do with how much Java you run. The honest exceptions are organisations whose Java footprint is so large and so fast growing that a headcount based subscription is genuinely cheaper than maintaining and supporting a certified estate, but those are the minority, and the only way to know is to model both. Every Java agreement has its own language, so the certification metric and the rights you certify into depend on the contract.

A worked illustration

Take an indicative organisation with a large workforce and a Java estate concentrated on a defined set of servers. Under its Java ULA it can certify that deployment into a perpetual entitlement and carry only the support cost afterwards. Under the employee subscription it would instead pay every year on its entire headcount, a figure driven by the size of the company rather than the size of the Java estate. For this profile, certifying preserves an asset and caps the forward cost at support, while the subscription would create a recurring liability scaled to a number that has little to do with Java. The figures are indicative and the outcome depends on the contract and the actual headcount, but the shape recurs whenever the workforce is large relative to the Java footprint.

Dimension	Java ULA (certified)	Employee subscription
Pricing metric	Deployment, at certification	Total employee count
Outcome	Perpetual owned licenses	Recurring subscription
Forward cost	Support on certified count	Annual fee on headcount
Ends in ownership	Yes	No

Where OpenJDK fits the decision

The third option is to remove the dependency on Oracle Java altogether by migrating to OpenJDK, which can change the comparison entirely by reducing or eliminating the need for either a certification or a subscription. For many estates a migration is a credible exit, and it deserves to sit in the model alongside certifying and subscribing rather than being treated as an afterthought. We set out the route in OpenJDK migration as a ULA exit path. Whichever path you choose, the risk that surfaces afterwards is the same, and it is worth understanding before you decide, as covered in the Java audit risk after a ULA exit.

Where this leads

For an organisation holding a Java ULA, the choice is rarely as simple as renewing into the employee subscription, because that path trades the ownership a certification delivers for a perpetual fee scaled to headcount. Measure your Java deployment, model certifying against subscribing and against an OpenJDK migration, and read the certification metric in your own agreement before deciding. The full treatment of leaving an Oracle agreement on good terms lives in our pillar, the ULA exit strategy guide.

The takeaway

A Java ULA certifies into perpetual licenses you own, while the Java SE Universal Subscription charges every year on total employee count and never ends in ownership. For most ULA holders, certifying preserves more value than lapsing into a headcount based subscription. Measure your Java footprint, model certifying against subscribing and against an OpenJDK migration, and check the certification metric in your contract, because the answer depends on it.