The GPL Time Bomb: Why AI-Generated Code Is a Licensing Liability Nobody's Auditing For

The Lawsuit Quietly Redefining What 'Your Code' Means

In November 2022, a group of developers filed a class action against GitHub, Microsoft, and OpenAI, arguing that Copilot was trained on public repositories and reproduces licensed open-source code without honoring the attribution and copyleft terms those licenses require. Most of the original claims — unjust enrichment, negligence, unfair competition — were dismissed on preemption grounds by mid-2024. But two claims survived, and they're the ones that matter: a breach of contract claim arguing that open-source licenses are enforceable contracts Copilot violates by stripping license terms from its output, and a DMCA Section 1202(b) claim over the removal of copyright management information.

That DMCA question is now on interlocutory appeal at the Ninth Circuit, with oral argument expected in early 2026. The legal question is narrow but consequential: does Section 1202(b) require an AI model's output to be functionally identical to the copyrighted source, or can it apply to output that is merely substantially similar? If the Ninth Circuit lands on 'substantially similar,' the bar for what counts as infringing AI-generated code drops sharply — and a great deal of code sitting in production today, generated over the last three years without anyone checking, becomes retroactively exposed.

This is not an isolated case. By mid-2026, more than 70 AI copyright lawsuits were active or recently resolved across US and international courts, with cumulative claimed damages exceeding $50 billion. Most of the headlines focus on image and text generation, but the code-specific cases carry a distinct risk profile: unlike a generated image, generated code gets compiled, shipped, and sold as part of a product — which means the exposure isn't reputational, it's a live intellectual property liability sitting inside your revenue-generating software.

For engineering leaders, the practical takeaway isn't 'wait for the ruling.' It's that the legal ambiguity itself is the risk. Litigation this unsettled means insurers, acquirers, and enterprise customers doing due diligence are already asking the question your codebase may not have an answer to: can you show where your code came from?

What License Contamination Actually Looks Like in a Commit

Large language models are trained on enormous volumes of public code, a meaningful share of it released under copyleft licenses — GPL, LGPL, AGPL — that require derivative works to be released under the same terms. When a model reproduces a close variant of that training data in its output, the copyleft obligation travels with it. The difference from traditional open-source use is that nobody typed `npm install` or added a line to a manifest file. The code simply appears, indistinguishable in formatting and style from anything else the model generates, with no signal that it came from anywhere at all.

This is exactly what happened at a Fortune 500 company that used GitHub Copilot to scaffold a payments module. Three months after the code shipped, the company's legal team — running an unrelated audit — found roughly 40 lines that were a near-verbatim reproduction of GPL-licensed code. Untangling the dependency, verifying what else in the module might share the same provenance, and rewriting the affected logic cost a six-figure sum and delayed the release the module was built for. Nobody on the engineering team had done anything they'd have flagged as risky. The code passed review because it looked like ordinary, competent code — which, per the training data it came from, it was.

The pattern generalizes beyond payments logic. Common algorithms, boilerplate error handling, well-known data structure implementations, and widely-copied utility functions are exactly the code most likely to appear verbatim or near-verbatim across many training repositories — which makes them both the code an LLM reproduces most confidently and the code least likely to get a second look in review, because it looks the most unremarkable.

The Numbers Say This Is Already Widespread, Not Hypothetical

Black Duck's 2026 Open Source Security and Risk Analysis report — an annual audit now in its eleventh year, covering 947 commercial codebases across 17 industries — found license conflicts in roughly two-thirds of the codebases scanned. That is the highest rate the report has recorded in its history, and the timeline lines up precisely with the period in which AI coding assistants went from novelty to default tooling across most professional engineering teams.

The governance gap behind that number is the more alarming part. Research published under the DevLicOps framework — a 2025 academic study specifically examining AI coding assistant licensing risk — found that only 24% of organizations run comprehensive IP, license, security, and quality evaluation specifically on AI-generated code. The other 76% are, in effect, running their traditional open-source compliance process — the one built around scanning dependency manifests — against a code generation method that doesn't touch a manifest at all. The scanner is checking the front door while the exposure is coming in through a window nobody built a lock for.

Separate industry estimates put the share of AI-generated code containing some form of licensing irregularity at roughly 35% — a number that should be read less as a precise figure and more as directional confirmation: this is not a tail risk affecting a handful of unlucky teams. It is a structural byproduct of how these models were trained, showing up at meaningful scale in production codebases right now, in most cases completely undetected because the detection tooling most companies rely on wasn't built for this failure mode.

Why This Slips Past Tooling That Was Working Fine Until Now

Most engineering organizations of any size already have a mature open-source compliance process, and it has worked reasonably well for two decades: a developer adds a dependency, a software composition analysis (SCA) tool like FOSSA, Black Duck, or Mend.io scans the manifest file against the full dependency tree, flags anything with a restrictive license, and legal reviews it before merge. That process assumes the point of entry for third-party code is a declared, visible dependency. It is a good assumption for imported packages. It is the wrong assumption for AI-generated code.

When a coding assistant emits a function inline, there is no manifest entry to scan, no package name to check against a license database, and no dependency tree node for the SCA tool to walk. The code is indistinguishable, at the tooling layer, from anything a human engineer typed by hand. A handful of newer tools are beginning to address this specifically — building 'AI-code fingerprinting' capability that compares generated snippets against known open-source corpora, similar in spirit to academic plagiarism detection — but the efficacy is inconsistent, particularly once code has been refactored, renamed, or lightly paraphrased by a second AI pass, which is now a common part of many teams' workflows.

