What the buyer is actually acquiring
In a technology transaction, most of the enterprise value sits in intangibles. Source code, patents, trade secrets, brands and data. The physical assets are incidental.
That makes intellectual property diligence the area where a transaction is most likely to encounter a problem that cannot be negotiated away, because unlike a commercial issue it is frequently binary. Either the seller owns the thing being sold or they do not.
Start with your own audit
Run the diligence on yourself before a buyer runs it on you. Five areas.
Patents and applications, with jurisdictions, expiry dates, maintenance status and any licence granted to a third party.
Software, meaning the proprietary codebase, the third-party components inside it, and every open-source dependency with its licence.
Trade secrets, meaning the algorithms, processes and datasets that carry advantage, together with evidence that they have been treated as confidential. A trade secret nobody protected is not a trade secret.
Trademarks, domains and brand assets, including the ones registered in an employee's name because that is who filled in the form six years ago.
Data, including customer data, and for machine learning businesses the training data and its provenance.
Open source is where problems are found
Every modern codebase contains open-source components, and most of the licences are benign. The exceptions matter a great deal.
Copyleft licences, principally the GPL family and the AGPL, can require that source code combined with them is made available. Where such a component has been linked into a proprietary product rather than kept at arm's length, the remedy can involve re-engineering, and discovering that during diligence is expensive in both time and price.
Permissive licences such as MIT and Apache are straightforward but still carry attribution obligations that are frequently unmet.
Buyers run automated scanning, and the tools are good. Run the same scan yourself during preparation and remediate what it finds. A clean scan report in the data room removes an entire diligence workstream. A scan the buyer runs first hands them a finding to price.
Shared code in a carve-out
Where the division shares a codebase with the parent, three questions have to be answered before launch.
What transfers. Draw the boundary by what the division developed and what it uses, and write it down rather than leaving it to be inferred from the repository structure.
Whether the parent needs a licence back. If code going with the division is embedded in products the parent is keeping, the parent needs a perpetual royalty-free licence, and negotiating that after signing is negotiating from a weak position.
Whether the division needs parent technology. Frequently yes, at least for a transition period, and sometimes permanently. That licence belongs in the transaction documents rather than the transition services agreement, because it outlives the transition.
Licences that do not transfer
Many third-party agreements are not freely assignable, and several patterns recur.
Change-of-control provisions requiring consent, which gives the licensor a moment of leverage they will sometimes use. Enterprise agreements covering the whole parent group, where the divided entity has no standalone contract at all. Volume pricing that reverts to list when the division buys alone, which belongs in the standalone cost model. And geographic restrictions that do not match where the buyer operates.
Start the consent process early and expect some licensors to treat the transaction as a renegotiation.
Assignments from people
Confirm that everyone who wrote anything material assigned it. Employees, contractors and founders.
Three groups produce most of the gaps. Early employees who joined before the company had proper documentation. Contractors, particularly outside the United States, where default ownership rules differ and an assignment clause drafted for one jurisdiction may not work in another. And former employees whose contributions remain in current products.
Missing assignments are among the most common material diligence findings, and remediating them after someone has left is difficult and sometimes impossible.
Protecting it during the process
You are about to show the crown jewels to several parties, some of whom may be competitors.
Stage the technical disclosure. Architecture and documentation early, source code access late and only to a shortlisted party under a specific arrangement. Use a clean room or supervised review for code rather than uploading the repository. Watermark everything and keep the access log.
The working assumption should be that whatever a competitor reads, they retain. That is not a reason to refuse diligence. It is a reason to sequence it so that the most sensitive material is only seen by the party most likely to complete.
Editorial Team · Published for orientation, not as advice on a specific transaction. Any figure cited is orientation, not a valuation. See market notes.