GitHub Copilot Indemnity and the Duplicate Detection Filter: What It Means for GPL Code

Why the question spans three layers

Most organisations assess GitHub Copilot indemnity in pieces. Procurement and legal read the contract. Platform administrators configure the product. Developers decide, suggestion by suggestion, what enters the codebase. Each group can be diligent and the organisation can still be unable to answer a simple question: if GPL-origin code was accepted while the duplicate detection filter was off, who turned it off, what was suggested, and what happened next?

This guide separates the layers. The first is the contractual indemnity: what the vendor promises, on what conditions, and with what exclusions. The second is product configuration: the public code matching setting, and whether it is fixed centrally or left to individual developers. The third is runtime enforcement and evidence: the controls that act on code as it is suggested and merged, and the records that survive for audit.

The layers do different jobs. The contract allocates liability after a dispute. Configuration reduces the chance that matching public code is suggested at all. Runtime controls and evidence show what actually occurred. A gap in any one of them weakens the other two.

How indemnity conditions relate to the filter setting

Indemnity clauses commonly attach conditions to coverage. These can include using the product as documented, keeping specified settings enabled, and notifying the vendor of a claim. Whether a given Copilot plan's indemnity is conditional on the public code matching filter being enabled is a question of contract wording. The answer should come from the exact clause in the terms that apply to your agreement, read as of a specific date, not from a summary or a blog post.

This guide is not legal advice, and interpretation of those terms requires legal review. Two points hold regardless of the answer.

First, if the wording does tie coverage to the filter, then the setting is no longer only an engineering preference. It becomes a condition that the organisation must be able to show it met. A developer disabling the filter locally, or an administrator changing it without approval, could then affect the contractual position without anyone noticing.

Second, NIST's Generative AI Profile (AI 600-1) lists GAI-specific indemnity clauses as one contractual risk control among others, and it warns that non-standard vendor terms can amplify or defer liability in unexpected ways. Reading conditions, exclusions and configuration prerequisites directly is the proportionate response. A contract-only posture is a thin basis for licence-risk handling.

What indemnity addresses and what it leaves open for GPL code

An indemnity is a remedy that operates after a claim arises. It may shift some legal cost or liability to the vendor, subject to its terms. It does not inspect a suggestion, block it, or change the licence attached to code that has already been accepted.

That distinction matters for copyleft licences such as the GPL. If code derived from GPL-licensed work is merged into a proprietary repository, the repository holds that code until someone finds and removes it. The organisation may then face remediation work, release delays, or a review of what shipped and to whom. Indemnity may speak to some legal consequences, but it does not remove the code, and it does not tell you which commits are affected. How any given exclusion or limit treats copyleft-origin output is a point for legal counsel.

The filter and the contract also answer different questions. The filter is a preventive setting that affects what the assistant offers. The indemnity is a contractual fallback. Turning the filter off increases the share of suggestions you must evaluate yourself, and it may change contractual standing, depending on the wording. Neither mechanism produces a record showing which accepted code, if any, carried licence risk.

Defining an internal policy for the filter setting

A policy for the public code matching setting should be short, testable and owned. It needs to work whichever way the contract wording is read. The following decisions give it structure.

• Default state: State whether the filter must be on. Where the contractual position is unresolved, a default of on is the conservative choice.
• Who may change it: Restrict changes to named administrator roles and require that the setting be fixed centrally rather than left to individual developers wherever your plan allows.
• Exception process: Define who approves an exception, for which repositories or teams, for how long, and what compensating review applies while it is active.
• Change records: Capture who changed the setting, when, and the previous and new values, as part of configuration management and account management baselines.
• Instruction files: Assistants follow repository instruction files such as .github/copilot-instructions.md, so place them under change control. Do not treat them as a substitute for the filter setting.
• Review cadence: Re-read the indemnity wording and the setting's documented behaviour on a schedule and whenever terms or plans change.

Where code provenance and runtime enforcement fit

The indemnity and the filter setting each leave a gap. The contract does not prevent copyleft code from entering a repository, and a setting does not prove what was suggested or accepted. Closing that gap needs controls that act on the code itself, in the path where the assistant operates.

Trussed addresses this layer. It provides code provenance, meaning the origin, licence and security context of code, and it enforces policy in the execution path for coding assistants. Policy can allow, redact, block, rate limit or escalate an interaction for human approval, at the level of individual interactions and tool calls. Enforcement is applied at runtime, not reviewed after the fact.

The same enforcement generates audit-ready evidence on a continuous basis. For a regulated enterprise, that evidence is what turns a licence-risk policy into something a regulator, auditor or legal team can examine. Trussed does not replace the contractual review or the vendor-side settings described above. It supplies the runtime control and evidence that those layers cannot provide on their own.