How to Detect MPL-2.0 Snippets in Claude Code Output Before Merge

Why file-level copyleft and inline snippets are a scanning problem

The Mozilla Public License 2.0 is a file-level copyleft licence. Its obligations attach to the covered files rather than to an entire codebase, which is the main contrast with strong-copyleft licences that can reach whole programs, and with permissive licences that impose lighter conditions. For a proprietary codebase, the practical question is whether a file or a portion of one contains or derives from MPL-2.0 covered code. What the licence then requires, and whether a short fragment is protectable at all, are legal questions for counsel. This guide makes no legal conclusions and treats those judgements as inputs to the process.

The detection gap comes from how conventional tooling works. Software composition analysis generally reads manifests and lockfiles, so it reports packages a project declares. An AI coding assistant can emit a function or block that resembles covered code without any package being added. A developer can paste or commit that output with no record of where it came from or under what licence. The dependency list looks clean while the file contains material that was never declared.

Limits of snippet matching

Snippet matchers compare submitted code against indexed open-source corpora and report similarity. Treat every result as a lead, not a verdict. Three limits shape how you design the review step.

False negatives occur when code is altered, renamed or restructured enough to fall below a matcher's threshold, or when the source is not in the indexed corpus. False positives occur when short or idiomatic code matches many projects because there are only so many ways to write it. Very short fragments may fall below a tool's minimum match size, and whether a short fragment is copyrightable is a legal question that no tool answers.

An analogy from a different domain is useful. NIST evaluations of static analysis tools for security weaknesses found that most tools use heuristics and so may miss defects, that detection varies with code complexity, and that in one synthetic C test suite almost half of all weaknesses were not found by any of the eight tools evaluated. That work concerns security weaknesses, not licences, and does not measure licence matching. It does support a sound design principle: a heuristic detector is one control among several, and its silence is not proof of absence. Ask any vendor for documented minimum snippet size, match thresholds and error rates, and test the tool on your own AI-generated code.

Where runtime code provenance fits

Snippet matching works after code exists. Runtime code provenance works earlier, at generation. Trussed code provenance supplies the origin, licence and security context of code, and Trussed enforces policy in the execution path of coding assistants, so a team can allow, redact, block or escalate for human approval at the level of individual interactions and tool calls. In this workflow that supports the generation-time step: licence context is available while the developer is still deciding, and a policy can send borderline output to a human approver rather than leaving it to convention.

Each enforcement action produces audit-ready evidence, which covers the record-keeping described above for that step. This complements pull request and CI matching rather than replacing it. Provenance context and snippet matching answer different questions, and the review process should use both. The approach is useful to evaluate on its merits, and the workflow above holds with other tooling if your team prefers it.