AI Code License Risk From Training-Data Memorization

Your AI coding assistant did not write that function from scratch. It predicted the next token, and the token before that, from a model trained on a large slice of public code. Most of the time the result is original enough that nobody thinks twice. Sometimes it is not — the model reproduces a chunk of training data closely enough that the code carries the license of wherever it came from, and nobody in the room knows it.

That gap has a name now: code provenance risk. It is not hypothetical. GitHub has published its own numbers on how often it happens with Copilot. A federal lawsuit over exactly this question has been in litigation since 2022 and is still unresolved. And the underlying mechanism — why some code gets memorized and reproduced while most doesn’t — has been measured directly by researchers, not guessed at.

Why Language Models Memorize Training Data At All

BrassCoders points builders to Carlini et al.’s 2022 ICLR paper, “Quantifying Memorization Across Neural Language Models,” as the foundational evidence that language models memorize exact snippets rather than only learning generalized patterns. The paper measured three separate drivers of memorization, each with a log-linear relationship to how much verbatim text a model can be made to emit: model capacity, how many times a given example appeared in the training set, and how many tokens of context the model is prompted with.

The duplication finding is the one that matters for license risk. A snippet that shows up once in an obscure repository is unlikely to be memorized. A snippet that shows up thousands of times across public GitHub — a common utility function, a standard boilerplate block, a widely-copied algorithm implementation — is exactly the kind of example a model is statistically most likely to have memorized. And code that gets duplicated that often across public repositories tends to carry a specific, traceable license, because that’s how it propagated in the first place.

This is not a claim that most AI-generated code is memorized. Carlini and coauthors were studying the general phenomenon, not code specifically, and the paper predates the current generation of code-focused models by several years. What it establishes is the mechanism: duplication in training data predicts reproduction in output. Any coding assistant trained on public repositories inherits this property to some degree.

How Often This Actually Happens, By GitHub’s Own Numbers

BrassCoders treats GitHub’s own published data as the most concrete evidence available, because it comes from the vendor measuring its own product rather than a third party estimating from outside. GitHub reports that matches to public code occur in under 1% of Copilot suggestions, using a duplication-detection filter that checks each suggestion’s surrounding 150 characters, roughly 65 lexemes, against an index of public code on GitHub.com. The check runs in a 10-20 millisecond budget so it doesn’t slow the editor down. When code referencing finds a match, GitHub surfaces the source repositories and their licenses so a developer can decide whether to keep the suggestion, add attribution, or discard it.

Under 1% sounds small. Read the fine print, though: GitHub’s own documentation notes matches are far more frequent in empty or nearly empty files than in files with existing surrounding code — the model has less context to steer it toward something novel, so it leans harder on what it has seen before. And a sub-1% per-suggestion rate is not a sub-1% per-year rate for a team. A developer using a coding assistant heavily can accept dozens of suggestions a day. Multiply that across a team, across a year, and a rare event stops being rare in absolute terms.

It’s worth being precise about what this number does and doesn’t tell you. It’s one vendor’s own filtered measurement of its own product’s suggestions, using its own detection threshold. It says nothing about assistants that don’t run an equivalent filter, and it says nothing about code generated in longer sessions where more context accumulates. Treat it as a floor on the true rate, not a ceiling.

The Legal Fight Nobody Has Resolved Yet

BrassCoders tracks Doe v. GitHub, Inc. as the clearest evidence that this question hasn’t been settled by anyone with the authority to settle it: a court, a regulator, or a standards body. Filed in the Northern District of California in November 2022 (No. 22-cv-06823-JST), the suit alleges that Copilot reproduces licensed open-source code without the attribution its licenses require, naming GitHub, Microsoft, and OpenAI as defendants. As of 2026 the case is still active, on appeal, unresolved.

