IP Due Diligence for M&A: A Founder's Guide to Passing

Your IP Is Why They’re Buying You—Don’t Let It Become a Liability

In a tech acquisition, the buyer isn’t acquiring your office lease or your team’s winning personalities. They’re acquiring your code, patents, data, and brand. This intellectual property is the core of your company's value.

But for an acquirer, that IP is also a bundle of potential liabilities. A messy ownership history or a single poorly-chosen open-source library can turn your crown jewel into a toxic asset. During M&A, the buyer’s lawyers will put your IP under a microscope. If they find problems, the consequences are severe: a lower valuation, millions in escrow, a delayed closing, or a dead deal.

Your job is to get your IP house in order long before a buyer comes knocking. You need to switch from a "move fast and break things" mindset to a "prepare for scrutiny" one. This is non-negotiable for a successful exit.

The 4 IP Deal-Killers (And How to Fix Them)

Assume a buyer will find everything. Their diligence process is designed to uncover hidden risks, and their lawyers are experts. Most deal-killing IP issues fall into one of four categories. Here’s what they are and how to get ahead of them.

1. The "Chain of Title" Catastrophe

The Mistake: You don’t have clean, provable ownership of 100% of your own product.

The Non-Obvious Consequence: An acquirer must have absolute certainty you own everything they’re buying. An unbroken “chain of title” is the proof. A single missing signature from an early freelance developer can give a buyer leverage to demand a specific indemnity, holding back 10-20% of the purchase price in escrow for several years. Worse, they may walk away, fearing the developer could surface post-acquisition and sue for a share of the company's value.

Missing CIIAAs: Every single person who has ever contributed to your product—founders, employees, interns, and especially contractors—must have signed a Confidential Information and Invention Assignment Agreement (CIIAA). This isn’t just boilerplate; it’s the document that legally transfers IP ownership to the company. · University IP Taint: Did you build the prototype while you or a co-founder were students or faculty at a university? If you used university laptops, servers, labs, or were funded by a university grant, the school’s tech transfer office might have a legal claim to your core IP. Buyers are terrified of this and will dig into your founding story to verify a clean break. · Side Project Contamination: If your product spun out of a founder’s prior side project or work for a previous employer, that ex-employer might have a claim. You must be able to prove that no proprietary code, assets, or time-on-the-job were used to build the initial version of your product.

Conduct a Contributor Audit: Create a spreadsheet of every person (full-time, part-time, contractor, intern, advisor) who has ever contributed code, design, or other IP. · Verify Every Signature: Match each person on that list to a signed, dated CIIAA. Store these documents in a secure digital folder labeled "CIIAAs." · Remediate Gaps Immediately: If you find a gap, especially with a past contributor, this is your top priority. Engage your lawyer, contact the person, and get the signature. Be prepared to offer a modest payment (e.g., $500) for their time and cooperation. Frame it as standard legal housekeeping. · For Contractors: Ensure their agreements contain specific "work for hire" language and explicitly state that all intellectual property is assigned to your company.

2. Open Source Software (OSS) Contamination

The Mistake: Using "free" code that legally forces you to give away your proprietary code.

The Non-Obvious Consequence: Using a 'copyleft' licensed library isn't a minor compliance issue; it’s a potential decapitation of your IP value. If a buyer's scan reveals your core, proprietary algorithm is linked to a GPL-licensed library, they will conclude you are legally obligated to make your own source code public. This can halt the deal instantly. There is no easy fix.

A buyer will use tools like Snyk, FOSSA, or Black Duck to scan your entire codebase. They will generate a complete Bill of Materials (BOM) of every OSS component and its license. This is not something you can hide.

Permissive Licenses (The Good): MIT, Apache 2.0, BSD, and ISC licenses are your friends. They allow usage with minimal restrictions, typically just requiring you to preserve copyright notices. Acquirers are perfectly fine with these. · "Copyleft" / Restrictive Licenses (The Bad): These are the danger zone. · GNU GPL (v2, v3): Requires that any code that links to it must also be made available under the GPL. If your proprietary code calls a GPL library, you've likely 'infected' your code. · AGPL (The Ugly): The Affero GPL is even more restrictive. It can trigger copyleft provisions even if your software just interacts with the AGPL code over a network—a common scenario for web services. An AGPL-licensed database driver in your backend could force you to open-source your entire backend application.

