This post uses hypothetical scenarios for illustrative purposes only. It does not describe any actual client, transaction, or representation, and is not legal advice.
Software M&A tends to look clean at signing and messy eighteen months later. The reason is not that buyers or sellers behave badly — most do not. The reason is that a modern software company is a stack of assets no human being fully inventoried on the day the purchase agreement was signed. Nobody in the data room read every open-source license. Nobody tested whether the escrow deposit at the neutral agent actually builds. Nobody confirmed the top-fifty customer contracts survive a change of control without written consent. And nobody anticipated a former engineer filing a trade-secret suit twenty-two months after closing, naming the buyer as the deep-pocket defendant. The rep-and-warranty section is written in the language of certainty. Post-closing software litigation is what happens when that certainty encounters the actual codebase. What follows walks through the categories that surface after closing, in the order they typically appear, tracking the 2024–2025 Chancery line on knowledge scrapes, materiality qualifiers, and the interaction with R&W insurance. Everything below is doctrinal and hypothetical.
Intellectual property rep breaches — the infringement claim that surfaces at month nine
The IP rep is the most heavily negotiated representation in a software purchase agreement, and it is also the most commonly breached. The reason is structural. The rep typically states that the target owns or has the right to use all intellectual property used in the business, that operation of the business does not infringe any third party’s IP, and that no such claim has been threatened or is pending. Every one of those clauses is a bright line. The problem is that the target — especially a founder-led target — cannot possibly know its software does not infringe anyone’s patent, because software patents are numerous, obscurely worded, and often asserted years after the accused product was built. What surfaces at month nine is a demand letter from a non-practicing entity asserting that the acquired product infringes a patent nobody at the target had ever heard of. The buyer tenders the claim under the indemnification article. The seller says the rep was qualified by knowledge. The parties then dispute what “knowledge” means — actual knowledge of the specific patent, knowledge after reasonable inquiry, or constructive knowledge of any risk in the field. Delaware courts have consistently held that unqualified reps mean what they say; an unqualified “does not infringe” rep is a strict-liability warranty and the seller pays the indemnity subject to the cap.
The defensive drafting is well understood but often skipped. A seller can push for a knowledge qualifier, a materiality qualifier, and an express carve-out for patents asserted by non-practicing entities. Buyers resist all three, and in a hot process sellers rarely hold the line. The interaction between the IP rep and the indemnification cap is the point I made in the seller-friendly vs. buyer-friendly deal terms post, and it applies here with force.
Open-source license claims — the GPL contamination the buyer finds in code review
Open-source contamination grew from a footnote in 2015 to a first-order diligence item today. The classic hypothetical: the buyer’s post-closing engineering team runs a software-composition-analysis tool over the acquired codebase and discovers that a core library is licensed under the GPLv3. The GPLv3’s copyleft provisions require that any distributed derivative work be released under the same license. If the acquired product has been distributed to customers as a proprietary binary, the theory goes, the product is out of compliance and the entire codebase may be at risk of a copyleft claim from the upstream contributor.
Whether that theory holds up turns on facts — whether the linkage was static or dynamic, whether the product was “distributed” in the copyleft sense or merely offered as a SaaS, whether the derivative-work analysis under U.S. copyright law reaches the accused code, and whether the upstream contributor has standing to sue. But the risk is real enough that a buyer discovering GPL contamination will almost always assert a rep breach under the IP-ownership representation and, separately, under compliance-with-laws. The remediation cost — refactoring the affected code or negotiating a commercial license — is what the buyer claims as damages. Where the sums are meaningful, the dispute drives to indemnification arbitration or, if the R&W policy triggers, to a coverage claim against the insurer.
Software escrow disputes — the deposit that turned out to be a shell
Software escrows are most often seen in enterprise licensing arrangements — the target licenses mission-critical software to a customer, the customer insists on a source-code escrow with a neutral third-party agent, and the escrow is triggered on defined events like bankruptcy, discontinuation of support, or a change of control. In the post-closing dispute, the customer triggers the escrow and the buyer discovers that the deposit is outdated, incomplete, or does not build. The dispute becomes tri-lateral. The customer sues the acquired entity for breach of the escrow agreement. The buyer asserts a rep breach against the seller, arguing that the target represented that its escrow deposits were current. And the escrow agent, depending on its own agreement terms, may be exposed for failure to verify what it was holding. A buyer’s diligence checklist should include the last escrow verification report and, ideally, a build test by an independent third party. The cost is trivial compared with the cost of the post-closing fight.
SaaS uptime and SLA disputes
A SaaS master agreement typically commits to a monthly uptime percentage — 99.9%, 99.95%, 99.99% — with defined service credits payable if the target misses the commitment. In diligence, the buyer requests the SLA history for the last twenty-four months. In the purchase agreement, the seller represents that the target has complied in all material respects with its customer contracts. Post-closing, if the buyer discovers that the SLA history was misreported — outages classified as “scheduled maintenance” when they were not, regional degradations excluded from the uptime calculation when they should have been included — the buyer has a rep-breach claim, and the customers often have parallel service-credit claims of their own. If enough customers assert service credits to trigger a termination right, the buyer’s customer-retention damages can dwarf the direct credit amounts.
Third-party vendor and change-of-control license issues
Every software company sits on a stack of third-party licenses — cloud infrastructure, developer tools, APIs, embedded components, database engines, ML models. A meaningful fraction contain change-of-control clauses. Some require written consent; some require notice and a step-up fee; some are silent, which under many state laws means the license is personal and does not automatically transfer. Post-closing, a cloud vendor or embedded database licensor notices the ownership change and asserts either a termination right or a demand for materially higher pricing. The buyer’s indemnification claim runs on the compliance-with-material-contracts representation, sometimes supplemented by a specific change-of-control rep. Whether the claim succeeds depends on whether the seller disclosed the trigger in the schedules and whether the buyer waived by closing with knowledge.
Trade-secret claims from former employees and competitors
Post-closing trade-secret claims are among the most damaging category of software-M&A disputes, because they can lead to injunctive relief against the buyer’s use of the acquired code. The typical pattern: a former engineer of the target, now at a competitor, alleges that the code developed while she worked there incorporated trade secrets she brought from an earlier employer. Or a competitor alleges that a target founder left with confidential source code. Either theory, if credited, supports a claim under the federal Defend Trade Secrets Act or the state trade-secret statute, both of which authorize injunctive relief and enhanced damages. The purchase agreement typically addresses this through a rep that the target’s IP was developed without misappropriation of third-party trade secrets and, separately, that employees who contributed to the codebase executed valid proprietary-invention-assignment agreements. Where R&W insurance is in place, the policy may respond to a covered claim, subject to a familiar list of exclusions.
Cybersecurity incident disclosure gaps
A category that has grown quickly since 2023 is post-closing disputes over undisclosed cybersecurity incidents. The rep at issue is compliance-with-privacy-and-security-laws, often paired with a specific representation that there have been no material security incidents in the last thirty-six months except as disclosed. Post-closing, the surfacing event is either a delayed regulatory action — a state attorney general’s inquiry into a breach the target knew about and did not disclose — or a class action under a state biometric or consumer-privacy statute. The rep breach interacts with the notice provisions in the buyer’s cyber policy, with the SEC’s cybersecurity disclosure rules for public buyers, and with the R&W policy’s cyber exclusions. The takeaway is that a seller who does not surface an incident in diligence pays for it later, usually at a multiple of the cost of disclosure.
Defensive drafting — carve-outs, materiality qualifiers, knowledge scrapes, R&W interaction
Everything above is downstream of the drafting choices made in the four-week window between the LOI and the signing of the purchase agreement. On the seller side, the strongest protections are a defined-term “Knowledge” that lists specific individuals and requires only their actual knowledge, a materiality qualifier on the IP-non-infringement rep, an express carve-out for open-source components disclosed on a schedule, a survival period shorter than the buyer’s opening ask, and a cap on indemnification at a percentage of the purchase price. On the buyer side, the moves are the opposite: a broad knowledge definition, a knowledge scrape that reads the qualifier out for damages purposes, a specific IP-ownership rep with no knowledge qualifier at all, extended survival for the IP reps, and an escrow or holdback tied to the cap.
The interaction with the R&W policy is the last piece. R&W insurance is standard in software deals above roughly thirty million enterprise value, though the threshold has moved down. The policy’s exclusions do the important work. Standard exclusions include known matters, interim-breach matters, forward-looking financial reps, and specific categories like open-source contamination or unresolved trade-secret claims. The seller’s hope in a “public-style” deal is that the buyer’s post-closing recourse runs to the insurer rather than the escrow. The buyer’s hope is that the excluded matters remain excluded from the policy but not from the seller’s direct indemnification. The gap between those two hopes is where the litigation lives.
None of this makes software M&A more dangerous than any other kind — the deals close, the codebases integrate, and the founders and buyers move on. But the post-closing profile of a software deal is different from a services deal or a manufacturing deal. The claims arrive later, they arrive through vectors nobody wrote about at signing, and they are harder to resolve because the facts — what the code does, who wrote it, which license governs — require expert analysis long after the diligence team has moved on. A buyer and a seller who understand that profile at the LOI stage write a better purchase agreement and spend less time in the arbitration room three years later. That framing connects back to the broader M&A process I’ve written about at the M&A practice page. For a helpful overview from the insurance side of R&W underwriting, see the AIG M&A insurance overview.
If you are a founder or a buyer working through a software transaction and want to talk through the post-closing risk profile, feel free to reach out to my firm manager, Magda, at Magda@montague.law, or fill out our contact form. Mention you read this post.
— John
