IP, code and contract transfers in a software sale

A software business is mostly intangible: code, brand assets, customer contracts and, often, personal data about users and customers. Unlike equipment or inventory, none of that transfers automatically just because a purchase agreement says the business is sold — each category has its own legal mechanics, and a gap in any one of them is a common reason software deals stall or get re-priced late in the process.

Confirming the business actually owns its IP

The starting point of any technology sale is confirming that the company itself — not a founder personally, not a departed co-founder, not a contractor or agency that built part of the product — holds a clear, documented chain of assignment for the source code and any other IP the business relies on. Work built by employees is often owned by the employer automatically depending on the circumstances, but work built by contractors generally is not unless a written assignment says so, which is why contractor agreements are one of the first things a buyer’s lawyer will ask to see.

Trademarks, domains and brand assets

Beyond the code itself, confirm who legally holds the business’s trademarks, registered or not, and who controls the domain names and any related accounts the business depends on — these are sometimes registered in a founder’s personal name rather than the company’s, especially in businesses that started informally, and untangling that after a sale is agreed is avoidable friction that a buyer’s lawyer will flag immediately during diligence.

Source code escrow

Some software deals include a source code escrow arrangement, where a copy of the code is held by an independent third party and released to the buyer under specific, pre-agreed conditions — useful in some deal structures as a form of protection, though it is one tool among several rather than something every software sale requires. Whether it makes sense for a given deal depends on the structure of the transaction and how the parties are protecting the buyer’s access to what they are paying for, and is worth discussing with your lawyer rather than assuming it is either always needed or never needed.

Assignable contracts and anti-assignment clauses

Customer contracts, vendor agreements, API and platform terms, and software licences the business relies on may or may not transfer automatically in a sale — many contracts contain an anti-assignment clause requiring the other party’s consent before the agreement can be assigned to a new owner, particularly in a share sale where the counterparty might otherwise not even be told, or an asset sale where assignment is explicit. Reviewing every material contract for this clause before closing, rather than discovering it after, is one of the more tedious but genuinely important steps in a technology sale.

Customer data and privacy on transfer

If the business holds personal information about customers or users, transferring that data as part of the sale is subject to federal privacy law and, depending on what is collected and from whom, potentially additional obligations, not simply a matter of the purchase agreement listing the customer database as an asset. In general terms, customers may be entitled to notice, and their consent may be relevant depending on how the data was originally collected and what it will be used for going forward — the specific mechanics depend on the facts and should be confirmed with a privacy-aware lawyer rather than assumed.

Why this needs a lawyer, not just a checklist

IP ownership, contract assignment and data transfer each turn on the specific documents and facts of the business being sold, and a gap discovered during diligence is far cheaper to fix before a deal is signed than after — sometimes it cannot be fixed at all once a departed contractor or co-founder is no longer cooperative. Get a lawyer experienced in technology transactions involved early enough to review these points before you are negotiating price under time pressure.

Open source licence compliance

Most software products are built partly on open-source components, and confirming which licences those components carry, and what obligations each licence imposes, is part of a thorough IP review before a sale closes. Some open-source licences require that source code built on top of them also be shared or licensed on similar terms, which can directly affect what a buyer is legally able to do with the product after purchase, while others impose lighter obligations like attribution only. A buyer relying on an incomplete or informal inventory of open-source dependencies is taking on risk they cannot properly price, and a seller who has never audited this is likely to be asked to do so during diligence regardless. Building or reviewing a dependency inventory before going to market, rather than assembling one under time pressure once a buyer asks, is a straightforward way to avoid this becoming a late-stage obstacle.