IP Due Diligence a Technology Reviewer Can Actually Do

IP due diligence (IP DD) in M&A and investment deals is often treated as a black box handed entirely to lawyers and patent attorneys. In practice, however, there is a significant amount of preliminary fact-finding that a technology reviewer—someone with engineering expertise but no legal background—can carry out before formal legal review begins.

This guide covers what that preliminary work looks like in practice. The checks described here are about establishing technical facts, not drawing legal conclusions. Any legal interpretation of those facts belongs with qualified attorneys.

Where Preliminary IP Checks Fit

There are three distinct layers to IP assessment in a deal:

Layer	Who does it	Purpose
Tech DD	Engineers, technical advisors	Code quality, architecture, team capability
Preliminary IP checks (this guide)	Technology reviewer	Identify where IP risks may exist; scope the formal IP DD
Full IP DD	Lawyers, patent attorneys	Confirm legal ownership, FTO, contract review

The goal of the preliminary layer is not to reach legal conclusions. It is to answer: “Where should the lawyers focus?” Getting this triage right makes the formal IP DD faster and more targeted.

For context on how this fits within the broader technical review, see The Complete Framework for Technology Due Diligence.

Check 1: OSS License Inventory

OSS license exposure is the most accessible and most frequently found IP risk a technology reviewer can assess.

The two categories to know

Type	Examples	Key concern
Copyleft	GPL, LGPL, AGPL	May create source disclosure obligations depending on how libraries are integrated
Permissive	MIT, Apache 2.0, BSD	Generally safe for commercial use with attribution

Whether copyleft OSS creates an actual disclosure obligation in a specific product is a legal question. But identifying which copyleft licenses are present and where they appear in the codebase is a technology task.

How to do it

Review package.json, requirements.txt, go.mod, Cargo.toml, or equivalent dependency files
Run a license extraction command: npm licenses, pip-licenses, cargo license, etc.
For large dependency trees, request an SBOM (Software Bill of Materials) or a license scan report from tools like FOSSA, Snyk, or Dependabot
Flag for legal review: any GPL / LGPL / AGPL dependency and where it is integrated in the product

You are not evaluating whether a disclosure obligation exists—that is for lawyers. You are establishing which copyleft licenses are present and in what parts of the product.

Check 2: Code Provenance

Establishing where the code came from is foundational. A technology reviewer can gather this information without legal expertise.

Git history signals

Who are the primary committers on core product code? Are they still at the company?
Are there any commits where large volumes of code appeared at once? (Potential signal of code copied from elsewhere)
Do any commit messages reference “from,” “port,” “copy,” “migrate,” or similar language?

These are facts to document and pass to the legal team, not legal determinations.

External development

Ask management directly:

Was any core code written by contractors or freelancers?
If yes, is there a written agreement covering intellectual property ownership?

You are not evaluating the legal validity of those agreements—that belongs to lawyers. You are establishing whether agreements exist at all. “No written agreement with external contributors” is a fact that legal reviewers need to know.

Check 3: AI Model and Dataset Terms

For AI-driven products, the terms under which models and data are used are directly reviewable by a technology professional. This is one of the most actionable areas for a technical reviewer.

Foundation model API terms

For commercial APIs (OpenAI, Anthropic, Google, etc.), review the posted terms of service for:

Commercial use: Is the intended use permitted under the terms?
Prohibited uses: Are restrictions on building competing services, model distillation, or benchmarking relevant to this product?
Version-specific terms: Terms sometimes differ between model versions; confirm which version is in use and what terms apply

Open-source model licenses

For open-source models (LLaMA, Mistral, Gemma, etc.), each carries its own license—distinct from MIT, Apache 2.0, or BSD. Check the LICENSE file in the model’s repository or its Hugging Face page for:

Commercial use permissions
Restrictions on use in competing products
Requirements for derivative model distribution

Training data provenance

For proprietary datasets: who collected or created the data, and was there consent or licensing for the intended use?
For public datasets: confirm the dataset’s license explicitly allows commercial use
For scraped data: note that web scraping was used—legal evaluation of terms-of-service implications is for lawyers, but the fact that scraping was used is yours to establish

Check 4: Patent and Trademark Basics

Patent scope and validity analysis (including Freedom to Operate) requires a patent attorney. A technology reviewer’s role is limited to establishing basic facts.

What you can confirm

Whether the company holds any patent filings or registrations (a quick company name search on a public patent database confirms this)
Whether claimed patents are filed vs. registered—a meaningful distinction that is often glossed over in pitch materials
Whether the subject matter of patents corresponds to current product features at a high level

What you should not try to determine

Whether a patent’s claims are valid or enforceable
Whether the product infringes a third party’s patents (FTO analysis)
The commercial value of a patent portfolio

These require specialist legal expertise. Flag the basic facts you can confirm and refer everything else.

Check 5: Information Management Practices

Whether trade secrets are legally protected is a legal question. But whether sensitive technical information is being managed with basic controls is something a technology reviewer can observe.

Access controls: Is proprietary code in private repositories? Is access to sensitive technical documents limited to relevant personnel?
Offboarding: Are departed engineers’ accounts and access credentials revoked promptly?
Documentation: Is core technical know-how documented in systems the company owns—or does it live only in the heads of key individuals? (This also bears on key-person risk.)

Summarizing Findings for Legal Handoff

The output of a preliminary IP check is not a legal opinion—it is a structured fact sheet that legal reviewers can use to scope their work. A simple format:

Area	Finding	Escalate to legal?
OSS: copyleft licenses present	Yes / No / Needs review	Yes, if present
External code contributors	Yes / No; written agreements: Yes / No	Yes, if no written agreement
AI model terms reviewed	Any restrictions found	Yes, if restrictions apply
Patent filings present	Count; filed vs. registered	Yes, if product alignment unclear
Access controls in place	Adequate / Gaps noted	Yes, if significant gaps

Handing this structured summary to legal counsel means they can immediately focus on the areas of highest risk rather than starting from scratch.

For the full technical DD checklist including IP and licensing, see The Complete Checklist for Technology Due Diligence. The IP items in this guide map directly to the IP/licensing section of that checklist.

Tied Inc. provides technology due diligence support for VC firms and corporate M&A teams. See our investor services page for more.