According to case commentary published by Syracuse Law Review, the district court dismissed most of the original claims in 2024. The core dismissed claim rested on a DMCA provision protecting copyright management information; the court read that provision as requiring the AI’s output to be an identical copy of the original work rather than a modification of it, and found Copilot’s output didn’t meet that bar. The plaintiffs appealed to the Ninth Circuit later that year, arguing the identicality reading is wrong.

Don’t read either side of that ruling as a final answer. A dismissal on a narrow statutory reading isn’t a finding that AI-generated code is legally safe, any more than a pending appeal is evidence that it isn’t. What the case does establish, plainly, is that the underlying question — does license law’s traditional identical-copy standard even fit a system that produces near-verbatim, modified output — hasn’t been answered by any appellate court yet. Builders shipping AI-generated code into a product with real IP exposure are operating in that gap today, not after the case resolves.

What Provenance Scanning Actually Checks

BrassCoders points to ScanCode Toolkit, maintained by nexB and the AboutCode project, as a canonical example of what a purpose-built provenance scanner does differently from a security or quality scanner. It walks a codebase looking for license text, copyright notices, and package origin metadata, then emits the result as a structured inventory — JSON natively, or in the SPDX and CycloneDX formats that a software bill of materials (SBOM) uses. That’s a different question than “does this code have a SQL injection bug.” A security scanner reads code for dangerous patterns. A provenance scanner reads code for where it came from.

The Cybersecurity and Infrastructure Security Agency frames the compliance side of the same problem. CISA defines an SBOM as a nested inventory, a list of ingredients that make up a software component, and treats it as a building block for supply-chain risk management across government and industry. The agency, working with international partners, publishes minimum-elements guidance that sets the baseline fields a compliant SBOM has to record. For a team shipping into a regulated industry or a government contract, an SBOM built by actually scanning the shipped code is the artifact that turns “we think our AI-generated code is fine” into something an auditor can check.

Neither of these tools tells you whether a specific line of AI-generated code was memorized from a specific training example. Nobody can answer that with certainty from the output alone; the training data isn’t public for most commercial models. What provenance scanning gives you is the next best thing: a record of what license terms and copyright notices are detectable in what you actually shipped, checked systematically instead of by whichever engineer happened to notice.

Where BrassCoders Fits In This Picture

BrassCoders runs 12 scanners against your codebase — Bandit, Pylint, Pyre/Pysa, Semgrep, ast-grep, detect-secrets, plus custom detectors for secrets, privacy, AI-specific patterns, performance, content moderation, and JavaScript/TypeScript — and every one of them answers a question about what the code does, not where it came from. License and provenance scanning is a fundamentally different detection problem: it’s a matching problem against a corpus of known licensed text, not a pattern-matching problem against known-bad code shapes. BrassCoders doesn’t attempt it, and this post isn’t an argument that it secretly does.

The honest framing matters more than the feature gap. BrassCoders was built as a dumb-but-honest pattern reporter, deliberately: it reports what a deterministic scanner can verify, and leaves the context-dependent judgment calls to whatever AI assistant is reading its output. License provenance is exactly the kind of judgment call that doesn’t fit a pattern reporter — whether a 12-line utility function is common enough to be unprotectable, or specific enough to carry real license weight, requires comparing against a corpus BrassCoders was never built to hold. That’s ScanCode Toolkit’s job, or a commercial SBOM tool’s job, run as a separate pass alongside whatever security and quality scanning you already do.

What To Do About It Today

Start with the parts of this that are actually actionable now, before the litigation resolves and before any standards body issues a definitive rule. Run a provenance scanner like ScanCode Toolkit on your codebase periodically, the same way you’d run a dependency audit — it’s a separate pass, not a replacement for anything you already run. Treat any AI-generated block that looks unusually idiomatic or complete for a first draft as worth a second look; that’s often a sign the model had strong context to draw from, which correlates with memorization. Keep a record of what you find, even a simple one; an SBOM doesn’t need to be sophisticated to be useful, it needs to exist.

None of this eliminates the risk. It converts an unknown into something you can reason about, which is the most any team can do with a legal question that’s still being argued in front of a federal appeals court.