Software intellectual property due diligence verifies whether a target company can prove it owns, controls and can transfer the software value being acquired. It tests the evidence behind code ownership, contractor assignments, open source obligations, AI-assisted code provenance, trade secret controls and escrow arrangements so legal IP work is supported by technical facts.
For investors and acquirers, the risk is practical. Valuation often assumes the buyer can own, sell, integrate, improve and defend the product. Unassigned contractor work, copied components, poorly governed open source, unclear repository control or undocumented AI-assisted development all need evidence.
FoundationState's technical due diligence service treats software IP as a bridge between legal, technical and operational diligence. In our diligence engagements we typically move from scoping, to data room review, to evidence evaluation, to interviews, to findings calibration and readout. The aim is to show whether the technical record supports the ownership story counsel is being asked to rely on.
What does software intellectual property due diligence assess?
Software intellectual property due diligence assesses the ownership chain behind the target's proprietary product. It asks who wrote material code, under what relationship, where that code now sits, which third-party obligations apply and whether the buyer can inherit the asset without hidden restrictions.
The UK Intellectual Property Office is the relevant UK authority for intellectual property policy and guidance. In a transaction, specialist legal counsel interprets the law and contract position. Technical diligence supports that work by checking whether repositories, dependency records, access history and development process match management's claims.
The review usually covers:
- Ownership chain: employees, founders, contractors, agencies, offshore teams, acquired teams and any code brought in from previous ventures.
- Repository control: who owns source control accounts, build pipelines, deployment scripts, infrastructure definitions and package registries.
- Third-party code: open source packages, commercial SDKs, copied snippets, source-available components and generated artefacts.
- Provenance evidence: commit history, authorship patterns, pull requests, ticket links, design records and release history.
- Confidentiality controls: trade secret handling, access restrictions, leaver processes and use of external development tools.
- Transfer readiness: whether the buyer can obtain source, credentials, documentation, licences and escrowed materials if the deal requires them.
How do you prove the software ownership chain?
The ownership chain starts with people and entities. A target may have code written by employees, founders, freelancers, agencies, outsourced teams, interns, open source contributors, consultants or engineers from a company it previously acquired.
Employee-created code is usually simpler to evidence when contracts, role descriptions, repository history and work patterns align. Founder-created code can be more complicated if the product began before incorporation, early prototypes sat in personal accounts, or components came from a previous employer or venture.
Contractor and agency-created code needs more active testing. Supplier contracts may include IP assignment clauses, but technical review verifies what those suppliers contributed. Commit authorship, pull requests, repository permissions, deployment access and documentation ownership can show whether the supplier provided capacity or still holds critical product knowledge.
Acqui-hired or acquired code introduces another step: whether previous transactions assigned the relevant rights, whether the inherited code is still used, and whether old licensing, customer-hosting or confidentiality obligations remain attached.
A practical ownership-chain register is often enough for deal purposes:
| Evidence area | What to verify | Deal implication if weak |
|---|---|---|
| Founders and early code | Incorporation timing, personal repositories, prior-employer overlap | Core product rights may need warranties or pre-close clarification |
| Employees | Employment contracts, repository history, role records | Usually manageable if contracts and contributions align |
| Contractors and agencies | Assignment clauses, statements of work, commit authorship, access history | Buyer may not control material code or handover knowledge |
| Acquired or transferred code | Purchase records, repository lineage, retained obligations | Legacy rights may be unclear or incomplete |
| Third-party components | Licence terms, dependency inventory, notices, commercial licences | Product use may require remediation, attribution or legal review |
| AI-assisted code | Policy, tool settings, review records, sensitive-input controls | Provenance and confidentiality questions may remain unresolved |
Where do contractor and agency assignment gaps appear?
Assignment gaps often appear where commercial urgency moved faster than governance. Early-stage companies may hire a freelancer before contracts exist, use an agency to build a first product, rely on offshore teams for maintenance, or ask a specialist to implement a critical integration under a vague statement of work.
In UK software transactions, paying for development does not by itself prove ownership. Legal counsel needs the exact contract position. Technical diligence sharpens that review by identifying which suppliers touched material product code, which repositories they accessed, and whether their work remains in production.
Common warning signs include supplier accounts with admin access, contractor commits in core modules without assignment evidence, production systems documented only by an agency, code delivered as a compiled artefact without source, and unclear ownership of deployment scripts or infrastructure-as-code. These issues overlap with engineering team due diligence because IP ownership and key-person dependency often travel together.
The response should be proportionate. A missing signature for a low-risk internal tool may be housekeeping. A missing assignment for the billing engine, matching algorithm, data pipeline or customer-facing application may affect warranties, completion conditions, valuation or the first 100 days after close.
How do open source and AI-assisted code affect IP risk?
Open source does not usually undermine a software acquisition by itself. Mature software companies use it extensively. The diligence question is whether the target knows what it uses, understands the obligations and can show licence requirements do not conflict with the buyer's plan.
Copyleft, source-available and commercial licence obligations can dilute the buyer's practical control if found late. A component may require attribution, source-sharing, modification disclosure, usage limits or a paid licence. The open source licence compliance in M&A review should connect dependency records, SBOM evidence, legal interpretation and product distribution model.
AI-assisted development creates a newer provenance layer. The issue is not that AI-generated code is automatically unusable. The risk is weak process: engineers pasting proprietary code into unmanaged tools, accepting generated output without review, or being unable to show how material features were created. A credible target should have a policy, approved tooling and review expectations.
In our diligence engagements we look for consistency. Repository history, dependency manifests, SBOM outputs, developer interviews and policy documents should tell a coherent story. If the data room says the product is proprietary but the codebase shows copied snippets, untracked packages or unexplained generated code, the buyer needs a calibrated finding.
What evidence can technical review provide to legal counsel?
Technical review turns IP claims into evidence. It cannot decide legal ownership, but it can show whether the factual record is strong, incomplete or contradictory.
Useful evidence includes repository maps, contribution history, commit authorship concentration, pull requests, dependency inventories, package lockfiles, build pipelines, release artefacts, architecture diagrams, access-control exports and deployment ownership records. Interviews add context: why a supplier was used, how code moved into production, where prototypes came from, and which systems remain outside company control.
Reviewers should protect confidentiality. Source access should be scoped, time-limited and restricted to the evidence needed. Reports should summarise risk, evidence type and commercial implication without reproducing proprietary code unless there is a clear transaction need and permission.
The strongest finding is rarely "IP is bad". It is more precise: a named supplier contributed a material module, no assignment evidence has been provided, that module remains in production, and replacement would take meaningful engineering effort. That helps counsel, the investment committee and management decide what action is proportionate.
When do trade secrets and source code escrow matter?
Trade secrets matter when product value depends on know-how that is not patented, registered or visible in standard contracts. That can include algorithms, data-cleaning methods, pricing logic, security processes, customer implementation patterns, model training workflows or operational playbooks.
Diligence should test whether sensitive code and know-how are limited to appropriate people, leavers lose access promptly, suppliers are bound by confidentiality terms, and critical materials sit in company-controlled systems. Weak trade secret practice is often mundane: shared accounts, personal drives, unmanaged contractor laptops or missing offboarding records.
Source code escrow matters when customers, lenders, regulated buyers or strategic acquirers need continuity assurance. An escrow arrangement may require source code, build instructions, documentation or other materials to be deposited with a third party, usually for release under specified conditions. Technical diligence should test whether escrowed materials are current, buildable and aligned with production.
Escrow is not a substitute for ownership evidence. An out-of-date deposit, missing build secrets or undocumented deployment process may give the buyer less practical control than the contract suggests.
How should IP findings influence deal decisions?
Software IP findings should be translated into transaction choices. Some need legal clarification, technical remediation, warranties, disclosure schedules, completion conditions, holdbacks or post-close budget. The diligence report should make those routes explicit.
A useful readout separates findings by materiality and timing:
- 1Pre-close blockers: material code with no assignment evidence, critical third-party restrictions, missing source for acquired functionality, or unresolved ownership disputes.
- 2Pre-close clarifications: contractor agreements to retrieve, supplier access to document, open source obligations for counsel to interpret, or AI policy gaps to explain.
- 3Day-1 actions: transfer admin ownership, secure repositories, rotate credentials, collect build instructions, freeze supplier access and confirm critical contacts.
- 4First-100-days work: improve SBOM governance, clean up attribution, formalise AI usage, document trade secrets, update escrow materials and reduce supplier knowledge dependency.
FoundationState's work with Finex Advisory reflects the same principle we apply in transaction support: technical findings should become clear leadership priorities, not a long list of observations. Software IP due diligence is most valuable when it shows what risk is real, what evidence is missing and what protects value.
Get an independent view before software ownership assumptions become deal risk. Contact FoundationState to scope technical due diligence around code ownership, contractor evidence, open source obligations and IP provenance before your next investment or acquisition.
Frequently Asked Questions
How do you verify software IP ownership?
Verify software IP ownership by reconciling contracts with technical evidence. Review employment and contractor assignments, repository ownership, commit history, supplier access, dependency inventories, build artefacts and release records. Legal counsel decides the ownership position; technical diligence shows whether the factual record supports the claim that the company controls the software.
Does contractor-written code belong to the company?
Not automatically. Contractor-written code depends on the contract, assignment terms and surrounding facts, so legal counsel should review the agreement. Technical diligence helps by identifying what contractors actually built, whether their code remains in production, whether source was delivered and whether the company can operate the product without supplier control.
What is source code escrow and when is it needed?
Source code escrow is an arrangement where source code, build instructions and related materials are deposited with a third party for release under agreed conditions. It is most relevant when customers, lenders or acquirers need continuity assurance. Diligence should test whether the escrow deposit is current, complete and usable.
