Claude Code vs Amazon Q Developer: which flags public-code license matches

What public-code license matching means for a security team

AI coding assistants generate code that can resemble existing public code. When it does, the license on the original work may attach conditions to reuse. NIST SP 800-204D notes that open-source projects typically allow anyone to pull, replicate, modify and share source code with minimal or copyleft restrictions. A copyleft license in a proprietary codebase is a legal and engineering problem, and it is easier to resolve before the code is merged than after release.

Public-code license matching is the capability that compares generated output against known public code and tells the developer, or an administrator, what it found. Amazon Q Developer's reference tracking is the feature most often discussed under this heading. For Claude Code, buyers should ask whether an equivalent capability exists and how it behaves. The two tools differ in whether, how and where they surface matches, so a feature-name comparison is not enough. The questions below apply to both.

Side-by-side evaluation criteria

Use the same five criteria for each assistant and record the result as observed behavior, not as an assumption. A criterion that a pilot cannot demonstrate should be marked as a gap.

• Detection mechanism: For both tools: does the assistant compare output to public code at all, what is the stated method, and what are its stated limits?
• License information surfaced: For both tools: when a match occurs, is a license name, repository or URL returned, or only an indication of similarity?
• Where it is shown: For both tools: is the result visible in the IDE, the command line, a log, or nowhere a reviewer would see it?
• Administrator controls: For both tools: can administrators enable, disable or enforce match handling centrally, and can developers override the setting?
• Behavior on a match: For both tools: is the suggestion blocked, flagged with attribution, or delivered unchanged for the developer to judge?
• Evidence for auditors: For both tools: what exportable record shows that detection ran, on which interaction, and what was flagged?

Gaps that remain when you rely on built-in flagging alone

Even a well-designed built-in feature leaves questions that only your own policy can answer. Detection is bounded by what the tool compares against, so a missing flag is not proof that the code is original. A flag shown only to the developer in an editor is not a record an auditor can inspect. A setting that a developer can change locally is a preference, not a control.

Three gaps are worth testing explicitly. The first is scope: does the feature apply to every surface where the assistant writes code, including agentic and command-line workflows, or only to inline suggestions? The second is consequence: when a match is found, does anything stop the code from entering the repository, or does the decision rest with the person who may not recognize the license? The third is evidence: if counsel asks in a year which generated code was checked and what was found, can you produce that from the tool, or only from memory?

Policy should also settle which licenses are acceptable in generated code and who approves exceptions. Without that, a flag has no defined outcome.

Keep security findings separate from license findings

Both assistants appear in public vulnerability records, but these are security issues and say nothing about license detection. The NVD lists the Amazon Q Developer VS Code extension as affected in versions from 1.84.0 up to but excluding 1.85.0 (CVE-2025-8217). It lists Claude Code as affected in versions before 1.0.93 (CVE-2025-66032).

NVD also describes CVE-2025-55284: before Claude Code version 1.0.4, confirmation prompts could be bypassed to read a file and send its contents over the network without user confirmation, because of an overly broad allowlist of safe commands. For license compliance, the relevance is indirect. It shows that agentic assistants read files and make network calls, so controls on what they may do belong in the execution path as well as in the tool's own settings.

The practical consequence is version governance. Pin and track the version of each assistant in use, because a vulnerability or a change in match handling is tied to specific releases. Re-run your license-match pilot when versions change.

Covering the remaining gaps with runtime policy and code provenance

Whatever the pilot shows, some requirements will sit outside either assistant. Enforcement that depends on a developer noticing a notice is review after the fact. Enforcement in the execution path of the coding assistant is applied at runtime, as the code is produced or the tool call is made. NIST SP 800-218A frames the principle through least privilege: only authorized personnel, tools and services should have access to code and configuration.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants. For each interaction or tool call, policy can allow, redact, block, rate limit, or escalate for human approval. Code provenance adds the origin, licence and security context of code, which gives a reviewer something concrete to apply a license policy to.

Enforcement also produces audit-ready evidence. That evidence records what the assistant was allowed to do and what it did, which is the record an auditor asks for when built-in flagging offers only an in-editor notice. Trussed can be self-managed in the customer cloud, with configurable retention and data residency. It is deployed alongside the assistant you choose and does not decide which assistant that is.