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 a week earlier: 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 took thirteen field components on our own system, about 2,750 lines including tests. 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 they read the same wherever you find them. CTO on Demand's technical due diligence checklist, updated in July 2026, is representative: how much 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 spring 2026 update put the pass rate at roughly 55%, flat on the year. Bigger models did not do better.

Founders hear that and conclude the safe move is vagueness about how much AI they used. It is the worst available move: an assessor who cannot separate generated code from reviewed code has to treat all of it as unreviewed.

So we make it visible instead. On a healthcare platform we build, 58 of 117 commits carry an explicit AI co-author trailer, and an assessor can run that query themselves rather than take a founder's estimate for it. What comes back is a map rather than a score: which commits swept wide across the codebase, which were narrow and late, and whose name is against each. Decision records carry the same discipline in their authorship line, human for decisions and agent for drafting and review synthesis. Eleven of those sit in another platform's repository, several recording an objection that lost the argument.

The trail is an asset in the room, and it is worth being precise about why: it is not a quality claim. It says somebody can tell you which parts a machine swept, which parts a person sat with, and where the gates were. Version-control operations, dependency additions and auth-model changes stay with a human on our projects, written down as a rule rather than left as a habit, and we publish the six task types agents still get wrong on us. That describes a process somebody controls. "Our engineers use AI tools like everyone else" describes a shrug.

Provenance runs past code as well. The prompt assets and agent skills that produce the code are dependencies too, and on a coaching platform we build they sit in a lockfile recording each one's origin repository, path and content hash. It took an afternoon. Nobody has asked us for it yet.

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 our answer is contractual rather than clever. The specifications, the agent instruction files and the decision records live in the client's repository as deliverables, so they transfer with the code and nobody has to argue about whether a prompt is a work. The assignment covers whatever rights subsist in the output. Model provider terms get read 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 visible authorship trail 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.

Should we tell a buyer how much of our code was AI-written?

Yes, with evidence rather than an estimate. An assessor who cannot separate generated code from reviewed code has to assume the worst about all of it. A commit trail, a review gate and tests that cover the generated parts turn an unanswerable 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 instruction files in the same repository as the code.