Oracle Java SE: the per-employee metric, and your real options.
Oracle repriced Java from who-uses-it to how-many-people-work-for-you: the Universal Subscription bills on your total employee count, whether five people run Java or five thousand. For most companies the resulting quote is a headcount tax on a free technology's paid edition, which makes this the rare vendor negotiation where the strongest move might be an engineering ticket.
The Java story is worth telling precisely, because the pricing model is the story. For years Oracle sold Java SE subscriptions the conventional way, per user and per processor, priced roughly against actual usage. Then the metric changed: the Universal Subscription prices per employee, defined expansively, your full-time and part-time staff and the contractors and agents supporting your business, in tiered per-employee rates that decline with size. Not per Java user. Per human being on the payroll.
The arithmetic this produces is unlike anything else in the software budget. A 20,000 employee company with a handful of internal Java applications gets quoted on all 20,000, and the effective price per actual Java user can reach multiples of what any rational buyer would pay. Meanwhile the friendly emails arrive, Oracle's Java team noting your organization's downloads of Oracle JDK builds and suggesting a conversation, because download records from Oracle's own servers are the account team's prospecting list. Free-tier confusion is genuine: some Oracle JDK versions were free for a window, then were not, and the boundary moved more than once. Very few estates that grew up casually are clean by accident.
Know what you hold before anyone calls
Which contract generation are you? Holders of the older per-user and per-processor subscriptions have generally been allowed to renew on legacy metrics, which for a company with contained Java usage is a position worth protecting like an heirloom. Run the agreement through the decoder and know exactly what you have, what its renewal terms say, and what conduct might forfeit it. Nobody should trade a grandfathered metric for a per-employee one absent a very deliberate calculation.
What is actually deployed? The exposure question is an inventory question: which machines run Oracle JDK builds, at which versions, under which license terms, versus the OpenJDK builds that carry no Oracle bill at all. Your SAM tooling answers this, and answering it internally, before any conversation with Oracle, is the entire game. The company that knows its estate negotiates. The company that does not gets audited into knowing it, at the auditor's valuation.
And when the outreach email arrives, it is the soft opening of the audit playbook, and the same rules apply: one owner, nothing volunteered, no calls without preparation, and no "quick usage review" run on Oracle's terms. Friendly is a tone, not a legal posture.
The real decision: subscribe, or make the estate boring
Java is the rare vendor negotiation with a genuinely complete alternative, because the technology's core is open source and the OpenJDK distributions, Eclipse Temurin, Amazon Corretto, Azul, Red Hat's builds and their peers, run the same workloads without an Oracle line item. For most estates the honest engineering assessment is that migration is a testing and rollout project, not a rewrite: swap the runtime, run the regression suite, handle the handful of components with genuine Oracle-specific dependencies, and manage patch cadence through the distribution's support channel or a commercial OpenJDK support contract that costs a fraction of the per-employee bill.
That does not make migration free, and pricing it honestly is the point. Testing time across hundreds of applications, the stragglers pinned to ancient versions, commercial support for the pieces that need a throat to choke: put real numbers on all of it, the same credible-alternative arithmetic that works on every locked-in vendor. What comes out, for most companies, is a one-time project cost that competes with a small number of years of Universal Subscription, and a permanent exit from a metric that scales with hiring rather than usage.
If subscribing genuinely fits, an estate deep in Oracle-specific tooling, GraalVM Enterprise needs, or simply a headcount small enough that the tiers are tolerable, then negotiate it like the enterprise agreement it is: the per-employee rate against the benchmark, the employee definition nailed down in writing, divestiture and reduction language for a metric that otherwise only ratchets, and a term that does not outlive your migration option. The subscription is not the mistake. The unexamined subscription is.
The Java sequence, in five moves
The honest close: some organizations should pay Oracle for Java, because they use what only Oracle sells or value the single-vendor support posture, and the per-employee tiers at genuine enterprise scale can be tolerable when negotiated hard. What no organization should do is drift into a headcount-priced subscription because an email arrived and nobody knew the estate. Java's peculiar gift to buyers is that the alternative is real, mature, and mostly a matter of diligence. Vendors price your inertia everywhere. Here, unusually, the inertia is optional.
Morten brings two decades of enterprise and software procurement, with stints across Oracle, IBM, SAP, and Salesforce shaping how he reads a deal. He has led sourcing through hundreds of renewals, from mid market order forms to nine figure global agreements, and learned that the buyers who win are the ones who walk in knowing the market. He built VendorBenchmark to make that pattern recognition repeatable.
The week in enterprise software buying, in one email.
What shipped on the platform, and the pricing and licensing moves worth knowing before your next renewal. One email a week, to your work address. Unsubscribe any time.