Open-source licences, AI-written code, and your IP story

Technical diligence runs three IP questions, roughly in this order. What do your dependencies oblige you to do? Where did the code come from, and who took responsibility for it? And can you trace ownership from every person and every tool that touched the repository to the company being bought? The first two are usually fixable in weeks. The third, left late, is the one that moves a deal.

The law here has not moved. What changed is that the second question grew teeth. DORA's 2025 State of AI-assisted Software Development found 90% of respondents using AI at work, a median of two hours a day, and 30% reporting little or no trust in the code it produces. An assessor reading that report and then reading your repository has an obvious follow-up, and "we use Copilot" does not answer it. IP sits alongside the other findings in the seven red flags that stop a funding round, and it is the one founders most often assume belongs to someone else.

Provenance is the record of where a piece of code came from and who took responsibility for it. Licences are a subset of that record. So is the commit history, and so is the contract with the contractor who left in 2023.

The three layers, and what each one is testing

None of these questions is really about code. They ask whether the company can sell what it says it owns, on the terms it claims. An assessor who finds a copyleft package in a shipped binary is not admiring your dependency choices. They are working out whether a warranty in the purchase agreement is about to be untrue.

The layers also fail on different timescales, which matters when you are deciding what to fix first. Licence problems are found by a script in minutes and take weeks to remediate. Provenance is cheap to fix going forward and impossible to fix backwards, because you cannot retrofit a review that never happened. An ownership gap does nothing at all for years, and then needs a contractor from 2023 to answer an email.

Layer one: the licence inventory nobody has read

Every package manager can produce a licence report from the lockfile. Few teams have run one, and most of those ran it once, before eighteen months of dependency drift.

Four things go wrong, and only copyleft in shipped code is famous. Its obligation attaches to distribution, and what counts as distribution is precisely the argument you do not want to be having during an exclusivity period. Network-facing copyleft catches hosted products by surprise, because "we never ship a binary, so we never distribute" is not a reliable intuition there.

Second, and far more common, the transitive dependency nobody vetted. Your team approved the package it added. Nobody approved the thirty that came with it. A licence report reads the whole tree, and the finding is usually four levels down in something that arrived as a build-time convenience.

Third is the one that produces the worst afternoon: package metadata that disagrees with the licence file. The manifest says MIT, the LICENSE file in the repository says something else, and they have been out of step since a relicensing half the ecosystem missed. Your tooling reads the manifest. An assessor's tooling might read both.

Last, vendored code with no provenance at all. A pattern set copied in, a snippet from a blog post, a file somebody pasted in 2022. We vendor an MIT-licensed pattern set on one platform quite deliberately, and the only reason that sentence is safe to say out loud is that the decision sits in writing next to the code.

What a finding costs you is decided by coupling rather than by the licence. On a field operations platform in a regulated compliance industry, we adopted a mature open-source form engine on a Monday and pulled it out on the Tuesday, for design reasons rather than legal ones. The reversal was survivable because of a boundary drawn at the start: the schema was stored opaquely and the thing was treated as a library rather than a platform, so nothing on the server knew it existed. Replacing it meant building our own field components on the platform's existing component system, tests included. Where we have held that boundary, removing a dependency has cost days. Where a library's own model has spread into the product's, we would not want to be pricing that work in the middle of a diligence period.

Layer two: where the code came from, and who reviewed it

The AI questions arrived on diligence lists during 2026 and read much the same everywhere. CTO on Demand's technical due diligence checklist, updated in July 2026, is representative: what share of the codebase was AI-written, was it reviewed by someone who understands it, and what test coverage exists on the generated code specifically. The worry underneath is legitimate. Veracode's 2025 GenAI Code Security Report tested more than 100 models across 80 coding tasks and found 45% of cases producing code with an OWASP Top 10 weakness. Its 2026 report put the average security pass rate at 56%, barely moved in four years of testing, and model size made little difference.

Founders hear that and conclude the safe move is vagueness about their use of AI. It is the worst available move: an assessor who cannot tell how the code was reviewed will treat all of it as unreviewed, which is also how an AI-built app audit reads a codebase with no review record.

