Your pre 2023 perpetual and Named User Plus Java entitlements did not evaporate when Oracle rewrote its price list. They are property, and property has edges. This page maps where those edges sit, what the grant covers, and which ordinary corporate events move you outside it.
Your pre 2023 perpetual and Named User Plus Java entitlements did not evaporate when Oracle rewrote its price list. They are property, and property has edges. This page is about where those edges sit: what the grant covers, what only the support contract ever covered, and which ordinary corporate events quietly move you outside the boundary.
Yes. A perpetual license Oracle granted before January 2023 is still a perpetual license, and an in term subscription runs to its stated end date on its stated terms. Oracle changed what it sells. It did not, and cannot, retroactively cancel what it already sold.
The useful question is narrower. Not "is it valid" but "how far does it reach". A license is a permission with a shape, and the shape was fixed on the day the ordering document was signed.
Oracle cannot take your perpetual license away. It can decline to let you grow inside it, and it can price the exit from it. Those are different problems, and only the first one is settled.
It entitles you to use a named program, at a named quantity, forever. That is the whole grant. Everything else you associate with owning Oracle software came from a separate annual contract you may or may not still be paying for.
This is the distinction that decides most legacy Java arguments, and it is the one buyers get wrong most often. The license fee bought permission. The support fee bought a pipeline: patches, security updates, new releases, and the right to open a service request.
When support stops, the pipeline stops. The permission does not. You keep running what you had, at the version you had rights to when the pipeline closed, and you stop receiving anything published afterwards.
Oracle's own Software Technical Support Policies set out this split, including the rules on reinstatement and on terminating support for part of a license set. Read the version in force for your contract year, not the current one.
Pre 2023 Oracle Java entitlements and what each one is
| Entitlement | Shape | Typical metric | What survives without support |
|---|---|---|---|
| Java SE Advanced | Perpetual license plus annual support | Processor or Named User Plus | Use rights at the licensed quantity, on the releases you were entitled to obtain |
| Java SE Advanced Desktop | Perpetual license plus annual support | Named User Plus | Desktop use rights at the licensed user count |
| Java SE Suite | Perpetual license plus annual support | Processor or Named User Plus | Use rights, including the components bundled into the Suite |
| Java SE Subscription (2019 to 2022) | Term subscription | Named User Plus or Processor | Nothing. Rights end with the term |
| Java SE Desktop Subscription | Term subscription | Named User Plus | Nothing. Rights end with the term |
| Restricted use JDK inside another Oracle program | Bundled right, follows the host program | Host program metric | Whatever the host program entitlement allows, for that program only |
Sort every Java line item you hold into one of those rows before you do anything else. The perpetual rows are a durable asset on the balance sheet of the negotiation. The term rows are an unfinished conversation with a date on it.
From the ordering document, and only from the ordering document. Not the support renewal quote, not the Oracle account team's install base extract, and not the spreadsheet your predecessor maintained. Those are secondary sources and they drift.
Named User Plus on Oracle server programs is not a pure headcount metric. It carries a contractual minimum expressed per processor, so the licensable quantity is the higher of your actual user count and that floor.
The practical effect is that a lightly used but widely installed server estate can require far more Named User Plus licenses than there are humans touching it. Check the minimum stated in your ordering document or the applicable license definitions before you conclude you are compliant.
You keep the software and lose the supply chain. That trade is often perfectly rational for a frozen Java estate, and it is sometimes the strongest position a buyer has, but it has to be a decision rather than an accident.
Perpetual license after support lapses: what you keep and what stops
| Item | Status after lapse | Practical consequence |
|---|---|---|
| Right to run the licensed quantity | Retained | The estate keeps working, indefinitely |
| Security patches and updates | Stops | Frozen build. Compensating controls become a security conversation, not a licensing one |
| New major releases | Stops | No entitlement path to a newer JDK through the old agreement |
| Access to the support portal for new downloads | Stops | Archive your entitled installers and their checksums before the account closes |
| Service requests | Stops | Third party or internal support becomes the fallback |
| Audit exposure | Unchanged | Lapsing support does not reduce the obligation to stay inside the licensed quantity |
This is the single most common regret in a lapse. Once the support account is deactivated you generally lose the ability to pull installers you were entitled to while the contract was live.
Before the end date, take a dated copy of every installer and patch you are entitled to, record the checksums, and store them with the ordering document. That package is both an operational safety net and evidence of what you legitimately obtained.
Oracle's published support policies apply a reinstatement charge if you stop paying support and later want it back, calculated from the lapsed period rather than from the day you ask. Treat reinstatement as a one way door and price it before you let a renewal slide.
Oracle's support policies also restrict partial termination. You generally cannot keep support on some licenses in a set and drop it on the rest without the remaining licenses being repriced.
That mechanic is what turns a modest reduction into a full renegotiation. In practice it is the most frequent trigger for the conversation that ends with an employee based quote, and it is far more common than any audit letter.
None of them void the license. Each of them creates usage the license does not reach, which is the same thing commercially and a very different thing legally. Keep the distinction, because it changes what you are arguing about.
We disagree with the standard counsel, which is to hold the legacy position at all costs. That advice treats the entitlement as a fortress when it is really a bank balance. A perpetual position on a shrinking, frozen estate can be worth defending for a decade; a perpetual position on an estate that is growing, containerizing and moving to cloud is a wasting asset that will be overrun within two renewal cycles, and every month spent defending it is a month not spent migrating off it. The right question is not "can we keep this" but "how many years of runway does this buy, and what does the exit cost if we start now rather than under an audit clock". Buyers who model both answers negotiate from a completely different place.
Quite a lot, usually. Before you count a Java installation as exposed, check whether something you already pay for covers it. This is the highest yield hour of work in the whole exercise.
Several Oracle programs ship with a Java runtime licensed only for use with that program. The right is real, it is already paid for, and it is narrow.
The boundary is the point. Running a general purpose application on that same JVM, or reusing the binary for an unrelated workload, steps outside the bundled right. Document which hosts rely on bundled rights and why, because that mapping is what turns an install count into a licensable count.
Independent software vendors frequently distribute an Oracle runtime with their product under an application specific license. Your right to that JVM comes from the vendor agreement, not from any Oracle order you signed.
Ask each vendor, in writing, three questions: which runtime does your product ship or require, under what license is it distributed to us, and does that license cover the version we are running today. Keep the replies. They are the cheapest evidence you will ever collect.
The value is the delta between a metric that tracks usage and a metric that tracks headcount. Legacy Java pricing followed processors and named users. The current subscription follows your employee count, which for most organizations is a much larger and entirely unrelated number.
Oracle's published employee tier rates start at $15.00 per employee per month for 1 to 999 employees and step down with volume to $5.25 for the 40,000 to 49,999 band. Above 49,999 the rate is not published.
Support is included in the subscription, which is one of the few genuine improvements in the model. The full ladder, with arithmetic, sits in the employee tier pricing table and worked examples.
Illustrative annual list exposure at published employee tier rates
| Employees | Published rate per employee per month | Annual list cost | Java users required to justify it |
|---|---|---|---|
| 500 | $15.00 | $90,000 | One |
| 2,500 | $12.00 | $360,000 | One |
| 8,000 | $10.50 | $1,008,000 | One |
| 45,000 | $5.25 | $2,835,000 | One |
Rates are Oracle's published Java SE Universal Subscription employee tiers. Figures are list, before any negotiated position.
Read the last column again. The metric does not care whether one developer or ten thousand people touch Java. That asymmetry is exactly why a small legacy entitlement can be worth an order of magnitude more than it cost, and why fifty developers can force a ten thousand employee bill.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
A legacy Java entitlement is not sentimental value. On a mid sized estate it is frequently the difference between a five figure and a seven figure annual line, and it is sitting in a filing system nobody has opened since 2018.
With documents, in a pack, assembled before you need it. Oracle's position in any legacy discussion is that the burden of demonstrating entitlement sits with the customer, and a buyer who cannot evidence the grant is treated, commercially, as if it does not exist.
Ordering documents and executed agreements carry weight. Screenshots, internal spreadsheets and recollections of what a former account manager said do not.
If the paper is genuinely lost, ask Oracle for its own records of your orders. Oracle keeps them, and requesting the file discloses nothing about your estate.
Understand what Oracle's records do and do not establish before you lean on them, which is set out in the analysis of what Oracle already knows.
A clean entitlement does not protect the parts of the estate it never covered. The usual leaks are development laptops, contractor machines, container images baked years ago, and test environments nobody assigned to a cost center.
Contractor headcount deserves separate attention, because if the conversation does move to the employee metric it becomes the single largest number in dispute. Start with how contractors and consultants are counted before you accept any figure Oracle proposes.
If you want a structured view of where your organization currently sits, the banded output and the ninety day plan in the Java license risk assessment is the fastest way to turn this into a work order. The wider metric mechanics live in the employee metric guide.
No. A perpetual grant survives Oracle changing its product line or its price list, and an in term subscription runs to its end date on its own terms. What Oracle controls is what it will sell you next, which since January 2023 is the employee based Java SE Universal Subscription.
Not on its own. The license grants use rights; the support contract was what delivered new releases and patches. If support has lapsed, you keep running the releases you were entitled to obtain while it was live, and a newer JDK needs a current entitlement. Oracle's Java SE support roadmap sets out which releases are current.
Named User Plus counts authorized individuals and carries a contractual minimum tied to processor count, so the licensable quantity is the higher of the two. Processor counts the hardware and is indifferent to how many people use it. Growth breaks them differently, which is why the metric on each line has to be recorded, not remembered.
Not by itself. A lapse ends the pipeline of patches and new releases; it does not end the right to run what you already had at the licensed quantity. You become non compliant only if the estate grew past the ceiling, or if someone installed a release you had no entitlement to obtain.
No. A restricted use runtime shipped with an Oracle program is licensed for that program only. It is a genuine, already paid entitlement for its host workload and it is worth mapping carefully, but reusing the same binary for an unrelated application steps outside it.
They stay with the entity named in the grant unless Oracle consents to an assignment. Plan the licensing position alongside the transaction rather than after it, because the buyer of a divested business often discovers it inherited the servers and not the rights. Check the assignment and affiliate clauses in the master agreement before the transitional services agreement is drafted.
Usually not as a matter of price list, and any exception is a negotiation rather than an entitlement. Oracle's current Java offering is the employee based subscription, and a request to add legacy quantity is frequently the moment the model conversation begins. Treat any capacity request as a commercial event and prepare for it.
Ask Oracle for its record of your orders, and ask the reseller or partner that transacted the deal for their copies. Both hold the paperwork, and requesting it discloses nothing about your current deployment. Oracle's own licensing services group publishes how it approaches license reviews, which is useful context for how the documents will later be read.
Oracle Exadata can lock you into full core licensing across X9M, X10M, and Cloud at Customer. The buyer side strategy to size the platform and cut the bill.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
