AI Coding Assistant Indemnity and SSPL: What GitHub Copilot, Cursor, Claude Code and Amazon Q Cover

Indemnity is a remedy, not a control

Vendor IP indemnities for GitHub Copilot, Cursor, Claude Code and Amazon Q Developer are contractual commitments. They describe who may bear certain costs if a third party brings a covered claim. They do not inspect a suggestion, identify its origin or stop it from being accepted into a repository.

This distinction matters for regulated adoption. A risk register that lists indemnity as a mitigation for licence contamination is relying on a financial and legal backstop. It is not relying on prevention. The code is already in the codebase when the indemnity becomes relevant.

Indemnities are also typically conditional. Common conditions include a specific product tier, enabled duplicate-detection or code-reference filters, and output used without modification. Each condition is something the customer must be able to show it met, and a lapse in any of them can narrow or remove coverage.

Why SSPL is a distinct question

The Server Side Public License is a source-available licence with network-service copyleft obligations, and the OSI does not recognise it as open source. Its Section 13 addresses offering software as a service. The obligations therefore tend to arise when code is deployed as a network-delivered service, not only when it is copied.

That sets SSPL apart from the claims indemnities are usually described as covering, such as copyright infringement arising from generated output. Whether a licence-condition obligation, a contract-based claim or a source-disclosure demand falls inside a vendor's covered claim types is a question for the written terms and for qualified legal review. This page does not offer legal conclusions.

There is a second gap. Terms and tooling that refer to open-source licences may not extend to source-available ones. A reader should not infer coverage from the word "open source" appearing in a vendor document, and should look for SSPL or source-available licences named explicitly in scope or in exclusions.

Comparison dimensions for each of the four vendors

Apply the same six questions to GitHub Copilot, Cursor, Claude Code and Amazon Q Developer, and record the answer, the document version and the retrieval date for each. Indemnity terms are conditional and can change, so the date matters. Separate what the terms state from what they leave silent. Silence on SSPL is a finding in its own right, and it leaves the risk with the customer.

• Covered plans and tiers: Is coverage limited to business or enterprise tiers? Do individual or free tiers sit outside it? Confirm that the tier you procure is the covered one.
• Required configuration: Must duplicate-detection or code-reference filters be enabled? Who controls the setting: the vendor, an administrator or each developer?
• Covered claim types: Is coverage limited to copyright infringement from output? Are licence-breach, contract-based and source-disclosure claims covered, excluded or not addressed?
• Exclusions and voiding conditions: Do modified output, disabled filters, known-infringement use or combination with other material remove coverage? What notice and cooperation duties apply?
• Licence-specific language: Do the terms mention open-source or source-available licences, or SSPL by name, in scope or exclusions? Or do they stay silent?
• Evidence of compliance: What records show the tier, the filter state and the unmodified status of output at the time of generation?

What detection and filtering can and cannot tell you

Assistants may offer mechanisms that flag suggestions matching public code, sometimes with licence attribution or a reference to the matched repository. These are useful, but each has limits that should be documented per vendor before coverage is relied on.

A matching filter finds what resembles code it can compare against. It may not detect code that is derived or reworked, and it may not classify a licence it does not recognise as a restricted category. Licence attribution depends on the licence being identified correctly, which is harder for source-available licences than for widely catalogued open-source ones. A filter can also be switched off, and an indemnity condition tied to that filter then depends on a setting someone can change.

Ask each vendor three things. What is matched against? How is the licence determined? What is the documented behaviour for source-available licences such as SSPL? Where the answer is not documented, assume the filter gives no assurance about SSPL.

Runtime enforcement as the complementary control

Because indemnity does not prevent SSPL-licensed code from entering a codebase, regulated enterprises need a control that acts before code is accepted. That means knowing the origin and licence context of code when it is generated, and applying policy to it then. Reviewing it afterward is too late.

Trussed enforces policy in the execution path across coding assistants, models, agents and tools. Its policy can allow, redact or block an interaction. Code provenance supplies the origin, licence and security context of code, so a licence policy can be enforced at runtime, not reviewed after the fact. Each enforcement decision produces audit-ready evidence, mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act and NIST. That evidence helps show an auditor, and potentially a vendor, which controls were active when code was generated.

The NIST secure software development community profile for generative AI is a reasonable reference for the wider development practices around this control. Runtime enforcement does not replace indemnity or legal review. It reduces how much residual SSPL risk reaches the codebase, and it documents what was allowed and what was not.