|
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.
0 Comments
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 Pam Fulmer
This is the first in a series of articles from Tactical Law examining the SAP licensing landscape and what it means for your organization. If your company runs SAP, there's a good chance you'll face a license audit in the next few years — and the outcome may cost you far more than you expect. SAP's license audit program has become one of the company's most effective tools for generating new revenue. Buried in most SAP contracts is a clause granting SAP the right to review your license compliance, typically on an annual basis. While not every customer is audited every year, SAP's Global License Audit & Compliance team selects targets strategically — and when they come knocking, the financial stakes can be significant. How the Audit Becomes a Sales Conversation Here's what many SAP customers don't realize until they're in the middle of it: an audit finding isn't a fine. It's the opening move in a negotiation. When SAP identifies a licensing shortfall — whether that's too many users, the wrong user classifications, or unlicensed system integrations — the compliance team works in coordination with SAP's sales organization. The shortfall creates urgency. The sales team then presents the remedy: additional licenses, a conversion to RISE with SAP, adoption of a new licensing model, or an expanded cloud subscription. Customers mid-migration to S/4HANA are particularly exposed, because they're already committed to a massive project and have limited leverage to push back. Where SAP Focuses Its Audits SAP's audit teams have become increasingly sophisticated about where they look. Four areas dominate current audit activity: Indirect access is the most consequential. Whenever a third-party system — your e-commerce platform, CRM, supplier portal, or any external application — reads from or writes to SAP, SAP takes the position that those interactions require licensing. Under their Digital Access model, this is measured by counting business documents like sales orders and invoices created by outside systems. For companies with heavily integrated environments, the exposure can be substantial. User classification is another frequent finding. SAP licenses are tiered by the transactions a user is permitted to run, and each tier carries a different price. If an employee classified at a lower tier has executed even a single transaction reserved for a higher tier, SAP will argue that person should have been licensed at the more expensive level — across your entire user base, these reclassifications add up quickly. S/4HANA migration compliance has become a major focus as SAP's 2027 end-of-support deadline for the older ECC system approaches. Companies running both systems in parallel during migration face the risk of double-counting licenses, and SAP's licensing metrics change between ECC and S/4HANA — meaning what was compliant under the old system may not be under the new one. HANA memory consumption rounds out the list. As data volumes grow, SAP checks whether your actual database memory usage exceeds what you've licensed. Why This Matters Now The 2027 ECC end-of-support deadline is accelerating everything. Every company still running the older SAP system faces a decision — migrate to S/4HANA, move to SAP's cloud offering, or find an alternative. SAP's audit activity tends to intensify during these transition windows, because customers facing a deadline are far more likely to settle compliance disputes quickly in exchange for favorable migration terms. In short, the audit isn't just about compliance. It's a strategically timed part of SAP's commercial playbook. How Tactical Law Can Help Navigating an SAP audit requires a clear understanding of your contractual rights, your actual usage patterns, and SAP's negotiating tactics. Many organizations go into these conversations underinformed and come out having agreed to terms they didn't need to accept. Tactical Law works with companies to evaluate their licensing exposure, prepare for audit engagements, and negotiate from a position of knowledge rather than surprise. Whether you're facing an active audit, planning an S/4HANA migration, or simply want to understand where you stand, we can help you see the full picture before SAP defines it for you. Have questions about your SAP licensing situation? Contact us to start a conversation. |
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.