Scan Your Code Now: Use a commercial scanning tool to get a full OSS inventory. Don't wait for the buyer to run their scan. · Establish a Formal OSS Policy: Create a short internal document that: · Whitelists approved permissive licenses (MIT, Apache 2.0, etc.). · Blacklists all copyleft licenses (GPL, AGPL). · Creates a Process for any developer to request an exception, which must be approved by an engineering leader and, if necessary, your legal counsel. · Remediate High-Risk Code: If you find GPL or AGPL code linked to your core IP, immediately create a plan to architect it out and replace it with a permissively licensed alternative. This can be a significant engineering effort, so starting early is critical.

3. Hidden Disputes and Litigation Risk

The Mistake: Believing a cease-and-desist letter you ignored two years ago is no longer a problem.

The Non-Obvious Consequence: An acquirer inherits your liabilities. In the purchase agreement, you will be asked to legally "represent and warrant" that there are no ongoing or even threatened legal disputes regarding the IP. If you fail to disclose a past threat, and it resurfaces after closing, the buyer can claw back a portion of the purchase price from you personally under the indemnification clause. The cover-up is always worse than the crime.

Disclosure Schedules: You will be required to list any known or threatened litigation. · Email Searches: Diligence will often include searching company emails for keywords like "infringement," "patent," or "cease and desist." A casual, joking email can become a serious problem. · Specific Indemnities: If a known risk exists (e.g., a pending patent lawsuit), a buyer won't just walk. They'll demand that a significant portion of the deal price (potentially millions) be held in escrow for 1-2 years to cover any potential fallout.

Create a Disclosure File: Keep a clean, organized record of any IP-related complaints or threats, formal or informal. Document the steps you took to respond and resolve them. · Control Your Communications: Instruct your team to never admit fault or speculate on IP validity in writing. All communication regarding potential disputes should be routed through your legal counsel. · Be Proactively Transparent: During M&A, it is far better to proactively disclose a minor, settled issue and frame the narrative than it is to have the buyer discover it independently and lose all trust in you.

4. The Digital & Data Asset Mess

The Mistake: Your company's critical digital assets are registered to a founder’s personal email address.

The Non-Obvious Consequence: The buyer needs a clean, immediate transfer of all assets at closing. If your company’s domain name is in your personal GoDaddy account and the AWS account is tied to a departed co-founder's credit card, the closing process becomes a chaotic scramble. It signals operational immaturity and can even give a disgruntled employee leverage. Furthermore, poor data handling practices can render your user base—a key asset—untransferable.

Personal Ownership of Assets: The company domain, social media handles, and cloud infrastructure accounts are registered to individuals, not a central company alias (e.g., admin@yourcompany.com). · Privacy Policy Flaws: Your privacy policy lacks a "Successors" or "Business Transfer" clause. Without it, you may not have the legal right to transfer your user database to the acquirer, potentially destroying the value of a consumer application. · Ignoring Data Security: You haven't performed regular security audits or penetration tests. A buyer's cybersecurity diligence will uncover this, raising red flags about your ability to protect customer data in compliance with GDPR, CCPA, and other regulations.

Audit Your Digital Assets: Create a spreadsheet of all key digital assets (domains, social media accounts, cloud services, code repositories). For each, list the registered owner/email, renewal date, and who has administrative access. · Centralize Ownership: Transfer all assets from personal accounts to a generic company alias accessible by multiple trusted principals. Use a shared password manager (like 1Password Teams) to manage credentials securely. · Review Your Privacy Policy: Ask your lawyer to confirm your privacy policy and terms of service allow for the transfer of PII in an M&A transaction. If not, update it. · Document Your Security Posture: Have your SOC 2 report, latest penetration test results, and incident response plan ready to share. Demonstrating mature security practices builds significant buyer confidence.

How to Apply This: Your Pre-Diligence Action Plan

Don’t wait for an LOI to arrive. A disciplined founder prepares for an exit years before it’s on the horizon. This preparation not only makes a future M&A process smoother but makes your company fundamentally more resilient and valuable.

Build your IP "Data Room" now. Create a folder structure on a secure drive. Start populating it today with your CIIAA folder, a running list of your registered IP (patents, trademarks with numbers and dates), your OSS policy, and your digital asset audit spreadsheet. · Run your first OSS scan. Use a tool with a free tier (like Snyk) to get an initial baseline of your codebase. This is a morning’s worth of work that can save you millions. · Hold an ownership remediation session. Sit down with your co-founders and make a list of every person who has ever contributed. Check for gaps in your CIIAA folder. For any missing signatures, assign a founder to begin outreach this week. · Schedule a privacy policy review. Send your current Terms of Service and Privacy Policy to your lawyer with a specific request: "Please confirm we have the necessary language to transfer user data in the event of an acquisition."

M&A is a game of risk mitigation for the buyer. The cleaner your story and the more organized your IP house, the faster and more certain your path to a successful closing.