When a corporate development team acquires a software company, the stated rationale is almost always some version of: we're acquiring the technology. The IP stack is the asset. What diligence practice reveals, deal after deal, is that "the IP" is not a single thing — it's a collection of ownership claims, license rights, assignment chains, and use restrictions that collectively determine what the acquirer actually gets.
IP carve-outs — provisions that exclude specific IP from ownership claims or license grants — are one of the most structurally important categories to extract in a technology acquisition. They're also among the most dispersed across the data room. A single carve-out finding might require cross-referencing a software license agreement, its attached schedule of licensed components, an employment agreement defining the employee's pre-existing IP, and an invention assignment agreement that covers a narrower scope than the employment agreement suggests.
The three categories that matter most
Inbound license restrictions. The target has licensed software from third-party vendors — infrastructure providers, data vendors, specialized tools. Those inbound licenses almost certainly contain restrictions on what the licensee can do with the licensed technology: permitted use restrictions, sublicense prohibitions, combination restrictions, restrictions on modifications. When the acquirer takes over the target, those restrictions transfer. If the acquirer's intended use of the acquired technology stack exceeds the permitted use in the inbound licenses — for instance, integrating the licensed software into the acquirer's existing product in a way the license doesn't permit — the acquisition doesn't include that right, regardless of what the deal documents say.
The practical implication: the acquisition agreement can transfer every IP right the target has. It cannot transfer rights the target never had. IP carve-out extraction from inbound licenses identifies the boundaries of what the target actually owns or controls.
Open-source obligations. Virtually every software product built in the last decade incorporates open-source components. The license terms governing those components vary significantly. Permissive licenses (MIT, BSD, Apache 2.0) impose minimal obligations. Copyleft licenses (GPL v2, GPL v3, AGPL) impose distribution obligations that can affect the acquirer's ability to maintain the existing product distribution model. A GPL v3 license in a component that's linked into the core product creates a disclosure and distribution obligation that attaches to the combined work — obligations that transfer to the acquirer and that may conflict with the acquirer's existing licensing model.
Open-source obligation extraction doesn't require reading every line of the target's codebase. It requires reading the technology agreements and license schedules in the data room that reference or identify the open-source components. Most mature software companies have a software bill of materials or equivalent schedule. Many don't. Extraction from the available documentation surfaces what's visible; gap analysis of what's not documented is a separate diligence task.
Assignment chain completeness. In early-stage technology companies — the kind that are typically acquisition targets in the $20M-$200M range — IP ownership runs through a chain of employment agreements, contractor arrangements, and specific assignment agreements that were executed at various points in the company's history. The IP assignment is only as strong as the weakest link in that chain.
Common gap patterns: a founding engineer who contributed code before signing an invention assignment agreement; a contractor who built a material component under an agreement that didn't include a work-made-for-hire clause or an explicit assignment; an early advisor agreement with retained IP rights that covered work in the same technology area as the core product. These aren't edge cases — they're routine in the diligence of technology companies that grew from a small team.
What extraction surfaces and what it doesn't
An IP carve-out extraction across the data room surfaces the documented provisions: the license restrictions in the agreements, the carve-outs in the employment terms, the assignment language in the contractor arrangements. It does not fill in what's not there. If the target has oral contractor arrangements, undocumented IP transfers, or agreements that were never placed in the data room, extraction from the data room will not find them. That's a gap identification task — knowing what documentation should exist and checking for its absence — that falls to the attorney reviewing the extraction output.
The value of extraction in IP diligence is not replacing attorney review. It's making sure the attorney's review time is applied to the complete set of documented provisions, not a sample. In a technology acquisition with a data room containing 200 employment agreements and 150 contractor arrangements, a manual review might cover 40 employment agreements and 20 contractor arrangements. Extraction covers all 350 documents for the specific provision types that determine IP ownership completeness.
The integration question starts during diligence
Acquirers who get the most value from IP diligence are the ones who start the integration analysis during the diligence period. The extraction output isn't just a risk report — it's the input to the question: given what we know the target owns and licenses, what can we actually do with it after close? Which inbound licenses need renegotiation before integration? Which open-source obligations require disclosure decisions? Which assignment gaps need cure prior to closing?
Those questions have easier answers when they're identified before signing than after. Post-close, the counterparty's negotiating position on a license renegotiation is different from their pre-close position when the deal hasn't yet closed and the acquirer still needs their consent.