The practical effect is a governance blind spot that most engineering leaders haven't mapped yet: your existing compliance stack, the one your legal and security teams already trust, was not designed to catch this problem, and telling them it's 'handled' because you run an SCA scanner in CI is not accurate. It's handled for the 2015 threat model. It is not handled for the 2026 one.

Vibe Coding and Regulation Are Compounding the Exposure, Not Reducing It

Two trends are making this worse at the same time, rather than either one resolving it. The first is the sheer volume of AI-generated code now shipping with minimal human review — the 'vibe coding' pattern this publication has covered extensively elsewhere. Every percentage point increase in AI-authored, lightly-reviewed code is a percentage point increase in code whose provenance nobody checked, because the entire premise of vibe coding is that checking is the thing being skipped.

The second is regulatory. The EU's revised Product Liability Directive expands liability exposure for software defects, and legal commentary through 2026 has increasingly read AI-generated code with undisclosed licensing contamination as falling within that expanded scope — a defect a reasonable engineering process should have caught. Combined with the Ninth Circuit's pending 'substantially similar' question, the direction of travel is unambiguous: the legal standard for what counts as a problem is getting stricter at the same time as the volume of exposed code is getting larger.

Put those two trends together and the risk isn't static — it's compounding. A codebase with unaudited AI-generated code carries more latent exposure today than it did a year ago, purely because more of it has been written, and it will carry more again next year, purely because the legal bar for what counts as infringement is trending toward being easier to clear, not harder.

What Good Governance Actually Looks Like

The organizations handling this well are not avoiding AI coding tools — they're building a governance layer that treats AI-generated code with the same rigor as any third-party dependency, because that is functionally what it is. The pattern has four consistent pieces. First, provenance tracking: knowing which code in your repository was AI-generated, by which tool, and when — the same visibility principle that matters for AI technical debt generally, applied specifically to license risk here.

Second, license-aware scanning that goes beyond manifest checks — deploying the newer generation of SCA tooling that includes AI-code similarity detection against known open-source corpora, run in CI rather than as a periodic audit, so contamination is caught at commit time rather than three months later during an unrelated legal review. Third, a written AI code policy that sets an explicit similarity threshold above which code requires human rewrite or legal sign-off before merge, rather than leaving the judgment call to whichever engineer happens to be reviewing the PR that day.

Fourth — and most often skipped — contractual protection with every external development partner: explicit warranty of code originality, audit rights over AI tool usage in delivery, and indemnification language that specifically names license contamination rather than relying on generic professional liability coverage that may not cover it. Most outsourcing and staff-augmentation contracts signed before 2024 say nothing about this at all, because the risk didn't meaningfully exist yet when they were drafted.

The Vendor Due Diligence Question Almost Nobody Is Asking

If license contamination risk is largely invisible inside your own engineering team, it compounds when the code is coming from an external partner whose AI tooling practices you can't see into. The standard outsourcing due diligence questions — technical skills, delivery track record, security posture — don't touch this at all, and most vendors have never been asked about it, which means most vendors don't have a good answer.

The questions worth adding are specific: does the partner run license-aware scanning on AI-generated commits, or only traditional dependency scanning? Do they carry indemnification that names IP and license contamination explicitly, rather than generic errors-and-omissions coverage? Do their senior engineers review AI output specifically for 'this looks like it could be copied' patterns, or only for functional correctness? And — the question that separates a genuine engineering partner from a volume-oriented one — do they even know which of their delivered code was AI-generated in the first place?

This is where the accountability structure of a partner matters as much as their technical skill. A marketplace-sourced, anonymously-subcontracted engineer has no institutional stake in whether the code they shipped six months ago turns out to carry a licensing problem — by the time it surfaces, they may not even be on the project anymore. A senior engineer who is a named, direct employee of a firm with an ongoing relationship and reputation at stake has every incentive to flag it, document it, and fix it properly the first time. At StepTo, treating AI-generated code with the same review rigor and provenance discipline as any other third-party dependency isn't an add-on service — it's what senior-led delivery has always meant, applied to a risk that didn't exist a few years ago.

A Practical 90-Day Checklist for Engineering Leaders

This doesn't require a moratorium on AI coding tools, and treating it as an argument against AI adoption misreads the problem entirely — the fix is governance, not retreat. Start with an audit: run a modern SCA tool with AI-code similarity detection against your current production codebase, focused first on any module built heavily with AI assistance since 2023, since that's where the highest concentration of unreviewed exposure is likely to sit.

In parallel, write down an actual AI code policy — even a one-page version is better than the silence most organizations currently have — that states your organization's tolerance for AI-generated code similarity to known open-source sources, and what happens when a scan flags something above that threshold. Bring it to your next contract renewal with any outsourcing or staff-augmentation partner and add explicit license-contamination indemnification language; if the vendor pushes back or seems unfamiliar with the concept, that reaction is itself useful diligence information.

Finally, put the Ninth Circuit's pending ruling on your radar as a trigger event, not a footnote. When it lands — expected sometime after the early 2026 oral argument — it will either narrow or widen the legal exposure of every codebase with AI-generated code in it, retroactively. Organizations that have already done the audit and have provenance data on hand will be able to answer the question quickly. Organizations that haven't will be doing the audit under legal deadline pressure instead of on their own schedule.