Amazon Q and Copilot Indemnity for GPL Code in a Shared Repository

Indemnity follows the vendor's output, not the repository

An AI coding assistant IP indemnification is a contractual commitment from a vendor about the output its own product produces. It is defined by that vendor's customer terms, tied to a particular product tier, and subject to conditions the customer must meet. It is not a property of the code or of the repository where the code ends up.

That has a direct consequence for teams running Amazon Q Developer and GitHub Copilot side by side. The Amazon Q Developer indemnity relates to Amazon Q Developer output under Amazon's terms. The GitHub Copilot indemnity relates to Copilot output under GitHub's terms. Neither vendor's commitment extends to suggestions produced by the other vendor's tool, and neither extends to code a developer wrote without an assistant.

The question "which indemnity applies to this GPL snippet?" therefore has no repository-level answer. It has a per-snippet answer, and the answer can be "one of them", "neither" or "cannot be determined". Legal teams should confirm the current terms, tiers and exclusions of each vendor directly, because they change and this guide does not restate them.

Conditions that typically determine eligibility

Vendor indemnities of this kind generally depend on a small set of conditions. Architects should expect to map each of them for each assistant.

The first is the product tier. Indemnity is commonly offered for specific commercial or business plans, so a developer using a personal or unlicensed account in the same repository may fall outside it. The second is required configuration. The brief for this guide notes that each vendor's indemnity has its own required settings, such as code-reference or public-code filters. If a filter must be enabled for coverage to apply, then the setting at the moment of generation matters, not the setting today.

The third is how the output was used. Indemnity language usually addresses unmodified output, and treats modified, combined or unknown-origin code differently or not at all. The fourth is exclusions, which can include cases where the customer ignored a warning, knew or should have known that the output infringed, or used the output outside the permitted scope.

GPL adds a separate dimension. GPL is a copyleft licence family, which attaches conditions to how code is reused and distributed. Whether a given snippet creates obligations is a legal analysis. An indemnity is a risk-transfer mechanism between the customer and the vendor. It does not change what the licence requires, so licence review and indemnity eligibility are two distinct workstreams that need the same underlying evidence.

Why mixed-assistant repositories create attribution gaps

Once a suggestion is accepted and committed, the repository usually keeps only the resulting code and the committer. Commit signing, code-owner approval and per-account accountability are standard repository integrity practices in NIST's Secure Software Development Framework. They establish who committed a change. They do not establish which assistant generated it, what the settings were, or whether the suggestion matched public code.

Three things widen the gap in a shared repository. Developers switch between assistants, sometimes within one file. Snippets are edited after acceptance, so the final text may differ from what either vendor produced. And code gets merged, copied between branches and refactored, which separates it from the session in which it was generated.

Human editing also complicates labelling. US Copyright Office guidance, as summarised by the Congressional Research Service, says that when humans use AI, what matters is the extent of human creative control over the work's expression. That concerns copyright authorship rather than licence terms or indemnity. Still, it shows why a simple "AI-authored" or "human-authored" tag does not hold for mixed code.

NIST's SSDF also treats AI-generated and human-written code the same for evaluation purposes. Review, vulnerability scanning and licence checks should apply to all code regardless of origin. That is necessary, but scanning after the fact finds licence matches without recovering the generation-time facts an indemnity claim would depend on.

Where runtime policy enforcement and code provenance fit

The evidence above has to be created when the interaction happens. A record reconstructed months later from developer recollection or from scattered tool settings is weak. This is why policy applied in the interaction path is more consistent than settings left to each developer's configuration. NIST also frames content provenance as something whose effectiveness should be measured and monitored across the lifecycle, rather than set up once.

Trussed enforces policy in the execution path across coding assistants, among other AI interactions. For individual interactions it can allow, redact, block, rate limit or escalate for human approval. For a mixed-assistant repository, that means an organisation can define the conditions under which assistant interactions proceed, and have those conditions enforced at runtime, not reviewed after the fact. Interactions that fall outside the defined conditions can be blocked or sent to a person for approval.

Trussed code provenance records the origin, licence and security context of code. Combined with enforcement, this produces audit-ready evidence that ties an interaction to an assistant, a policy decision and a licence context. Trussed is deployed self-managed in the customer cloud, with configurable retention and data residency, which matters because the retention period for generation-time evidence should be agreed with legal and security teams in advance.

The boundaries matter. Trussed does not create, expand or guarantee any vendor's indemnity, and it does not decide whether a vendor's terms are satisfied. Eligibility remains a question under each vendor's contract. What the evidence does is let legal, security and audit teams answer that question from records rather than assumptions.