Short answer: Third-party support legal risk is not about whether you may leave Oracle support — that is unambiguously lawful — but about how your provider builds and stores fixes. The Rimini Street v Oracle litigation policed delivery methods, not the existence of third-party support itself.
Oracle's account teams describe third-party support as a legal minefield because fear is cheaper than a 50% discount. The reality is narrower and more manageable. The only Oracle support provider Oracle has litigated against is Rimini Street, the case turned on specific copying practices that the provider has since changed, and no court has ever held that an enterprise running Oracle software on a perpetual license without Oracle support is breaking the law. This guide separates settled law from Oracle's deterrence playbook so you can evaluate third-party support legal risk on evidence, not on the account manager's framing.
Short answer: Yes. Third-party support is the practice of replacing Oracle's annual maintenance with an independent provider for break-fix, security advisory, and tax, legal and regulatory updates. Running Oracle software on a perpetual license without Oracle support, and paying an independent firm instead, is lawful in every major jurisdiction.
Third-party support is a legitimate, established market. An Oracle perpetual license grants the customer the right to use the licensed software indefinitely — those use rights are not conditional on an active Oracle support contract. When you stop paying Oracle's 22% annual maintenance, you lose access to Oracle's patches, updates and My Oracle Support portal, but you keep the right to run the software you already own. Independent providers exist to fill the support gap that this creates.
The confusion enterprises feel is deliberate. Oracle's sales organisation conflates two separate questions — "may I leave Oracle support?" and "may a provider copy Oracle's software to support me?" — because blending them makes a lawful decision sound risky. We push back on that framing because it costs buyers real money. The first question is settled: leaving is lawful. The second question is where the litigation history actually sits, and it is the question that should drive your provider selection.
Short answer: Oracle America v Rimini Street found that Rimini's early support model infringed Oracle's copyrights by copying Oracle software in unlicensed ways, and a later injunction restricted specific fix-development practices. No ruling declared third-party support itself unlawful, and Rimini changed its delivery model in response.
Oracle filed suit against Rimini Street in 2010. The dispute centred on how Rimini built and stored the software fixes it delivered to clients — in particular, the practice of downloading and copying Oracle code and reusing fixes across customers in ways that exceeded the customers' license entitlements. A 2015 jury found copyright infringement, and the litigation continued through multiple appeals, a 2019 US Supreme Court ruling on the recovery of litigation costs, and a subsequent "Rimini II" phase that produced an injunction constraining specific practices.
The forensic point for buyers is what the case did not hold. It did not hold that third-party support is illegal. It did not hold that enterprises running Oracle software without Oracle support are infringing anything. It policed a provider's internal engineering practices. Rimini Street responded by re-architecting its delivery model so that fixes are developed within each client's own licensed environment, and the provider continues to operate at scale. The legal history is therefore a guide to provider due diligence, not a reason to stay on Oracle support.
The distinction that matters: "Is third-party support legal?" and "Did one provider's early engineering practices infringe copyright?" are different questions. Oracle's account teams answer the second and present it as the first. Hold them to the precise distinction.
The legal risk in third-party support is concentrated in the provider's fix-development and software-handling methods, not in the customer's decision to switch. The relevant question is whether the provider creates, tests and stores fixes in a way that respects each customer's specific license entitlements — or whether it copies Oracle software, reuses fixes across unrelated customers, or builds a shared library outside any single customer's licensed environment.
This is why the provider selection is the most consequential legal decision in the whole exercise. A provider that develops fixes inside your own environment, using your own entitlements, and does not transport Oracle code between clients, keeps you on the safe side of the line the courts have drawn. A provider that runs a shared, cross-customer fix factory reintroduces exactly the exposure the Rimini litigation examined.
| Risk area | Who controls it | How to neutralise it |
|---|---|---|
| Leaving Oracle support | You | No action needed — lawful under perpetual use rights |
| Fix-development method | The provider | Require fixes built inside your licensed environment |
| Cross-customer reuse of fixes | The provider | Contractually prohibit; require per-client development |
| Copying Oracle software | The provider | Confirm no Oracle code is downloaded or transported |
| License compliance gaps | You | Forensic compliance review before you switch |
| IP infringement claim | Shared | Written provider indemnification |
Short answer: No. A perpetual license grants ongoing use rights that survive the termination of any support contract. Stopping Oracle support reduces what Oracle delivers to you; it does not revoke the rights you already paid for. The breach risk lies in how fixes are made, not in the act of leaving.
Enterprises often assume that ending Oracle support somehow invalidates the underlying license. It does not. Support and license are separate entitlements under your Oracle agreements. The license is perpetual; the support is an annual service you may decline. When you decline it, you forfeit Oracle's patches, the My Oracle Support portal, and your right to download new versions — but your right to run the deployed software continues unchanged.
One genuine constraint deserves attention. Oracle's policies tie certain upgrade rights to an active support contract, so a future version upgrade may require you to reinstate Oracle support first. That is a roadmap-flexibility cost, not a license breach. It should be modelled into the decision, but it does not make leaving support unlawful. For the mechanics of coming back, see our analysis of Oracle support reinstatement fees.
Short answer: Switching does not breach any audit clause, but it does raise your audit probability. Customers who terminate Oracle support sit in a higher-risk category for an LMS audit letter, because Oracle has less commercial incentive to keep the compliance conversation cooperative. The audit tests license compliance — not the legality of third-party support.
Oracle's License Management Services (LMS) team can audit any customer under the audit clause in the Master Agreement. An LMS audit does not investigate whether third-party support is lawful — it cannot, because it is not — it measures whether your deployment exceeds your entitlements. The connection to third-party support is behavioural: terminating support removes Oracle's incentive to handle a compliance gap quietly, so a pre-existing gap that might have been negotiated softly becomes a hard back-license claim.
This is why the sequencing matters. A forensic compliance review before you notify Oracle lets you find and close any compliance gap while you still have a cooperative relationship and full portal access. Enterprises that switch with an unexamined license position hand Oracle the upper hand. Our Oracle compliance review service is routinely used as a pre-transition health check, and our Oracle audit defense guide sets out how to respond if a letter arrives anyway.
In our engagement data, customers who terminate Oracle support are materially more likely to receive an LMS contact within twelve months than the broader install base (Oracle Licensing Experts benchmark, 2026). That correlation is manageable, not disqualifying — it simply means a clean compliance position is a prerequisite, not an optional extra.
Before you notify Oracle, we forensically map your deployment against entitlements, close any compliance gap, and document a defensible position — so a support termination cannot be turned into a back-license claim. Buyer-side, always.
Not all third-party support providers carry the same legal profile. The two dominant Oracle-focused providers — Rimini Street and Spinnaker Support — have different litigation histories, and the structural question for buyers is identical in both cases: how does this provider build and store the fixes it ships to me?
Spinnaker Support has no major Oracle litigation history. Rimini Street has the litigation history described above and re-engineered its model so that fixes are developed within each client's own licensed environment. The practical due-diligence test is the same for any provider you evaluate: insist on a written description of where and how fixes are created, whether Oracle code is ever copied or transported, and whether any fix is reused across customers. The answers determine your exposure far more than the provider's brand. For a fuller side-by-side, see our three-way comparison of third-party support providers and our independent assessment of Spinnaker Support.
| Question to ask the provider | Low-risk answer |
|---|---|
| Where are fixes developed? | Inside the client's own licensed environment |
| Is Oracle software ever copied or downloaded? | No — client retrieves entitled software directly |
| Are fixes reused across customers? | No — each fix is developed per client |
| Do you indemnify against IP claims? | Yes — in writing, uncapped or high-limit |
| Have your current methods been litigated? | Either no, or model changed and operating |
Short answer: Four steps remove almost all practical exposure: choose a provider that builds fixes inside your licensed environment, secure written IP indemnification, close any compliance gap with a forensic review before you switch, and archive all entitled Oracle software and patches before portal access ends.
The legal risk in third-party support is real but bounded, and each element is controllable. Work through these steps before you serve a termination notice:
Executed together, these steps convert a topic Oracle frames as a minefield into a routine, defensible commercial decision. Our third-party support advisory manages all five on the buyer's side, and our Oracle negotiation guide shows how the credible option to switch also strengthens your hand in any Oracle support renewal.
Yes. Running Oracle software on a perpetual license without Oracle support is lawful, and contracting an independent provider for break-fix and regulatory updates is lawful. The Rimini Street v Oracle litigation never challenged the legality of third-party support itself — it concerned the specific methods one provider used to develop and store fixes.
The case found that Rimini Street's early support model infringed Oracle copyrights through unlawful copying of Oracle software, and a later injunction restricted specific fix-development practices. It did not rule that third-party support is illegal. Rimini changed its delivery model in response, and the provider continues to operate at scale.
No. Your perpetual license grants ongoing use rights that do not depend on an active Oracle support contract. The legal risk is not in leaving support; it is in how patches and fixes are created. A provider that develops fixes inside your own licensed environment, using your entitlements, keeps you on the safe side of the line.
Oracle can audit any customer under the audit clause in the Master Agreement, and customers who terminate support are statistically more likely to receive an LMS audit letter. The audit tests license compliance, not the legality of third-party support. A clean, forensic compliance position before you switch removes most of the exposure.
Choose a provider whose fixes are developed and held within your own licensed environment, get written indemnification for IP claims, close any compliance gap before terminating Oracle support, and archive all entitled software and patches from My Oracle Support before access ends. These four steps neutralise the practical legal risk.
No. Oracle's argument that third-party providers cannot deliver its quarterly Critical Patch Updates is a technical and security point, not a legal one. It affects your risk posture and regulatory compliance, but it has no bearing on the legality of using third-party support. Evaluate it on security grounds, separate from the legal question.
Weekly briefing on Oracle support strategy, third-party support developments and compliance risk — read by 2,000+ Oracle stakeholders at Fortune 500 enterprises.
Independent. Buyer-side. Not affiliated with Oracle Corporation.
25+ years · 600+ engagements · $1.8B Oracle spend advised · 38% avg cost reduction · 100% buyer-side · former Oracle insiders
We separate settled law from Oracle's deterrence tactics, vet your provider's engineering method, close any compliance gap before you switch, and manage the negotiation. No Oracle agenda. Pure buyer-side analysis.
Not affiliated with Oracle Corporation. 100% independent, buyer-side advisory.