|
By Pam Fulmer
Our earlier piece made two points that sit in tension. First, when a software vendor’s exclusive “repair or replace” remedy collapses, Article 2 of the Uniform Commercial Code may give a buyer a statutory path around contractual remedy limitations. See Cal. Com. Code § 2719. Second—and inconveniently—that doctrine applies only if Article 2 governs the transaction. A modern cloud ERP delivered as software-as-a-service may be characterized as a service rather than a sale of goods. If a court holds that the enterprise system was a service, the UCC’s cleanest tool may disappear with it. So, the natural question is: if the UCC is off the table, is the customer defenseless against a vendor’s one-sided agreement? No. California common law and the Civil Code supply a different set of tools. A 2025 California Supreme Court decision, New Eng. Country Foods v. Vanlaw Food Prod., Inc., 567 P.3d 63, 331 Cal. Rptr. 3d 890 (Cal. 2025), has made one of them--Civil Code Section 1668—considerably sharper. First, an Honest Concession There is no freestanding California common-law doctrine called “failure of essential purpose.” That phrase belongs to UCC Section 2-719 and its California counterpart, Commercial Code Section 2719. A customer cannot simply invoke it in a services case and expect the same statutory framework to apply. What California does have is a cluster of common-law and statutory doctrines that can accomplish some of the same practical work: freeing a customer from contractual limitations when the vendor’s conduct, or the collapse of the bargain, justifies relief outside ordinary capped contract damages. The key is to understand which tool gets you past the vendor’s damages cap. Ordinary breach doctrine may establish liability, but it often leaves a negotiated limitation-of-liability clause standing. Rescission, Civil Code section 1668, fraud, and unconscionability are the doctrines that attack the limitations themselves. Tool One: Rescission for Failure of Consideration The closest functional cousin to “you are not trapped by a remedy that failed” is rescission. A contract is extinguished by rescission. Cal. Civ. Code § 1688. A party may rescind where the consideration for its obligation fails, in whole or in part, through the fault of the other party, or where the consideration fails in a material respect before it is rendered. Cal. Civ. Code § 1689(b)(2), (b)(4). For a failed ERP, the theory is intuitive. The customer bargained for an operational, integrated system that would run core business functions. If the vendor never delivers a working system—go-live never occurs, the system is rolled back, or critical functions never work—the customer may argue that the consideration failed in a material respect. The strategic payoff can be significant. Rescission seeks to unwind the agreement rather than enforce it. If successful, the customer may obtain restitutionary relief and avoid contractual limitations that presuppose an enforceable contract. See Cal. Civ. Code § 1692. California courts recognize that rescission may support broader restorative relief designed to return the parties to their pre-contract positions. See Runyan v. Pacific Air Industries, Inc., 2 Cal. 3d 304 (1970). But the tradeoffs are real. Rescission requires prompt notice after discovering the facts entitling the party to rescind and generally requires restoration, or an offer to restore, what the rescinding party received. Cal. Civ. Code § 1691. It is also a different remedial posture from expectation damages: rescission is about unwinding the deal, not keeping the contract and recovering the full benefit of the bargain. For a customer that has sunk years and millions into a system it still wants fixed, that is a meaningful choice. Pleading rescission and damages in the alternative can preserve flexibility. Tool Two: Civil Code § 1668—and the 2025 VanLaw Decision The vendor’s most powerful weapons in a failed-implementation case are often its limitation-of-liability clause and consequential-damages waiver. California Civil Code Section 1668 is the most direct statutory answer to those provisions when the claim involves fraud, willful injury, or violation of law. Section 1668 provides that contracts having as their object, directly or indirectly, exemption from responsibility for one’s own fraud, willful injury to the person or property of another, or violation of law are against public policy. Cal. Civ. Code § 1668. Two California Supreme Court decisions are especially important. First, in City of Santa Barbara v. Superior Court, 41 Cal. 4th 747 (2007), the court held that an agreement purporting to release liability for future gross negligence is generally unenforceable as a matter of public policy. That rule does not depend on the transaction-by-transaction public-interest analysis used for ordinary negligence releases. Second, in New Eng. Country Foods v. Vanlaw Food Prod., Inc., 567 P.3d 63, 331 Cal. Rptr. 3d 890 (Cal. 2025), the California Supreme Court held that Section 1668 invalidates limitations on damages for willful injury to the person or property of another. The court rejected the argument that Section 1668 reaches only complete exculpation clauses and not damages limitations. It also rejected a case-by-case exception based on the parties’ sophistication or commercial bargaining context. VanLaw matters because many vendor agreements do not say, “we are not liable for intentional wrongdoing.” They instead cap damages, exclude lost profits, and bar consequential or punitive damages. VanLaw confirms that, at least for willful injury within section 1668, a clause that substantially limits damages can be invalid even if it does not eliminate every theoretical remedy. The implications for ERP litigation are substantial. If the customer can establish a qualifying independent tort—such as intentional misrepresentation, intentional interference, or other willful injury—or a qualifying violation of law, the vendor’s damages cap and consequential-damages waiver may be unenforceable as to that claim. That result is UCC-independent: it does not matter whether the ERP is classified as a good or a service. But the limitation is equally important. Section 1668 does not turn an ordinary breach of contract into an uncapped tort case. VanLaw expressly preserved the distinction between breach of contract and violation of an independent duty. The court stated that Section 1668 does not preclude parties from limiting liability for pure breaches of contract absent violation of an independent duty within the statute’s scope. Recent California authority also continues to police that boundary through the economic loss rule. See Rattagan v. Uber Technologies, Inc., 553 P.3d 1213, 324 Cal. Rptr. 3d 433 (Cal. 2024); Robinson Helicopter Co., Inc. v. Dana Corp., 34 Cal. 4th 979 (2004). The practical upshot is that the Section 1668 route demands real tort or statutory-duty facts. A disappointing system is not enough. A concrete pre-sale misrepresentation, concealment, willful injury, gross negligence, or qualifying statutory violation may be. Tool Three: Fraudulent Inducement Fraud is both a claim in its own right and a gateway to the tools above. ERP sales cycles are full of representations: capability demos, “it does that out of the box,” implementation timelines, integration promises, industry-fit assurances, and statements about the vendor’s experience with comparable deployments. Where those representations were false, material, and relied upon, fraudulent inducement can support rescission and can also bring section 1668 into play. The fraud claim must be pleaded and proved with discipline: the specific statement, the speaker, the timing, the falsity, the customer’s reliance, and resulting harm. California law supports the general principle that limitation-of-liability clauses do not protect fraud. In Food Safety Net Servs. v. ECO Safe Sys. USA, Inc., 209 Cal. App. 4th 1118 (2012), the court stated that limitation-of-liability clauses are ineffective as to fraud and misrepresentation under section 1668. But Food Safety is also a cautionary case: the fraud claim failed because the plaintiff did not establish tortious conduct independent of the contract, and the economic loss rule barred repackaging contract nonperformance as fraud. That is the lesson for ERP disputes. Fraud framed as generalized disappointment will not survive. Fraud tied to concrete, provable, extra-contractual or pre-contractual misrepresentations may unlock rescission, section 1668, and uncapped tort remedies. Tool Four: Unconscionability Under Civil Code § 1670.5 Unconscionability is not a UCC-only concept. California’s general unconscionability statute empowers courts to refuse to enforce an unconscionable contract or clause, or to limit its application to avoid an unconscionable result. Cal. Civ. Code § 1670.5. The familiar framework has both procedural and substantive components. Procedural unconscionability focuses on oppression or surprise, often from unequal bargaining power or non-negotiable form terms. Substantive unconscionability focuses on overly harsh or one-sided terms. A limitation clause that leaves the customer with no meaningful remedy for a total implementation failure may be a candidate for substantive unconscionability. The caveat is that unconscionability is an uphill fight between sophisticated commercial parties negotiating a major enterprise deal. California courts generally enforce limitation-of-liability clauses in ordinary commercial contracts unless a doctrine such as unconscionability, section 1668, or public policy applies. Food Safety illustrates that point: the court enforced a limitation clause against contract and ordinary-negligence theories where the plaintiff did not show unconscionability or a public-interest basis to invalidate it. Unconscionability is therefore best treated as a supporting theory, especially where the vendor’s terms were genuinely non-negotiable, the cap is illusory, or the remedy structure leaves the customer with no practical recourse for catastrophic failure. Tool Five: Material Breach—and Why It Is Not Enough on Its Own Common law has its own concept of a failure so serious that it excuses further performance: material breach. In a failed ERP case, the customer may argue that the vendor’s failure to deliver a functioning system was a material breach that discharged the customer’s remaining obligations and supported damages. But this doctrine does not, by itself, defeat a limitation-of-liability clause. Limitation clauses are drafted for breaches; that is their purpose. California courts generally enforce them in ordinary commercial settings unless a separate doctrine attacks the clause itself. That is why material breach supplies the liability theory, but rescission, section 1668, fraud, and unconscionability do the cap-defeating work. A customer should not assume that proving a catastrophic breach automatically means recovering uncapped consequential damages. The Balance Sheet Compared with the UCC path, the common-law playbook has disadvantages worth stating plainly. There are no UCC implied warranties if Article 2 does not apply. The customer must rely on express contractual promises, tort duties, statutory doctrines, and equitable remedies. Section 1668 requires more than a breach; it requires fraud, willful injury, violation of law, or another qualifying independent duty. The economic loss rule limits attempts to repackage disappointed contractual expectations as tort claims. Rescission requires prompt action and may force a strategic election. Unconscionability is difficult between sophisticated parties. But the advantages are real. These doctrines do not depend on proving that a cloud ERP is a “good.” Rescission can unwind the contract. Section 1668 can invalidate damages limitations for qualifying fraud, willful injury, or statutory-duty claims. And after VanLaw, a vendor cannot save a damages cap merely by arguing that the clause leaves some theoretical remedy in place. A Practical Playbook Plead in the Alternative and Preserve Rescission Early Preserve breach-of-contract damages, but plead rescission promptly where the facts support a material failure of consideration. Delay can waive rescission, so the remedy should not be an afterthought. Build the Fraud Record From Day One Collect demos, RFP responses, implementation promises, capability matrices, sales emails, and executive assurances. The question is not just whether the project failed; it is whether the vendor made a specific false representation or concealment that induced the deal. Frame Independent Torts Carefully To survive the economic loss rule, identify duties and conduct independent of the contract. Do not rely on artful relabeling of missed milestones or defective performance. Tie tort claims to misrepresentation, concealment, willful injury, or other conduct recognized as independent under California law. Use Section 1668 Where the Claim Qualifies After VanLaw, Section 1668 should be front and center when the customer has a genuine intentional tort or willful-injury theory. It should not be overused for ordinary breach. Its power comes from matching the doctrine to the facts. Negotiate Express Warranties on the Front End Because implied UCC warranties may not apply, buyers should negotiate express warranties and objective commitments: acceptance criteria, go-live conditions, data-migration accuracy, integration requirements, uptime, response times, project staffing, and remedies that are meaningful even if Article 2 never applies. Watch the Choice-of-Law Clause California’s Civil Code Section 1668 and VanLaw are favorable to customers with qualifying tort or statutory-duty claims. A vendor’s out-of-state governing-law clause may materially change the analysis. Bottom Line The UCC gives a wronged software buyer one clean, well-worn statutory doctrine. California common law and the Civil Code give the buyer a more complex toolkit: rescission, Section 1668, fraud, unconscionability, and material breach.. For SaaS deals that dominate enterprise buying today, that distinction is no longer academic. And after VanLaw, a vendor’s limitation clause is more vulnerable when the customer can plead and prove genuine intentional wrongdoing or another independent duty within section 1668. The customer whose implementation was sold on promises the vendor could not—or never intended to—keep may have a viable path outside the UCC. But the path must be built deliberately, with facts that attack the limitation clause itself rather than merely proving that the project failed. This article is provided for general informational purposes only and does not constitute legal advice or create an attorney-client relationship. The doctrines discussed are fact-intensive and continue to develop. The availability of rescission, the reach of Civil Code section 1668 after VanLaw, and the operation of the economic loss rule all turn on the specific contract and conduct at issue. Companies facing a cloud ERP dispute should consult qualified counsel.
0 Comments
By Pam Fulmer
Is Your Cloud ERP Even Governed by the UCC? When an enterprise software implementation goes sideways, a customer’s lawyers often reach for the Uniform Commercial Code. Implied warranties of merchantability and fitness. Perfect tender. And the failed-remedy rule: when an exclusive or limited remedy fails of its essential purpose, the buyer may be able to reach the Code’s default remedies. See Cal. Com. Code § 2719; RRX Industries, Inc. v. Lab-Con, Inc., 772 F.2d 543 (9th Cir. 1985). There is a threshold problem that a surprising number of complaints skate past: those tools live in Article 2 of the UCC, and Article 2 governs transactions in goods. For delivered, licensed, on-premise software of the 1990s and 2000s, that was a fight worth having and often winnable. For the cloud ERP that dominates enterprise buying today—Oracle Fusion, Workday, SAP S/4HANA Cloud, NetSuite, Dynamics 365—the answer is far less certain and may well be no. A customer who builds its entire case on the UCC without first confirming that the UCC applies is building on sand. This piece explains why the goods-versus-services question has become central in modern ERP disputes, why software-as-a-service (SaaS) is hard to fit inside Article 2, and what sophisticated buyers should do about it. Why Classification Can Decide the Case The stakes of classification are not academic. If a transaction is governed by Article 2, the buyer may have access to the UCC’s buyer-protective architecture: implied warranties that attach unless effectively disclaimed, a demanding tender standard, and statutory remedies when an agreed remedy fails. If the transaction is governed instead by common law service-contract principles, the buyer may face a different regime: no implied warranty of merchantability, no Article 2 perfect-tender rule, and no statutory failure-of-essential-purpose provision. That does not mean common law leaves the buyer without remedies. It does mean the buyer’s path is different, and the vendor’s carefully drafted limitations may be harder to dislodge. The same failed implementation can therefore produce very different outcomes depending on a classification question the parties may never have consciously negotiated. That is why cloud vendors increasingly draft around the issue. Their forms often characterize the offering as “services,” confirm that the provider retains ownership of the software, and state that the customer receives only access rights—not delivery, title, or possession of a copy. Those labels are not automatically controlling, but they are important evidence of the transaction the parties made. The Framework: Goods, Sales, and Predominant Purpose Two threshold requirements must be satisfied before Article 2 governs, and cloud software strains both. First, the subject matter must be goods—defined in California as “all things ... which are movable at the time of identification to the contract for sale.” Cal. Com. Code § 2105. Second, there must be a sale, which the Code defines as the passing of title from seller to buyer for a price. Cal. Com. Code § 2106. A transaction that confers only a right to access or use software, without transferring title or a copy, sits uneasily inside that definition. When a contract blends goods and services—as nearly every enterprise software deal does—courts generally ask which aspect predominates. The classic formulation asks whether the contract’s predominant factor, thrust, or purpose is the rendition of services with goods incidentally involved, or a transaction of sale with labor incidentally involved. Bonebrake v. Cox, 499 F.2d 951, 960 (8th Cir. 1974). California courts apply a similar essence-of-the-transaction analysis. See Ventures v. SVC–W., L.P., 202 Cal. App. 4th 1483, 1502–03 (2012). The classification inquiry is typically contract-wide. If services predominate, common law—not Article 2—will generally govern the contract, including the software component. Why SaaS Is Different From the Software the Case Law Was Built On Much of the software-as-a-good precedent comes from a world of delivered products. Courts held that software could be treated as a good where something was delivered or transferred: a disk, a copy, a bundled hardware-and-software system, or a standardized software product. The leading example is Advent Systems Ltd. v. Unisys Corp., 925 F.2d 670 (3d Cir. 1991), which held that software was a “good” under the UCC where the contract’s main objective was the transfer of software and related products, with training and support treated as ancillary. The Ninth Circuit reached a similar result in RRX Industries, Inc. v. Lab-Con, Inc., 772 F.2d 543 (9th Cir. 1985), holding that the sales aspect of a software-system transaction predominated and that employee training, repair services, and upgrades were incidental to the sale of the software package. RRX is also important for remedies: applying California Commercial Code section 2719, the court affirmed consequential damages where the seller’s default was sufficiently total and fundamental that the limitation failed. But RRX should not be overread. It involved an installed software system in the 1980s, not a modern cloud-access subscription. SaaS changes the premise. In a true cloud ERP subscription, the customer usually receives no disk, no download, no executable, no object code, and no title to a copy. The customer receives a time-limited right to access software running on the vendor’s infrastructure, often priced by users, modules, or consumption. When the subscription ends, access ends. That structure creates problems on both Article 2 prongs. On the “goods” prong, there may be no movable thing delivered to the customer. On the “sale” prong, there may be no transfer of title. Some courts have applied Article 2 to software licenses, but the more cloud-like the transaction becomes, the harder it is to describe it as a sale of goods. Marquette University v. Kuali, Inc., 584 F. Supp. 3d 720 (E.D. Wis. 2022), is the modern SaaS decision buyers and vendors both should know. Applying Wisconsin law, the court accepted that the software underlying Kuali Research Cloud could be a good, and it accepted for purposes of analysis that the agreement included a sale. But it held that the contract was predominantly for services because Marquette paid for hosted access, maintenance, backups, updates, support, and the infrastructure needed to use the software—not primarily for a transferred software copy. Because services predominated, the UCC did not apply, and the contract’s remedy and damages limitations controlled. That reasoning maps naturally onto many cloud ERP subscriptions. The customer may care about the software functionality, but what it buys is often the vendor’s continuing operation of a hosted environment: access, uptime, maintenance, security, updates, integrations, and support. Those are service-like features, not the transfer of a movable chattel. The Law Is Unsettled—and the Facts Matter None of this means the UCC argument is dead. The authority is mixed, and the outcome depends heavily on the structure of the transaction, the governing law, and the factual record. A buyer has its best Article 2 argument when the deal involves standardized software, a meaningful delivered or downloadable component, or a contract whose economic center is the transfer of software functionality rather than ongoing vendor labor. Cases such as Advent and RRX remain useful for that proposition. The vendor has its best common-law argument when the contract is framed as a subscription service, the customer receives access rather than possession, the vendor retains title and operational control, and the customer pays materially for hosting, maintenance, configuration, support, and implementation. Kuali is the strongest modern SaaS example. California-specific authority also supports a careful, fact-based approach. In Tk Power, Inc. v. Textron, Inc., 433 F. Supp. 2d 1058 (N.D. Cal. 2006), the court applied common law rather than the UCC to a transaction involving prototype development because the essence of the agreement was development work—knowledge, skill, and ability—not the sale of finished goods. The court contrasted RRX, where the software sale predominated, with transactions centered on custom development. Other courts have drawn similar lines in technology disputes. In Conwell v. Gray Loon Outdoor Marketing, 906 N.E.2d 805 (Ind. 2009), the Indiana Supreme Court held that the UCC did not govern a website-design and hosting relationship because the arrangement involved custom design and ongoing hosting services, not a conventional transaction in tangible goods. The better formulation, then, is not that “software is a good” or “SaaS is a service.” The better formulation is: delivered, standardized software is often treated as a good; custom development, hosted access, and SaaS subscriptions often create stronger service-contract arguments. The Implementation Layer Makes the Goods Argument Harder Modern ERP deals rarely stop at a subscription. They often bundle implementation: configuration, data migration, integration, testing, change management, and training. These services may be performed by the vendor, a systems integrator, or both, and they may cost as much as—or more than—the subscription itself. Under the predominant-purpose test, that implementation layer matters. The more the buyer pays for the vendor’s labor, expertise, configuration, and project execution, the easier it is for the vendor to argue that services predominate. The irony is sharp: the more comprehensive and hands-on the vendor’s involvement—the very thing a customer wants when buying a mission-critical system—the harder it may become to characterize the transaction as the acquisition of a good. A deal in which the customer receives no delivered software copy, no title, and substantial implementation labor is difficult to shoehorn into Article 2. That does not make the UCC argument impossible. It does mean the argument must be pleaded and supported deliberately. What Sophisticated Buyers Should Do The practical response is not to abandon UCC theories. It is to stop depending on them and build a case that survives either classification. Plead in the Alternative Preserve the goods argument where the facts support it—especially for standardized suites, delivered components, downloadable modules, or arrangements where software functionality is the economic center of the deal. But assume the vendor will argue that the transaction is a service, and make sure the complaint survives if the court agrees. Build UCC-Independent Theories From Day One Fraud, negligent misrepresentation, and other pre-contractual representation theories do not depend on Article 2. ERP sales cycles often include capability representations, implementation assurances, timeline commitments, and integration promises that may support claims independent of the UCC. In California, Civil Code § 1668 provides that contracts that exempt a party from responsibility for its own fraud, willful injury, or violation of law are against public policy. That statute can be important when a vendor invokes limitation-of-liability language against fraud-based claims, regardless of whether the transaction is classified as goods or services. Negotiate Express Warranties Because Implied Ones May Never Attach If the transaction is classified as a service, implied UCC warranties may not apply. Buyers should negotiate explicit contractual warranties instead: implementation milestones, defined acceptance criteria, uptime commitments, integration obligations, performance standards, data-migration requirements, and meaningful remedies if the system does not work. Draft Remedies That Work Outside the UCC Do not rely solely on section 2719. A buyer should negotiate remedies that are enforceable as contract terms even if Article 2 never applies: refund rights, service credits that are not the exclusive remedy, termination rights, milestone holdbacks, fee clawbacks, audit rights, and carveouts from damages exclusions for mission-critical failures, data loss, security breaches, fraud, willful misconduct, and confidentiality breaches. Mind Choice-of-Law and Forum Clauses The goods-versus-services question can turn on governing law. Some jurisdictions are more receptive than others to treating software as a good; others focus more heavily on hosting, customization, and services. A vendor’s governing-law clause may therefore shape the classification fight before the dispute begins. Read the Vendor’s Characterization—and Rebut It Deliberately If the agreement says the offering is a “service,” states that the provider retains all rights in the software, disclaims delivery of any copy, and limits the customer to access rights, expect the vendor to rely on that language. If the buyer intends to invoke Article 2, it should develop a record showing why the transaction’s substance was the acquisition of software functionality rather than the purchase of labor or hosted operations. Bottom Line For a generation, “the software failed, so the UCC lets us past the vendor’s limitations” was a powerful opening move. In the cloud era, that move depends on a threshold question with an increasingly uncomfortable answer: a pure SaaS ERP subscription, especially one bundled with substantial vendor-led implementation, may fall outside Article 2 entirely. The sophisticated posture is not to assume the UCC applies, nor to concede that it does not. It is to recognize that the question is unsettled, litigate it deliberately where the facts support it, and—above all—build a case that does not collapse if the court decides the enterprise system was a service all along. This article is provided for general informational purposes only and does not constitute legal advice or create an attorney-client relationship. The classification of cloud and SaaS transactions under the UCC remains fact- and jurisdiction-specific. Companies facing a cloud software dispute should consult qualified counsel about their particular contract and circumstances. Breaking the Cap: Fraud in the Inducement in Failed Oracle Fusion and other ERP Implementations7/11/2026 By Pam Fulmer When a nine-figure ERP transformation collapses, the vendor’s limitation-of-liability clause is usually the whole ballgame. Here is how a well-pleaded fraud claim can get you past it — under California law, and in the two other jurisdictions where these disputes often land. Every large enterprise software dispute eventually comes down to the same question, and it is rarely the one the client expects. The client wants to talk about whether Oracle Fusion Cloud actually delivered the manufacturing or payroll functionality that was promised, or whether SAP’s S/4HANA rollout ever came close to going live. Those are the merits. But the number that decides whether the case is worth bringing — and whether it settles for real money — is buried in a boilerplate paragraph near the back of the Master Agreement: the limitation of liability. In a failed $30 million transformation, the cap is the ballgame. If the vendor’s limitation clause holds, the customer’s recovery is contractually squeezed down to the fees paid under the order form, with all consequential and “indirect” damages waived. The wasted internal labor, the second implementation, the lost efficiencies, the emergency consultants brought in to keep the lights on — none of it counts. A customer that spent $18 million and got nothing may find its recovery capped at a few million, minus what it still “owes.” The single most effective way past that cap is a properly pleaded, well-supported claim for fraud in the inducement, if the customer believes the vendor made misrepresentations to induce the contract and has the evidence to support it. Fraud is not just another count to pile onto the complaint. In the right posture it does two things at once: it opens the door to tort and out-of-pocket damages that the contract tried to foreclose, and — critically — it can render the limitation-of-liability clause itself unenforceable as to the fraudulent conduct. This article explains the mechanics, with California as the primary focus and New York and Massachusetts as the two other jurisdictions where enterprise software disputes frequently end up. Why the cap is the battlefield Oracle’s and SAP’s enterprise agreements are drafted by very good lawyers to do one thing above all: convert a potentially catastrophic delivery failure into a bounded, budgetable liability. The tools are familiar. Oracle’s cloud contracts — the Oracle Master Agreement and the Fusion Cloud Service order documents — pair a damages cap, typically pegged to fees paid over some trailing period, with a sweeping waiver of indirect, special, incidental, and consequential damages, and a disclaimer of lost profits. They are frequently accompanied by an integration or merger clause and, in financed deals, a payment agreement assigned to a third-party lender through Oracle Credit Corporation. SAP’s agreements follow a similar architecture around its software license and cloud/RISE subscription terms. The result is a structural mismatch. A customer’s real-world loss from a failed enterprise implementation is dominated by exactly the categories the contract waives — consequential damages, lost productivity, and the cost of a replacement system. The cap is engineered so that the customer’s provable “direct” damages are a fraction of its true loss. Litigating the breach alone, in other words, is often a losing economic proposition even when liability is clear. That is precisely why the analysis has to start with the cap, not the breach — and why fraud is the lever, provided the customer has real facts to support the claim. The fraud lever: an independent wrong the contract did not price The intuition behind every fraud-based attack on a liability cap is the same across jurisdictions: parties are presumed to have allocated the ordinary risks of performance in their contract, but no one bargains for the right to be lied to. A limitation clause allocates the risk that the software underperforms. It does not, as a matter of public policy in many commercial jurisdictions, allocate the risk that the vendor knowingly misrepresented the software’s capabilities to win the deal in the first place. The evidentiary heart of these cases is almost always the pre-contract sales cycle: the demos, the “solution overviews,” the RFP responses, the emails assuring the customer that the platform will handle its industry “out of the box,” that go-live will happen on a fixed timeline for a fixed price, that little or no customization is required, and that third-party add-ons will not be needed. When the executed order form then describes only components — and omits the capability that was the whole reason for the purchase — the gap between what was sold and what was signed is where the fraud claim lives. California: the primary jurisdiction California is where a large share of these disputes are filed, as many companies including Oracle are present here, and California law is comparatively favorable to defrauded customers. Three doctrinal pillars matter. 1. The economic loss rule does not bar fraud independent of the breach California’s economic loss rule generally bars tort recovery for purely economic losses between contracting parties. But it does not bar an intentional fraud claim based on conduct independent of the breach. In Robinson Helicopter Co. v. Dana Corp., 34 Cal. 4th 979, (2004), the California Supreme Court allowed fraud-based tort remedies where the defendant’s affirmative misrepresentations were independent of the mere failure to deliver conforming goods. The Court reasoned that no rational party enters a contract expecting to be defrauded, and that allowing the economic loss rule to swallow intentional fraud would reward dishonesty. For years, defendants argued that Robinson Helicopter was narrow and confined to affirmative misrepresentations that exposed the plaintiff to personal-injury-type liability. The Supreme Court closed much of that gap in Rattagan v. Uber Technologies, Inc., 17 Cal. 5th 1, (2024). Rattagan confirms that fraudulent concealment arising from or related to contract performance may also sound in tort where the concealment can be established independently of the parties’ contractual obligations and exposes the plaintiff to a risk beyond what the parties reasonably contemplated at contracting. Read together with Lazar v. Superior Court, 12 Cal. 4th 631, (1996), which recognizes tort remedies for fraudulent inducement, and consistent with Erlich v. Menezes, 21 Cal. 4th 543, 981 P.2d 978, 87 Cal. Rptr. 2d 886 (1999), which insists on an independent tort duty before contract claims become tort claims, Rattagan confirms that both affirmative misrepresentations and knowing concealment in the ERP sales cycle can sound in tort. That matters because tort framing is what unlocks out-of-pocket damages and, in egregious cases, punitive exposure that the contract’s damages waiver may not reach. The important limit, reaffirmed in Sheen v. Wells Fargo Bank, N.A., 12 Cal. 5th 905, (2022), is that the tort must be genuinely independent of the broken promise. A repackaged breach — “they promised the software would work and it didn’t” — will not clear the bar. The claim has to rest on a knowing misrepresentation of then-existing fact or a concealed material fact, pleaded with the specificity California fraud pleading demands. 2. Civil Code section 1668 can void the cap itself — even for sophisticated parties This is the development that has changed the leverage in these cases. Cal. Civ. Code § 1668 provides that all contracts that have as their object, “directly or indirectly,” the exemption of anyone from responsibility for their own fraud or willful injury are against the policy of the law. For decades, courts disagreed about whether section 1668 voided only total releases or also reached clauses that merely limited liability. In New England Country Foods, LLC v. Vanlaw Food Products, Inc., 17 Cal. 5th 618, (2025), answering a question certified by the Ninth Circuit, the California Supreme Court resolved the split: Section 1668 invalidates contractual provisions that substantially limit damages for willful injury to person or property, even where the clause is framed as a limitation of liability rather than a complete release. The Court rejected a broad sophisticated-party exception, while preserving ordinary contractual limitations for non-willful breach-of-contract claims. Earlier authority, including Food Safety Net Services v. Eco Safe Systems USA, Inc., 209 Cal. App. 4th 1118, (2012), points in the same direction for fraud-based claims. The practical significance is hard to overstate, but it should be stated precisely. Where the customer can plead and ultimately prove intentional fraud or willful injury within section 1668’s scope — as opposed to a garden-variety breach — the vendor’s fees-paid cap and consequential-damages waiver cannot be used to substantially exempt the vendor from responsibility for that conduct. New England Country Foods was careful to preserve the enforceability of caps for ordinary breach of contract; the statute reaches intentional wrongs within its ambit, not ordinary contract disappointment. So the fraud claim is not just a route to bigger damages. It is the mechanism that can dissolve the cap as to the fraudulent or willful conduct. 3. The integration clause is not the wall the vendor thinks it is Vendors routinely argue that the contract’s merger or integration clause bars any reliance on pre-contract sales representations. In California, the fraud exception to the parol evidence rule answers that argument. Riverisland Cold Storage, Inc. v. Fresno-Madera Production Credit Ass’n, 55 Cal. 4th (2013), overruled the old Pendergrass limitation and confirmed that a party may introduce extrinsic evidence of fraudulent representations to establish fraud in the inducement, even where those representations contradict the written agreement. An integration clause does not immunize a vendor from proof of the promises its salesforce actually made. How this looks in real Oracle litigationThese are not abstractions. A wave of California suits and filings has tested variations of this theory against Oracle’s ERP, HCM, and cloud products. The recurring allegations are familiar: the customer contends that Oracle or its implementation partner misrepresented product capabilities, downplayed the customization required, overstated the partner’s expertise, or promised functionality that did not appear in the executed order documents. In that posture, the breach claim may be vulnerable if the final contract does not actually require the configured, workable solution the customer thought it was buying. The fraud claim, by contrast, may remain viable if the customer can identify specific pre-contract misrepresentations of then-existing fact, the speakers, the timing, reliance, and resulting damage. Recent Oracle and NetSuite disputes illustrate the pattern at the pleading level. Customers have alleged that sales representatives made specific pre-contract promises that a system was tailored to the customer’s industry, would require little or no third-party functionality, or would support critical business requirements. Those allegations are typically paired with breach, fraudulent misrepresentation, negligent misrepresentation, and, in California cases, claims under California’s Unfair Competition Law, Cal. Bus. & Prof. Code § 17200. The lesson is not that every failed implementation becomes fraud. It is that the decisive facts often live in the sales record, not the project plan. The exposure is not limited to NetSuite. Public reporting around failed large-scale Oracle Fusion and SAP programs shows how an enterprise implementation can fail at scale, leaving the customer with impaired operations, a costly remediation project, and losses that ordinary contract caps are designed to exclude. Those examples are useful business context, but they should be distinguished from legal authority. The legal question remains whether the customer can plead and prove fraud or willful misconduct independent of the contract breach. One California-specific trap should be flagged at the outset. Many Oracle deals are financed through Oracle Credit Corporation, with the payment agreement then assigned to a third-party bank. Those financing agreements may contain waiver-of-defenses language governed by UCC Article 9, including Cal. Com. Code § 9403, which can materially affect the customer’s ability to assert software-related defenses against an assignee. The fraud strategy therefore has to account for the financing structure from day one, not after the bank seeks payment. New York: the sophisticated-party jurisdiction New York is the other dominant forum for enterprise software disputes, and its law is meaningfully less forgiving than California’s. The starting presumption favors enforcement. In Metropolitan Life Insurance Co. v. Noble Lowndes International, Inc., 84 N.Y.2d 430, 643 N.E.2d 504, 618 N.Y.S.2d 882 (1994) — itself a software development and installation dispute — the Court of Appeals enforced a negotiated limitation of liability where the vendor’s deliberate, economically motivated refusal to perform was not enough to defeat the cap absent proof of fraud, malice, or other truly willful tortious conduct. New York courts generally hold sophisticated parties to their negotiated risk allocation. The public-policy exception is real but demanding. Under Kalisch-Jarcho, Inc. v. City of New York, 58 N.Y.2d 377, 461 N.Y.S.2d 746 (1983), and related authorities including Sommer v. Federal Signal Corp., 79 N.Y.2d 540, 593 N.E.2d 1365, 583 N.Y.S.2d 957 (1992), a limitation or exculpatory clause generally will not shield conduct that is grossly negligent, willful, or in bad faith. But Colnaghi, U.S.A., Ltd. v. Jewelers Protection Services, Ltd., 81 N.Y.2d 821, 611 N.E.2d 282, 595 N.Y.S.2d 381 (1993), illustrates how high that bar is: gross negligence requires conduct that evinces reckless disregard for the rights of others or smacks of intentional wrongdoing. Fraud in the inducement, well pleaded, is the archetypal conduct that may clear this bar. Ordinary breach, and even deliberate nonperformance for economic reasons, usually does not. The distinctive New York battleground is the anti-reliance clause. Under Danann Realty Corp. v. Harris, 5 N.Y.2d 317, 157 N.E.2d 597, 184 N.Y.S.2d 599 (1959), a specific disclaimer of reliance — a provision in which the buyer represents that it did not rely on any representations outside the four corners of the agreement as to the very matter later alleged to be misrepresented — can defeat a fraudulent inducement claim. A general merger clause, by contrast, does not. The line between the two frequently decides these cases at the motion-to-dismiss stage, which is why the precise wording of the vendor’s “no reliance” language must be scrutinized before filing. There is a crucial but fact-specific escape hatch. Even a specific disclaimer may not bar a fraud claim where the misrepresented facts were peculiarly within the defendant’s knowledge and not discoverable through ordinary diligence. Basis Yield Alpha Fund (Master) v. Goldman Sachs Group, Inc., 115 A.D.3d 128, 980 N.Y.S.2d 21 (1st Dep’t 2014), is useful on that point. In the ERP context, internal defect logs, failed reference implementations, and internal engineering assessments may be candidates for peculiar-knowledge treatment, but the issue will turn on the precise disclaimer language and what diligence was realistically available to the customer. And throughout, New York’s heightened pleading standard, N.Y. C.P.L.R. 3016(b), means the fraud must be alleged with particularity: the specific statements, speakers, and circumstances, not conclusory labels. Massachusetts: Chapter 93A as a damages multiplier Massachusetts deserves its own analysis because it offers a statutory route that can be even more powerful than common-law fraud. Mass. Gen. Laws ch. 93A, § 11 prohibits unfair or deceptive acts in trade or commerce between businesses and authorizes recovery of double or treble damages plus attorneys’ fees for willful or knowing violations. Deceptive pre-contract representations of the kind at issue in ERP disputes are classic Chapter 93A conduct. Decisively, in H1 Lincoln, Inc. v. South Washington Street, LLC, 489 Mass. 1, 179 N.E.3d 545 (2022), the Supreme Judicial Court held that a contractual limitation-of-liability provision will not be enforced to protect a defendant who willfully or knowingly engages in unfair or deceptive conduct prohibited by Chapter 93A. The Court reasoned that the statute’s punitive and deterrent purposes cannot be overridden by private risk allocation, even among sophisticated parties, and even where the clause purports to waive consequential damages — the very category into which Chapter 93A multiple damages fall. The Court declined to let the older, more permissive analysis of Canal Electric Co. v. Westinghouse Electric Corp., 406 Mass. 369, 548 N.E.2d 182 (1990), shield willful violators, and distinguished the tort/contract analysis in Standard Register Co. v. Bolton-Emerson, Inc., 38 Mass. App. Ct. 545, 649 N.E.2d 791 (1995). Massachusetts also has directly relevant software authority. In VMark Software, Inc. v. EMC Corp., 37 Mass. App. Ct. 610, 642 N.E.2d 587 (1994), the Appeals Court affirmed misrepresentation-based relief arising from assurances about software functionality, while declining multiple damages on the facts. The lesson is familiar: the quality of the misconduct — merely misleading versus willful or knowing — drives both whether contractual limitations yield and whether damages multiply. Two practical cautions. First, a section 11 claim requires that the unfair or deceptive conduct occurred “primarily and substantially” within Massachusetts; courts examine the center of gravity of the misconduct, and an out-of-state vendor will press this hard. Second, a defendant can blunt the multiplier by making a reasonable single-damages settlement offer with its answer, so the timing and content of pre-suit Chapter 93A demand letters and early settlement posture genuinely affect the exposure. Practical takeaways for enterprise customers and their counsel The through-line across all three jurisdictions is that the fraud claim, not the breach claim, is what can make a failed enterprise implementation economically worth litigating. To preserve it:
Celonis v. SAP Update: What Celonis's Proposed Second Amended Complaint Adds to the Lawsuit5/11/2026 By Pam Fulmer
On May 2, 2026, Celonis filed a motion in Celonis SE v. SAP SE, Case No. 3:25-cv-02519-VC (N.D. Cal.), for leave to file a Second Amended Complaint. The proposed pleading — running 117 pages — has not yet been approved by Judge Vince Chhabria, but it is publicly filed and worth reading. Stripped of the antitrust framing, the proposed complaint is a detailed account of an enterprise software vendor squeezing its installed base. Here is what is alleged, organized by what is happening to the customer rather than by claim. The Customer Owns the Data, But Cannot Get to It Celonis alleges that SAP's own General Terms and Conditions for Cloud Services confirm that customers own their enterprise data. The data resides in the customer's instance of the SAP ERP system, often on the customer's own servers. Celonis's process-mining tool reads that data from the customer's environment. SAP is not in the path. Notwithstanding that ownership structure, the proposed complaint walks through a sequence of SAP technical notes — each of which incrementally narrowed how a customer could extract its own data for use with a non-SAP tool. Celonis alleges that after the sequence of changes, only two extraction pathways remain technically permitted: OData, which SAP has withdrawn support for, and Datasphere, an SAP product that the complaint alleges carries fees so high that using it as an extraction conduit to a non-SAP tool is commercially infeasible — sometimes exceeding the cost of the third-party tool itself. The customer-side picture this paints is a familiar one. A customer that purchased SAP ERP under a set of expectations about its ability to work with the third-party tools of its choice has watched those expectations narrow through a succession of vendor-published technical notes the customer never specifically agreed to. The customer's contract did not change. The technical implementation of the customer's contract did. SAP Allegedly Lied to its Customers to Get Them to Stop Using a Vendor They Liked The most operationally consequential allegations in the proposed amended complaint are the false-statement allegations. Celonis identifies — by individual SAP employee, by date, by customer, and by substance — specific communications in which SAP told joint customers that using Celonis would violate license terms, require purchase of additional database or HANA full-use licenses, render the customer non-compliant with SAP policy, or imperil S/4HANA migration. The proposed pleading references internal SAP materials that, according to Celonis, instructed SAP account teams to make these statements on a "case-by-case basis" and to avoid any "general compliance campaign" or "public communications" — a directive Celonis cites as evidence that SAP itself recognized the statements were problematic. For the customers on the receiving end of those conversations, the experience was not abstract. The proposed complaint reflects customer inquiries to Celonis in which the customer reported being told its current extraction processes were "no longer permitted," asked Celonis whether it was "in compliance with SAP requirements," reported having been "warned" about future problems with Celonis after migrating to S/4HANA, and asked whether SAP would "want to charge us" for the data connection. One customer told Celonis that as a result of what SAP had communicated, the customer "may be unable to implement Celonis" on its S/4HANA instance. Another reduced its Celonis contract because of its understanding that the Celonis approach "is not allowed." These are not antitrust harms in the abstract. They are operational decisions enterprise customers made based on information the proposed complaint alleges was false. Customers Were Pushed Into a Bundle Whether They Wanted It Or Not Celonis alleges that SAP has been giving Signavio — its own process-mining product — away free or near-free inside the RISE bundle, with an internal directive to "include Signavio in every software sale." The customer effect is that customers renewing or expanding their SAP relationship receive Signavio at no additional incremental cost, and Celonis alleges that this has caused customers to drop or scale back their Celonis usage in favor of a product the proposed complaint characterizes as inferior. Celonis identifies multiple lost expansion and renewal contracts — customer names redacted — where Celonis was told the reason for the loss was Signavio's inclusion in a RISE bundle. For customers, the dynamic is one we see repeatedly in enterprise software. A bundled component is presented as free, which makes it operationally rational to consume it. The free component then displaces a third-party tool the customer had been paying for. The customer "saves money" in the short run and loses optionality in the long run, as the third-party market shrinks and the vendor's bundled offering becomes the default. Customers Are Migration Hostages Threaded through the proposed pleading is an allegation that resonates with our practice and bears separate attention: customers' relationships with third-party tools are being disrupted at the exact moment customers are migrating to S/4HANA, and SAP is using the migration as leverage. The proposed amended complaint alleges that SAP communicated to customers that continued use of Celonis could jeopardize their S/4HANA migration — a migration most enterprise SAP customers cannot realistically defer. The proposed pleading frames this as part of a coercive scheme. The customer-side characterization is simpler: the customer cannot exit, cannot defer the migration, and is making procurement decisions about third-party tools under conditions in which the dominant vendor is communicating that the customer's strategic IT future depends on cooperating. That is the textbook fact pattern of economic duress under Rich & Whillock, Inc. v. Ashton Development, Inc., 157 Cal. App. 3d 1154 (1984), and an important reason customers facing this type of vendor pressure should preserve communications carefully and consider counsel involvement early. Customer Choice — Once Promised, Now Allegedly Removed The proposed complaint quotes SAP's own historical promises of an "open ecosystem" and "free customer choice," made publicly between 2012 and 2018, on which Celonis and other third-party developers built their businesses. The same proposed complaint alleges that SAP continues to advertise its platform as an "open ecosystem" on customer-facing materials, while internally directing the conduct described above. The complaint also notes that SAP gave explicit assurances to antitrust regulators reviewing the Signavio acquisition that process-management software like Signavio would require only "scanner access" with no fees for indirect use applicable — assurances Celonis says SAP has not honored. For customers, the gap between vendor public messaging and vendor account-team conduct is a recurring theme. The proposed complaint illustrates how that gap can be documented and ultimately litigated. What This Means for SAP Customers Right Now A few practical observations follow from reading the proposed Second Amended Complaint as a customer-side document. First, document everything. The proposed pleading is built on emails, sales-team communications, internal SAP slides, and customer-to-vendor inquiries. The customer that preserves these communications — whether or not it ever intends to litigate — is the customer with the strongest hand at the next renewal. Second, treat compliance assertions skeptically. The proposed complaint alleges that the central pattern of SAP's customer-facing campaign was false statements that the customer's use of Celonis was non-compliant, would trigger additional license requirements, or would create technical or migration risk. Customers who hear similar assertions from any enterprise vendor should obtain those assertions in writing and route them through counsel before acting on them. Vendor compliance claims are not self-validating. Third, recognize what California law provides. We have written before about the California-law tools available to customers facing aggressive vendor conduct: the implied covenant of good faith and fair dealing under Carma Developers (Cal.), Inc. v. Marathon Development California, Inc., 2 Cal. 4th 342 (1992); California's Unfair Competition Law under Business and Professions Code section 17200; economic duress under Rich & Whillock; and tortious interference theories where the vendor's conduct disrupts the customer's relationships with third parties. The Celonis litigation is a live test of how these tools apply to enterprise software conduct. The legal infrastructure California customers can use is more developed than is often appreciated. Fourth, the third-party tools customers depend on may have claims of their own. Celonis is litigating in its own name, but the conduct it describes is conduct directed at SAP customers. Customers whose preferred third-party tools have been the target of similar vendor pressure should be aware that the third party may have independent claims, and that the customer's documentation may be relevant evidence in those proceedings. Caveats Two important ones. First, this is a proposed pleading. The Court has not yet granted leave to amend; until it does, the First Amended Complaint remains the operative pleading. Second, these are allegations only. SAP has denied the allegations in its responsive pleadings and will be entitled to test them through discovery, dispositive motions, and ultimately at the December 7, 2026 trial. Nothing in this post should be read as a finding or conclusion about the merits. Closing Thought The most important sentence in the proposed amended complaint, from the customer's perspective, may be the one in which Celonis frames its own theory: customers buy SAP's ERP software to collect and run their own data, and SAP is allegedly using its control over that ecosystem to deny customers the freedom to work with the providers of their choice. Whether or not Celonis ultimately proves its case, the underlying dynamic — a dominant enterprise vendor narrowing customer choice through technical, contractual, and informational levers — is one California licensees will continue to encounter. The proposed pleading is a useful map of what that dynamic looks like in practice and where the legal pressure points are. We will continue to monitor the case as the Court rules on the motion to amend. Tactical Law Group LLP represents enterprise software licensees in licensing disputes, audit defense, and commercial negotiations involving Oracle, SAP, Broadcom, and other enterprise software vendors. Nothing in this post is legal advice or a comment on any pending litigation. The allegations described are taken from a publicly filed proposed pleading and have not been adjudicated. If your organization is facing aggressive vendor conduct directed at your relationships with third-party providers, please contact us directly. By Pam Fulmer
Software audit disputes used to be uncomfortable but survivable. A publisher would audit usage, claim over-deployment, and demand a true-up. The customer could dispute the findings, involve counsel, and negotiate while the business kept running. That leverage has changed. In a SaaS, cloud-hosted, subscription, or remotely administered environment, the vendor may control the customer’s practical ability to operate. If the vendor can suspend access, disable authentication, block a hosted environment, or lock down critical data, the dispute is no longer just about who is right under the contract. It is about whether the customer can keep running long enough to find out. California law has not yet developed a mature body of published SaaS “kill switch” cases. But California does provide a set of doctrines that can matter when a vendor threatens to disable mission-critical software to collect a disputed demand: the implied covenant of good faith and fair dealing, economic duress, unconscionability, conversion and trespass to chattels in appropriate cases, the Unfair Competition Law, and emergency injunctive relief. The key is precision. The customer’s argument should not be that a vendor can never suspend service. If the contract clearly allows suspension after defined conditions are met, California courts will generally take that language seriously. The stronger argument is that a vendor may not use a suspension right beyond its contractual scope, in bad faith, without satisfying conditions precedent, to enforce a knowingly inflated demand, or in a way that interferes with customer-owned property or data beyond what the agreement permits. And as a lawyer defending software audit disputes for years, I can tell you that many demands are knowingly and intentionally inflated to use as leverage to extract a large software purchase from the customer. Now imagine how empowered these same predatory publishers will be with the kill switch in their hands. Enterprise software customers would do well to start planning their strategies now. Start with the Contract The first question is what the agreement actually says. Many enterprise software agreements contain suspension provisions for nonpayment, uncured breach, security risk, license overuse, audit noncompliance, or violation of acceptable-use restrictions. Some clauses are narrow and procedural. Others are broad and vendor-friendly. California law gives real force to express contract language. In Carma Developers (Cal.), Inc. v. Marathon Development California, Inc., 2 Cal. 4th 342 (1992), the California Supreme Court held that the implied covenant of good faith and fair dealing may not be used to prohibit conduct the agreement expressly permits. The covenant protects the bargain; it does not rewrite it. In Bevis v. Terrace View Partners, LP, 33 Cal. App. 5th 230 (2019), the Court of Appeal likewise rejected an implied-covenant theory that would have required a party to choose one contractually permitted course over another. Those cases are important vendor-side authority. But Carma also identifies the customer’s opening: the implied covenant has particular force where one party holds discretionary power affecting the rights of the other. The strongest customer argument is not “the vendor can never suspend.” It is that the vendor cannot use a discretionary suspension mechanism as a pretextual coercion device to obtain benefits outside the bargain or to enforce a claim it knows is false or materially overstated. Think of Oracle's VMware virtualization policy arguments. Relevant questions include whether the contract allowed suspension for this type of alleged breach; whether the vendor satisfied notice, cure, audit, escalation, and dispute-resolution requirements; whether the customer is current on undisputed amounts; and whether the vendor is threatening to suspend services, data, affiliates, or environments beyond the clause’s scope. Economic Duress California’s economic-duress doctrine can be powerful in a kill-switch dispute, but only if the customer can show more than ordinary commercial pressure. The leading case is Rich & Whillock, Inc. v. Ashton Development, Inc., 157 Cal. App. 3d 1154 (1984), where a release was unenforceable because it was obtained after a contractor refused to pay an undisputed amount, knowing the other party faced financial ruin. The doctrine turns on a wrongful act, coercive pressure leaving no reasonable alternative, and submission to the pressure. The wrongful act need not be a crime or independent tort; asserting a claim known to be false, making a bad-faith threat to breach, or wrongfully withholding payment may qualify. That framework can fit software suspension threats where a vendor uses a knowingly inflated audit claim, refuses to follow agreed procedures, threatens suspension for amounts not yet due, or demands unrelated purchases or broad releases as the price of continued access. But a vendor’s threat to exercise a clear contractual suspension right after a material uncured breach is not automatically wrongful merely because it creates pressure. If payment is necessary to keep operating, the customer should pay expressly under protest, reserve all rights, identify the disputed grounds in writing, and document why no reasonable alternative existed. Unconscionability Unconscionability is possible, but often difficult in enterprise software disputes. In Sanchez v. Valencia Holding Co., 61 Cal. 4th 899 (2015), the California Supreme Court explained that unconscionability requires both procedural and substantive elements. Sonic-Calabasas A, Inc. v. Moreno, 57 Cal. 4th 1109 (2013) describes the same basic framework. In B2B software contracts, the customer may be sophisticated, represented, and able to evaluate alternatives. The better argument targets the combined remedial architecture: unilateral vendor breach determinations, short cure periods, suspension before neutral review, a bar on consequential damages, a low liability cap, and no meaningful data-export right. The goal may be limited but important: preserve access during a good-faith dispute or prevent the vendor from invoking a liability cap for a wrongful shutdown. Conversion, Trespass, and Data Lockout Tort theories are strongest when the vendor interferes with property interests beyond a mere contractual right to use the vendor’s hosted service. The customer should identify exactly what property is being impaired: customer data, electronic records, backups, local installations, servers, devices, credentials, or domain assets. In Intel Corp. v. Hamidi, 30 Cal. 4th 1342 (2003), the California Supreme Court held that unwanted emails did not establish trespass to chattels because they did not damage Intel’s computer system or impair its functioning. For kill-switch purposes, Intel underscores the need for concrete impairment: blocked access, disabled functionality, interruption of system use, or loss of access to records. Conversion may also apply to certain digital property. In Kremen v. Cohen, 337 F.3d 1024 (9th Cir. 2007), the Ninth Circuit, applying California law, held that a domain name could support a conversion claim. The out-of-state case Clayton X-Ray Co. v. Professional Systems Corp., 812 S.W.2d 565 (Mo. Ct. App. 1991) remains useful by analogy, but California briefing should lead with California authority. UCL and Emergency Relief California’s Unfair Competition Law can support restitution and injunctive relief, but not ordinary damages. Korea Supply Co. v. Lockheed Martin Corp., 29 Cal. 4th 1134 (2003) makes that remedial limit clear. The “unlawful” prong is often the cleanest route, using breach of the implied covenant, duress, unconscionability, statutory violations, or wrongful property interference as predicates. The “unfair” prong requires caution in B2B disputes; under Cel-Tech Communications, Inc. v. Los Angeles Cellular Telephone Co., 20 Cal. 4th 163 (1999), unfairness in competitor cases must be tethered to a legislatively declared policy or threaten competition. The most important remedy may be a temporary restraining order or preliminary injunction. California courts consider likelihood of success and the interim harm to each side. Butt v. State of California, 4 Cal. 4th 668 (1992). The customer should build a record showing both irreparable harm and merits: disputed demand, payment of undisputed amounts, failure to follow contract procedures, operational dependency, lack of alternatives, and threatened loss of customer-owned data. California law gives customers a toolkit, not a silver bullet. The winning case usually turns on contract language, procedural defects, a timely good-faith dispute, wrongful pressure, and whether suspension would interfere with customer data or operations in a way damages cannot repair. That is enough to change the negotiation. A vendor facing a prepared TRO application, a duress record, possible UCL restitution, and property-based claims for overreach must evaluate the cost of flipping the switch more carefully. This article is for general informational purposes only and does not constitute legal advice. Readers should consult counsel about the specific facts of their own situation By Pam Fulmer
A finance manager at a California company opens Microsoft 365 Copilot and asks, “Summarize our open purchase orders over $50,000 and flag anything unusual.” Copilot reaches SAP through a connector or other integration layer, builds the answer, and drops it into a dashboard she shares with four hundred colleagues. She is a licensed SAP user. The four hundred colleagues are not. Is that indirect access? Does each of those four hundred colleagues now need an SAP Named User license? Does it matter if Copilot creates a purchase order on her behalf rather than just summarizing one? What if the whole workflow runs autonomously, with no human prompting the agent at all? There is no clear AI-specific published guidance that answers those questions — and that is precisely the problem. SAP and Oracle are actively marketing AI-enabled products and integrations, customers are deploying them at speed, and the contract language that will ultimately be used to assess licensing exposure was drafted decades before anyone imagined an AI agent as a user. This Is Not a New Problem — It Is the Diageo Problem in New Clothes In 2017, the UK High Court ruled in SAP UK Ltd v. Diageo Great Britain Ltd that thousands of Diageo customers and sales representatives using Salesforce-based apps — apps that in turn exchanged data with SAP — constituted indirect users of SAP ERP. SAP claimed more than £54.5 million in additional license fees. The case settled before the damages phase, but the liability ruling became a touchstone for later indirect-access disputes and helped catalyze SAP’s move toward its current Digital Access model, while reinforcing the broader vendor view reflected in Oracle’s aggressive enforcement of its multiplexing rule. Diageo was ultimately a case about middleware. The court concluded that even though Salesforce users never logged into SAP directly, the fact that their actions flowed through middleware into SAP meant they were using the SAP software. That reasoning — that “use” and “access” can reach through whatever sits in the middle — is exactly what makes AI agents a likely next battleground. What’s Different Now: The AI Agent Fact Patterns AI agents raise the indirect access problem in four distinct ways, and each one introduces contractual ambiguity the vendors have not resolved. First, conversational assistants with ERP connectors. Microsoft 365 Copilot, ChatGPT with custom connectors, and similar tools allow a licensed user to query SAP or Oracle data and then redistribute the result to an unlimited audience. The licensed user pays for the license, but the practical beneficiaries may be hundreds of colleagues who never had a seat. Second, agentic workflows that create transactions autonomously. Procurement-to-pay pipelines can match invoices to purchase orders and post documents into S/4HANA without a human in the loop. Under SAP’s Digital Access model, every posted document — sales order, invoice, purchase order, journal entry, and others — may be a countable event. An agentic pipeline can multiply a customer’s historical document volume many times over, and SAP’s published materials do not clearly exclude AI-generated documents from the count. Drafts, retries, and reversal entries only compound the issue. Third, service-account connections in Oracle environments. A customer-service AI agent might use a single Oracle service account to answer billing or shipment questions on behalf of thousands of end customers. Oracle’s multiplexing rule, essentially unchanged for years, states that multiplexing does not reduce Oracle license requirements and that users at the multiplexing front end must still be licensed. On its face, that rule could be read to reach every one of those end customers — a potentially devastating position in an audit. Fourth, retrieval-augmented generation pipelines. A common enterprise pattern now is to extract master data from SAP or Oracle nightly, embed it into a vector database, and answer employee questions from the vector store. Is the nightly extract the relevant “access” event — a single licensed pathway? Or does every downstream question count because the data originated in SAP or Oracle? The contract language usually does not resolve that issue, and a motivated vendor auditor can argue it either way. The Vendor Silence Is Deliberate SAP now offers Joule base capabilities at no additional cost, while pricing certain premium AI capabilities separately, including in some cases through consumption-based AI Units. Oracle has embedded hundreds of AI agents across its Fusion Cloud applications. Both vendors are actively marketing these capabilities. Neither vendor, however, has published clear guidance answering the licensing questions above. That silence is a feature, not a bug. Ambiguous contract language is one of the most powerful tools a licensing team has in an audit. When the rules are unclear, the vendor gets to assert the most expensive reading first and negotiate downward from there. Customers that did not think to negotiate AI-specific language in their 2019 or 2022 renewals are the ones most exposed. Why California Customers Have Leverage California is home to a disproportionate share of enterprise SAP and Oracle customers, and California law gives customers several tools when a vendor tries to stretch pre-AI contract language to cover an AI deployment the parties never discussed. Every California contract carries an implied covenant of good faith and fair dealing. Where one party holds discretionary power — as vendors often do when interpreting their own license terms — that discretion must be exercised reasonably and with proper motives. A vendor that assesses a multi-million-dollar compliance finding against a customer on a theory the parties never discussed at signing may face a substantial good-faith challenge. California Civil Code section 1654 codifies the rule that ambiguous contract language is construed against the drafter. California courts apply that principle seriously, particularly in agreements drafted by sophisticated legal teams — and SAP and Oracle agreements are drafted by some of the most sophisticated licensing teams in the industry. Ambiguous words like “user,” “access,” or “multiplexing front end” belong to the vendor. If the vendor intended those terms to cover AI agents, copilots, downstream recipients, or vector-database architectures, it should have said so in the contract rather than for the first time in an audit demand. California’s Unfair Competition Law, Business and Professions Code section 17200, reaches unlawful, unfair, and fraudulent business practices. It can be especially useful when a vendor changes its interpretation of the same contract language between customers or over time, or when audit conduct crosses the line into misrepresentation or concealment. Finally, course of performance matters. If a vendor audited a customer in 2022 and did not flag an AI-enabled integration that was already in place, that audit history may support the customer’s interpretation of the contract and may strengthen waiver, estoppel, or course-of-performance arguments when the same vendor audits the same integration in 2026 and suddenly claims a compliance failure. Customers should be preserving audit history, support tickets, and account-team correspondence now, while memories are fresh, rather than scrambling later. Getting Ahead of the Problem There are a handful of practical steps every SAP or Oracle customer deploying AI agents should take before the first audit letter arrives. Revisit your most recent vendor contract and study the definitions of “user,” “access,” “indirect use,” and — for Oracle — “multiplexing.” Where the language is silent on AI agents, that silence is both an argument for you in the short term and a redline target in the next renewal. If the vendor is offering a new AI product as an add-on, insist on written confirmation of how that product interacts with your existing license metrics before you buy. Document your AI deployment architecture now. How does the agent connect? Who are the prompting users? What does the agent read, and what does it write? Which outputs create countable documents under Digital Access, and which are merely transient summaries? The time to build that file is before a vendor audit team builds it for you. Treat vendor-native AI differently from third-party AI. SAP’s Joule and Oracle’s Fusion AI agents are the vendor’s own products. There is a strong argument that licensing a vendor’s AI features should come with bundled indirect-access rights for the downstream outputs those agents produce. That argument should be made in writing, and it should appear in the contract itself. How Tactical Law Can Help The intersection of AI deployment and ERP licensing is where two fast-moving areas collide, and the customers who will pay the least are the ones who start the conversation before the vendor does. Tactical Law advises enterprise customers on licensing strategy, audit defense, and contract negotiation across exactly these issues. If your organization is deploying AI agents, copilots, or agentic workflows against an SAP or Oracle estate — and you have not yet had a conversation with outside counsel about what that means for your license position — now is the time. Oracle’s Newest Java Audit Demand: Your VMware Topology — and What California Law Says About It4/19/2026 By Pam Fulmer
A pattern is appearing in Oracle’s Java licensing enforcement that every in-house counsel with an Oracle footprint needs to understand. On the sales side, at least in some instances, Oracle is offering customers what is, in substance, a two-track choice. Customers willing to subscribe on the new per-employee Java SE Universal Subscription metric can do so without producing information about their virtualization environment. Customers who want to remain on — or return to — Oracle’s legacy Named User Plus or Processor-based Java metrics may be required by Oracle to first disclose extensive data covering the entire VMware farm, not only the servers where Oracle software is installed or actually running. A Java licensing conversation is, in other words, being converted into a VMware full environment disclosure. The scope of that demand is the tell. Even under the legacy Named User Plus and Processor options, Java compliance is verified by reference to the servers where Oracle Java is actually installed and/or running. When Oracle asks for data about the full virtualized environment — including hosts that do not run Oracle software at all — the data is being collected for a different purpose. This post explains that purpose, why it is dangerous, and the California legal arguments customers can use to push back. What Oracle Is Asking For The audit-side of this pattern is now documented in the trade press. Redress Compliance has reported that Java audit letters ask for “a full list of all VMware or other virtualized platform hosts, whether they have Java installed or not”. House of Brick has documented Oracle asking for vCenter exports and cluster configuration data during Java audits and tying those requests back to Oracle’s aggressive position on VMware licensing. And The Register’s 2024 coverage of Java audit letters to Fortune 100 companies signaled the scale of the escalation. The structure of the choice Oracle is offering customers with meaningful Java dependencies deserves a closer look, because it functions as a Hobson’s choice. Accepting the per-employee metric avoids any VMware inquiry, but it has made Oracle Java dramatically more expensive for most enterprises than the legacy arrangements. Declining that metric in favor of Named User Plus or Processor-based licensing may require the customer to hand over data on the full VMware environment — including hosts that have nothing to do with Oracle software. And walking away from Oracle Java altogether is, for many customers, not a short-term option: a disciplined migration to OpenJDK or another supported distribution takes time, requires engineering and testing work, and introduces business risk that cannot be absorbed on Oracle’s negotiation timeline. Customers have understandably balked at the VMware-disclosure path. Producing whole-farm topology to Oracle at any stage of a Java engagement raises the risk that the inquiry will expand beyond Java, or that Oracle will use the data to assert compliance claims about other Oracle products running in the same environment — most obviously Oracle Database. That is the subscription-side extension of the pattern we described in “Oracle Java Licensing Enforcement: How ‘Friendly Outreach’ Is Driving Significant Compliance Risk” and in “How Oracle Uses Online Agreements for ‘Free Software’ to Trap Companies”: Oracle’s outreach is not just pre-litigation intake — in some instances it has become pre-audit intake, with the subscription transaction itself used as the lever. Why It Is Dangerous The purpose of the VMware request is Oracle’s long-running “soft partitioning” position on database licensing — the whitepaper theory, never codified in customer agreements, that any physical core in a VMware cluster where Oracle software could theoretically run must be fully licensed. Under its more aggressive expressions, according to Oracle, every host connected to the same vCenter, or reachable by vMotion, must be licensed for any Oracle software running anywhere in the environment. For a customer running a modest Oracle Database footprint on a large VMware estate, the resulting compliance gap is often very large. That position has never been tested in court with a court ruling, and independent specialists have argued forcefully that Oracle’s soft-partitioning theory is inconsistent with how VMware actually works. But the economic pressure to settle rather than litigate is enormous, and Oracle knows it. A customer who hands over complete vCenter topology during a Java audit has, in practical terms, already pre-calculated the database compliance claim Oracle will assert three months later. The Java audit is the delivery vehicle. The database claim is the payload. California Legal Arguments That Matter For Oracle customers — many of whom operate under Oracle agreements that select California law by an express choice-of-law provision — California provides a toolkit for pushing back on this conduct. As California lawyers, we are intimately familiar with this toolkit. The Unfair Competition Law, Business & Professions Code § 17200, is the most flexible and most important of those tools. Section 17200 prohibits any “unlawful, unfair, or fraudulent business act or practice.” The “unfair” prong reaches conduct that violates public policy or causes substantial injury, even where no specific statute has been violated. Conditioning the sale of a Java subscription — priced on a metric entirely unrelated to virtualization — on the customer’s disclosure of VMware topology that will predictably be used to construct a separate, much larger claim appears to fit the “unfair” framework cleanly. Post-Proposition 64, a UCL plaintiff must show actual injury; a customer who paid an inflated subscription price, or who was forced into a database compliance settlement the disclosure made possible, can satisfy that requirement. The implied covenant of good faith and fair dealing is a second, and often underused, angle. Every California contract includes an implied covenant prohibiting either party from acting to deprive the other of the benefits of the bargain. When Oracle invokes the audit clause from one agreement — an Oracle Master Agreement, a database OLSA, or an OTN license — to extract information whose only function is to build claims under a separate product line, the implied covenant may be available as a basis for a claim. Audit rights exist to verify compliance with the agreement that granted them. Using them as reconnaissance for a different product’s claims is not what the parties agreed to, and California courts take that distinction seriously. Finally, economic duress. California recognizes the doctrine where one party uses a wrongful act or threat to force another into a transaction it would otherwise refuse, and where the coerced party has no reasonable alternative. Rich & Whillock, Inc. v. Ashton Development, Inc. (1984) 157 Cal.App.3d 1154 remains the foundational authority. The choice Oracle is presenting — an expensive new metric, or a whole-VMware farm disclosure that will foreseeably build claims elsewhere, or abandoning a business-critical platform on an infeasible timeline — fits that framework. Most often the scope of Oracle’s demanded disclosure has no legitimate relationship to the Java transaction, and a customer whose Java dependencies cannot be unwound on Oracle’s timeline has no reasonable alternative. Duress is a particularly valuable defense because it attacks the enforceability of any settlement Oracle later extracts from data produced under coercion. What To Do When the Pattern Appears A few practical steps apply whether the demand arrives in a formal audit letter, a GLAS follow-up, or a sales-team email holding up a subscription quote. Stop providing VMware information in any Java communication. Demand in writing that Oracle identify the specific contract clause authorizing the request and the specific Oracle product whose compliance is being verified; if Oracle cannot answer, the request is a fishing expedition. Document any conditioning of a subscription sale on disclosure — that documentation is the foundation of any UCL, implied-covenant, or duress argument later. And involve counsel before information leaves the company. Early, counsel-led responses are the single strongest predictor of a favorable outcome in this pattern. Closing Thought The Java audit is increasingly not about Java. Oracle’s enforcement program is a data-gathering operation with a sales objective attached, and the whole-farm VMware demand is the most aggressive expression of that strategy we have yet seen. California law gives customers real tools to resist it — but those tools only work if the customer reaches for them before the data has been delivered. Tactical Law Group LLP represents enterprise software licensees in Oracle and other software publisher licensing matters, audit defense, and commercial negotiations. Nothing in this post is legal advice or a comment on the specific circumstances of any customer or transaction. If your organization is facing an Oracle Java audit — or is being told a Java subscription is conditioned on VMware or other environmental disclosure — please contact us directly. By Pam Fulmer
For three years, we have been writing about Oracle’s Java licensing enforcement as a slow-motion campaign — one that began with “friendly” compliance emails, continued through a series of escalating sales-team overtures, and rarely produced a formal audit letter. That campaign is now changing character. In 2026, the soft outreach is giving way to formal audit notices issued under Oracle’s license management function — what used to be called LMS, and is now branded Global Licensing and Advisory Services, or GLAS. The letters are arriving. They look and feel different from what Oracle Java customers have seen for the last several years. And the pattern of who is getting them is not random. Our view, which we have previewed in earlier posts, is that this moment has been structurally inevitable since early 2023 — the year Oracle replaced its prior Java SE subscription with the Java SE Universal Subscription, a per-employee model that made Java dramatically more expensive for most enterprises and fundamentally changed Oracle’s enforcement economics. This post explains why the formal audits are finally here, what they actually look like, and what Oracle Java customers should be doing before — or, if the letter has already arrived, during — the audit. How We Got Here The current story starts with Oracle’s decision, announced in January 2023, to move Java SE off a per-user and per-processor model and onto a per-employee model covering every employee, contractor, and agent of a subscribing entity — whether or not they actually use Java. We wrote about the immediate commercial effect in Oracle Changes Java SE Licensing Rules and Prices Explode, and the practical upshot has not changed: for most enterprises the cost of Oracle Java increased dramatically, in many cases by a multiple of what the prior subscription had charged. Many companies concluded, reasonably, that the new model was not for them. They began evaluating OpenJDK, Amazon Corretto, Azul Zulu, and other supported alternatives. Some migrated. Some did not. What happened next was not a quiet period. It was a campaign. As we described in Oracle Java Licensing Enforcement: How “Friendly Outreach” Is Driving Significant Compliance Risk, Oracle’s sales and compliance teams began contacting organizations with pointed but informal questions about their Java deployments. Those inquiries were frequently positioned as helpful — an offer to “clarify” licensing status, or a suggestion that the company might qualify for a “special transition” subscription. In Warning to Oracle Customers: Don’t Be Fooled By Oracle’s Java Playbook, we explained why that framing was — and is — dangerous. The calls and emails were not customer service. They were pre-litigation intake. Why the Formal Audits Are Finally Coming Three things have changed in 2025 and 2026 that are now driving formal audit letters in volume. First, Oracle has had three years to gather data. As we discussed in How Oracle Uses Online Agreements for “Free Software” to Trap Companies, Oracle tracks downloads of Java binaries in detail — IP addresses, corporate domain associations, download timestamps, and whatever account information was used at download. It also logs the automatic update check-ins made by every installed copy of Oracle Java that has not been affirmatively disconnected from Oracle’s servers. Three years of that telemetry, cross-referenced against whatever the friendly outreach emails extracted from the company directly, is now a usable audit foundation. The companies Oracle is sending formal letters to in 2026 are not being chosen at random. Second, the soft-outreach stonewall has produced a target list. Companies that responded to the friendly outreach by buying the subscription on Oracle’s terms were never going to receive a formal audit letter — they were already paying. Companies that simply did not respond, or that responded with a polite “we use non-Oracle Java,” were implicitly telling Oracle that the only way to convert them was through the audit clause in their existing Oracle agreements or through the click-wrap terms they accepted when they downloaded Oracle Java. Three years later, that target list is mature. Third, Oracle has business reasons to push harder now. As we wrote in our recent coverage of the Rimini Street settlement, Oracle’s financial story has pivoted to a cloud and AI infrastructure business whose margins are widely understood to be thinner than its legacy support business. The support and subscription revenue line — the line that includes the Java SE Universal Subscription — has become more, not less, critical to Oracle’s investor narrative. Converting long-resistant Java customers into subscription customers, via audit, is directly aligned with that strategy. There is a fourth factor worth naming separately. We have seen an emerging pattern — which we flagged earlier and which the trade press has since confirmed — of Oracle declining to sell Java subscriptions to certain customers unless those customers first disclose detailed usage and employee-count information. In some instances, companies that tried to buy their way into compliance have been told, in effect, that compliance is not available to them without first producing the data that typically comes out of an audit. That is not a sales process. It is a structure for manufacturing non-compliance, and in-house counsel should treat it as such. What a Formal Java Audit Letter Looks Like The formal audit letters arriving in 2026 look meaningfully different from the outreach emails that preceded them. They are typically addressed to a named C-suite executive — CIO, CFO, or General Counsel — and signed by an Oracle GLAS representative rather than a salesperson. They cite an audit clause either in the company’s existing Oracle Master Agreement (if the company holds other Oracle products) or in the Oracle Technology Network License Agreement that governed the original Java download. They name an audit window — commonly forty-five days — and specify whether the review will be conducted directly by GLAS or through a designated third-party auditor. And they set an expansive scope: global employee counts, deployments by version, installation inventories, virtualization and cloud environments, and anything Oracle believes relates to its employee-metric calculation. For readers who want a deeper walk through how Oracle conducts these engagements generally, our earlier post Oracle Knows More About You Than You Think: Lessons from Oracle v. Kelkar remains directly on point. What Oracle Java Customers Should Be Doing Now Whether or not a formal letter has already arrived, a few things are worth doing now. Inventory your own Java deployments before Oracle tells you what they are. The most damaging audit outcomes we see are the ones where the company learns the size of its Java footprint from Oracle — usually at a moment when the company has lost most of its negotiating leverage. Counsel-led internal discovery, done under privilege, almost always produces a more favorable result. Understand which license terms actually govern your Java usage. Not every Java installation is governed by the same agreement. Versions and licenses have changed several times since 2019, and what you downloaded in 2018 is almost certainly not what you downloaded in 2024. Older, more permissive license grants still exist in many environments. Identifying them is often the single most important step in a Java audit defense. Do not respond to “friendly outreach” without counsel. The consistent pattern we see is that informal responses to Oracle’s pre-audit inquiries become the foundation of the formal audit that follows. If an email from an Oracle Java team member has landed in your inbox and you have not yet responded, treat it the way you would treat a preservation letter. If the formal audit letter has arrived, assert the procedural protections you are entitled to. Oracle audit clauses are negotiable in practice, even if they look one-sided on the page. Scope, timeline, choice of auditor, and handling of proprietary data are all areas where experienced counsel can substantially change the trajectory of an audit. Closing Thought None of this was unpredictable. We wrote, in Java Audits Likely Will Increase as Oracle Seeks to Move Java Users onto its Total Employee Metric, that the shift to the employee metric would eventually produce a wave of formal audits, and that the quiet soft-outreach period was not a feature of Oracle’s enforcement posture but a phase of it. That phase is now closing. The companies that treated the last three years as a chance to prepare — to inventory, to analyze their contracts, and to reduce their dependence on Oracle Java where alternatives exist — are in a materially stronger position than those that assumed the outreach would simply go away. It did not. It never does. Tactical Law Group LLP represents enterprise software licensees in Oracle and SAP licensing matters, audit defense, and commercial negotiations. Nothing in this post is legal advice. If an Oracle audit letter has arrived at your organization — or if you are receiving the “friendly” pre-audit emails that tend to precede one — please contact us directly. By Pam Fulmer
When Oracle and Rimini Street announced their confidential settlement in July 2025, the headlines framed the moment as the quiet close of a decade-plus copyright saga. For the lawyers who lived through the case, that was certainly true. But for the Oracle customers who have watched this litigation from the sidelines — often while writing twenty-two-percent-of-license-cost checks to Oracle each year — the settlement is not the end of anything. It is the beginning of a new round of questions about who controls the cost of enterprise software support, and who is going to pay for it. We have written before about the litigation and the Ninth Circuit’s December 2024 opinion that forced the parties to the table. This post is about what comes next. The short version: the Ninth Circuit handed Oracle a loss on the law. The settlement handed Oracle something it arguably wanted more — a clear off-ramp for one of the largest pools of customers who had found a cheaper alternative to Oracle’s support machine. The question Oracle customers should be asking is whether that trade will show up in their renewal invoices. A Quick Refresher The settlement has three load-bearing pieces: Oracle returned approximately $37.8 million of the attorneys' fees the lower court awarded to Rimini Street; Rimini agreed to wind down its third-party support for Oracle PeopleSoft by July 31, 2028; and both sides dropped their remaining claims with neither admitting wrongdoing. The parties reached this deal after the Ninth Circuit vacated nearly every material copyright ruling against Rimini, reversed the Lanham Act judgment, and set aside the injunction. The court called the district court’s reading of “derivative work” “hopelessly overbroad,” and held that “mere interoperability isn’t enough” — a party must actually, substantially incorporate copyrighted material to infringe the right to prepare a derivative work. On the law, the third-party support industry walked out of the Ninth Circuit in a stronger position than it walked in. Which is precisely why the settlement terms — and the PeopleSoft wind-down specifically — are interesting. Oracle’s Support Business, and Why It Matters Here Anyone who has read Oracle’s recent annual reports understands a simple fact: the company’s revenue is no longer dominated by new software license sales. The overwhelming majority of what Oracle takes in every year comes from cloud services, subscriptions, and — critically for this discussion — license support. Support and subscription revenue is not a sideline for Oracle. It is the business. And it is a remarkably profitable one. Software support — the recurring fee Oracle collects in exchange for patches, bug fixes, and portal access — carries famously high margins by enterprise software standards, meaningfully above Oracle’s already-robust overall margin. When you compound those margins over decades of paid-up license bases, you see why Oracle’s investor story has for years been less about selling new software and more about keeping the existing customer base inside the paying support tent. The mechanics are worth spelling out. Oracle’s standard Premier Support fee is twenty-two percent of the net license fee, charged annually — a figure codified in Oracle’s own published support policies, which also reserve Oracle’s right to raise that fee annually based on “inflationary” adjustments Oracle itself sets. Historically modest, those annual uplifts have in recent years trended meaningfully higher than conventional inflation. Over a ten-year horizon on a large license base, the compounding effect is substantial — the difference between a support budget that stays roughly flat in real terms and one that quietly doubles. Why the Settlement Terms Favor Oracle, Even If the Law Did Not Read against that financial backdrop, the 2028 PeopleSoft sunset is not a footnote. It is the point. PeopleSoft is a mature product set Oracle acquired in 2005. Many PeopleSoft customers have paid-up perpetual licenses, no interest in migrating to an Oracle cloud suite on Oracle’s timeline, and every reason to keep their existing systems running on a leaner support contract. That profile — stable, installed, resistant to re-platforming — is exactly what third-party support is built for, and exactly what is most valuable to Oracle if it can be kept on Oracle Premier Support for as long as possible. By securing a firm date by which one of the largest third-party support providers will stop supporting PeopleSoft, Oracle has effectively put a clock on a slice of the third-party support market it cares about most. Those customers will be deciding between 2026 and 2028 whether to return to Oracle support, move to another third-party provider, accelerate a replatforming project, or run unsupported. Nothing in the Ninth Circuit opinion compelled that outcome. The court’s holding cuts the other way — it makes copyright doctrine a harder tool for Oracle to use against third-party support providers. What the settlement did is trade a legal theory that was failing in court for a commercial concession extracted at the bargaining table. A rational outcome for a sophisticated plaintiff. But worth looking at clearly from the customer’s side. A note on Rimini: we have enormous respect for the role the company has played — and continues to play — in giving Oracle and SAP customers a meaningful alternative to vendor support. Rimini did not lose this litigation in any conventional sense. The company vindicated the legality of independent third-party support at the Ninth Circuit, survived a fifteen-year campaign from one of the best-resourced plaintiffs in technology, and continues to serve thousands of customers across Oracle, SAP, and other enterprise software product families. The PeopleSoft wind-down is a defined, manageable transition. The narrower question for Oracle customers is not whether Rimini survived — it is whether Oracle’s pricing leverage on its most captive installed base just got stronger. The Pricing Question There are two plausible reads on what happens to Oracle support pricing over the next three to five years. The optimistic read: the third-party support market is bigger and more robust than ever, with more credible providers serving more customers across more product lines than when the Rimini litigation began. Competitive pressure — from Spinnaker Support, Support Revolution, Rimini itself, and others — keeps Oracle from pushing support fees arbitrarily without accelerating customer defections. The twenty-two-percent fee plus modest annual uplifts stays roughly where it is. The cautious read: the PeopleSoft sunset is a signal. For those customers specifically, Oracle now has a defined window in which a meaningful share will be forced to make a decision, with every incentive to make the return-to-Oracle option attractive up front while positioning for price increases once those customers are back inside the tent. More broadly, if Oracle concludes that commercial-term negotiations with third-party providers can substitute for a failing copyright strategy, similar dynamics may play out in other product lines. And Oracle’s public posture is not subtle: its reliance on support and subscription revenue is increasing as its growth narrative pivots to cloud and AI infrastructure whose margins are widely understood to be thinner. When margins compress in one place, there is a natural pull on management to protect margins elsewhere. We do not yet know which read is closer to right. But customers who assume the settlement is simply “news” — a 2025 storyline requiring no action — are taking a position that the next three years of renewal cycles may test. What This Means for Oracle Customers A few things flow from all of this. First, the legal ground under third-party support is firmer, not softer, after the Ninth Circuit opinion — customers still hesitant about the legal risk should understand the highest recent appellate statement runs the other way. Second, PeopleSoft customers on Rimini support should be planning now, not in 2027; a thoughtful transition takes longer than most organizations expect and benefits from being planned before leverage shifts toward the deadline. Third, every Oracle renewal conversation from here forward is a pricing conversation, and customers who want to hold the line need to build leverage well before the renewal window. Finally — and this is the piece our firm spends the most time on — the support-cost question is inseparable from the audit-risk question. Oracle’s audit practice and its support renewal practice are two sides of the same revenue engine, and serious customers have to manage both together. The Rimini Street settlement is, narrowly, a story about one provider and one product line. Broadly, it is a story about who bears the cost of Oracle’s transition to being an AI-and-cloud company financed by a support annuity business. The Ninth Circuit made clear that copyright law is not going to do that work for Oracle. The settlement shows that commercial leverage might. None of this is reason to panic. It is reason to stop treating enterprise software support as a fixed cost line that simply renews itself each year — and to start treating it as a contract that is actively managed, aggressively negotiated, and regularly benchmarked against a growing and legally-vindicated ecosystem of alternatives. The customers who engage early keep control of their own budgets. Tactical Law Group LLP advises enterprise software licensees on Oracle and SAP licensing, audit defense, and commercial negotiations. Nothing in this post is legal advice. If you have questions about your organization’s Oracle support or audit posture, please contact us directly. By Pam Fulmer
On April 9, 2026, Oracle filed a federal lawsuit in the Eastern District of North Carolina against its former employee, Pravin Kelkar, alleging trade secret misappropriation and breach of contract. The case, Oracle America, Inc. v. Kelkar(Case No. 5:26cv236), reads like a corporate thriller: a terminated employee threatening to sell Oracle's proprietary databases to the highest bidder. But buried inside the drama is a revelation that should concern every Oracle customer. Oracle's own Complaint lays out, in remarkable detail, just how much information Oracle collects about its customers and how central that data is to Oracle's sales machine. What the Complaint Alleges Pravin Kelkar worked at Oracle for over five years, most recently in a sales operation’s role supporting Oracle's Life Sciences businesses. When Mr. Kelkar got caught up in Oracle’s recent massive layoff (Oracle eliminated his position on March 31, 2026), the Complaint alleges that Kelkar responded by sending threatening messages to Oracle's HR team and senior executives. He claimed to have transferred Oracle's entire "install base" database to a personal device and threatened to sell it to Oracle's competitors unless Oracle met his demands for two years of full salary, benefits, and immediate vesting of his restricted stock units. Oracle attempted to resolve the matter without litigation, contacting Kelkar by letter and phone, requesting that he return the data and submit his personal devices for forensic inspection. Kelkar refused to fully cooperate, at one point claiming his threats were made "in jest," while simultaneously declining to return the materials or allow an inspection. Oracle filed suit nine days later, seeking emergency injunctive relief under the Defend Trade Secrets Act. The Real Story: What Oracle Considers Its "Install Base" The most revealing aspect of this Complaint is not Kelkar's conduct. It is Oracle's own detailed description of what its "install base" databases contain and why Oracle considers them to be among its most valuable trade secrets. According to Oracle's Complaint, the install base databases include granular, confidential details about Oracle's customer relationships, covering information such as which products and services each customer uses, where those products are deployed, confidential pricing and contract terms, support identifier numbers for each customer, sales history broken down by fiscal quarter and week, product-use information, contract status and renewal timing, forecast and pipeline information, account ownership and sales representative contact information, and facility or site-level deployment details. Oracle maintains separate install base databases for its North America region, its Oracle Health business (formed after Oracle's 2022 acquisition of Cerner Corporation), and its Fusion product lines. The company describes these databases as representing years of ongoing development, built and maintained at substantial time, effort, and expense by its sales and operations teams. Oracle's Complaint explains that these databases exist for a specific purpose: to provide Oracle's sales and operations teams with the information they need to facilitate the maintenance and growth of customer relationships, track sales and renewal schedules, and provide critical data on software revenue and profitability. In other words, Oracle is not simply storing this data for record-keeping. It is actively using it to drive sales strategy, identify upsell and cross-sell opportunities, and time its outreach around contract renewals. Why This Should Concern Oracle Customers Oracle's Complaint makes clear that the company views its customer data as a competitive weapon. Oracle itself alleges that a competitor could use this information to uproot its customers by reviewing what products they use, what their impending needs are, what prices they pay, and when their contracts end. Turn that sentence around: if a competitor could use this data to target Oracle's customers, Oracle itself is certainly using this same data to target its own customers for additional sales. Oracle knows what you have deployed, what you are paying, when your contracts come up for renewal, and what your usage patterns look like. That is an extraordinary informational advantage in any negotiation. For Oracle customers, the implications are significant. Every interaction with an Oracle sales representative, every support ticket, every deployment discussion is potentially feeding a database that Oracle uses to craft its sales approach. When Oracle contacts you about a renewal or a new product offering, it is not making a cold call. It is working from a detailed dossier on your entire Oracle footprint. What Companies Should Do The Oracle v. Kelkar case is a wake-up call for any organization running Oracle software. Oracle is meticulously tracking your data, and it is using that data to maximize its revenue from your account. Companies that want to level the playing field should consider the following steps. Control the flow of information to Oracle. Establish clear internal policies about what employees can and cannot share with Oracle sales representatives. Not every conversation needs to include details about your deployment plans, budget cycles, or technology roadmap. Train your teams to understand that information shared with Oracle does not disappear; it goes into a database. Centralize your Oracle relationship. Designate a small team or a single point of contact responsible for managing Oracle communications. This prevents Oracle from gathering intelligence across multiple departments and assembling a more complete picture of your organization than any one person intended to provide. Understand your contractual position before Oracle does. Oracle knows your renewal dates, your pricing history, and your deployment footprint. You should know these things at least as well as Oracle does. Conduct regular internal audits of your Oracle estate so that you are never negotiating from a position of informational disadvantage. Be strategic about support and deployment conversations. Technical support interactions and implementation discussions can reveal information about how you use Oracle products, where you are experiencing growth, and what your future needs might look like. Be thoughtful about what details are shared and through which channels. Engage experienced counsel before Oracle comes knocking. Whether you are facing an audit, negotiating a renewal, planning a migration, or simply trying to understand your rights under your existing agreements, having advisors who understand Oracle's playbook can make an enormous difference in outcomes. How Tactical Law Can Help At Tactical Law, we have deep experience advising companies on their Oracle relationships. We understand how Oracle structures its sales organization, how it uses customer data to drive its licensing and audit strategies, and how companies can protect themselves from being outmaneuvered. Whether you are preparing for an Oracle license audit, negotiating a complex renewal, evaluating a migration to Oracle Cloud or away from Oracle entirely, or simply trying to get a handle on your current Oracle exposure, our team can help you develop a strategy that protects your interests and your budget. Oracle has a database full of information about you. We help you make sure the playing field is level. Contact Tactical Law today to learn how we can help your organization take control of its Oracle relationship. Disclaimer: This article is provided for informational purposes only and does not constitute legal advice. The discussion of Oracle v. Kelkar is based on allegations contained in the publicly filed Complaint and does not represent findings of fact by any court. |
By Tactical Law Attorneys and From Time to Time Their Guests
|
RSS Feed
tactical law group llp |
COPYRIGHT TACTICAL LAW GROUP LLP 2016-2026. ALL RIGHTS RESERVED
|
Legal Disclaimer: Contents may contain attorney advertising under the laws of some states. Prior results do not guarantee a similar outcome.