The answer that works shows every change was reviewed, with documents behind it. Which AI tools are approved, and do their account terms bar training on your code? Who reviews each change before it merges, and where is that recorded? What do the specification and decision records say about why a change was made, and what does the test history prove? When the share question comes, the strong answer is that every change went through the same review whatever produced it, with the record to show it. That makes the share a detail rather than a risk.

A review history is an asset, but it is not a quality claim. It shows that somebody can say where the gates were and who stood at each one. A written rule for what a tool may not do without a person's sign-off, such as adding a dependency or touching production, describes a process somebody controls. "Everyone uses AI tools now" describes a shrug. Be ready to name which of the known failure modes of coding agents your review is built to catch.

Provenance runs past code as well. The reusable assets that shape generated code, shared prompts and instruction files among them, are dependencies too, so check whether each one is pinned to a version and recorded with where it came from, the same way a package is.

Layer three: the ownership chain, and where it breaks

The IP story is the layer with no engineering fix, and in most seed-stage companies nobody has looked at it since incorporation.

Assignment on payment is the standard shape for agency work, and it is worth reading your own contract to check it says so. Ours does, and the repositories live in the client's own organisation from the first commit rather than moving across at the end, which removes an entire category of argument about what happens if a relationship ends badly. Handover becomes a permissions change rather than a migration.

Contractors are where the chain usually breaks. An employment contract in the UK typically deals with work created in the course of employment. A contractor's does not, unless somebody wrote the clause. The diligence question is not "did you use contractors", it is "show me the signed assignment for each of them", and the honest answer for a lot of seed-stage companies is a Slack message from 2023 and a hopeful expression.

Then the newer question: who owns the prompts and the output. We are not lawyers and this is not settled ground, so the sensible answer is contractual rather than clever. Treat the specifications, the written conventions and the decision records as deliverables that live in the client's repository, so they transfer with the code and nobody has to argue about whether a prompt is a work. Have the assignment cover whatever rights subsist in the output. Read the model provider's terms before a tool is approved rather than after, which is one of the more mundane reasons to keep an AI use policy sized for a small company.

One check takes ten minutes: who owns the account that owns the repository. A chain of assignments can be immaculate on paper and still terminate in somebody's personal account.

Three questions, one piece of work

Three layers, and nothing like three workstreams, because the artefacts overlap almost completely.

A licence inventory, a written rule about what gets in, decision records that say why, a review history and a signed assignment for every contributor. That set answers the IP questions. It also answers most of what happens when the engineer who knows everything leaves, which ends more diligence calls than bad code does, because both questions are really asking whether the knowledge in this company exists anywhere outside one person's head.

Which is the argument for doing it in a quiet month rather than week two of a process. A licence report takes an afternoon. Chasing a contractor from 2023 for a signature takes however long it takes, and no amount of urgency shortens that.

Common questions

Does using AI to write code create a licence problem?

Not directly. Obligations in your dependency tree come from packages somebody installed, whoever typed the command. The AI-specific worry is narrower: generated code reproducing a distinctive chunk of something licensed. That is why the vendored and pasted-in parts of a repository deserve more attention than the generated ones.

Which licences do investors treat as red flags?

The name of the licence matters less than whether its obligation conflicts with what you promise customers. Copyleft terms reaching your shipped or hosted product are the ones that get escalated, because the remedy can be publishing source. Permissive licences rarely trouble anyone, provided the attribution obligations are met.

How should we answer a buyer's questions about AI-written code?

Show that every change was reviewed, and keep the records that prove it. An assessor who cannot tell reviewed code from unreviewed code has to assume the worst about all of it, and a record turns an open question into a short one.

How long does a licence sweep take?

Generating the inventory is an afternoon on a codebase with clean lockfiles. The work is what follows: deciding which obligations you accept, replacing what you will not, and writing the rule that keeps the next one out. Budget a week, and do it before an assessor does.

Who owns the output of an AI coding tool?

Contracts settle it in practice, whatever the underlying legal position turns out to be. Check that your assignment language covers work produced with tools and not only work authored by people, and that your model provider's terms make no claim on output. Keep the specifications and written conventions in the same repository as the code.