Copilot Indemnity and LGPL Static Linking: What Is and Is Not Covered

Two risks that are easy to merge

Teams that use an AI coding assistant in a proprietary application often treat vendor indemnity as a general answer to open source licence exposure. That conflates two different questions.

The first is whether a third party could claim that code the assistant suggested infringes their copyright. Vendor indemnity is designed for this category. It applies to claims over suggested output and only when the customer meets the stated conditions.

The second is whether your organisation is meeting the licence terms of the third-party libraries it chose to include in the product. Here the code was not generated by the assistant. A developer or a build system pulled in an existing library, and the licence attaches to that library and to the act of distributing it. No claim over output is involved, so an indemnity written around output has little to say about it.

NIST's Generative AI Profile treats indemnity clauses as one contractual risk control among several, alongside provisions on content ownership, usage rights and provenance expectations. Indemnity is a supplement to compliance work, not a substitute for it.

How static linking affects LGPL compliance

The LGPL is a weak copyleft licence. It generally allows a proprietary application to use an LGPL library, but it places conditions on distributing that library as part of your product. The details differ between LGPL-2.1 and LGPL-3.0, and legal counsel should read the version that applies to each dependency.

Static linking matters because the library code becomes part of the executable you ship. The licence intent is that a recipient can still modify the library and run the modified version with your application. With dynamic linking, a user can swap a shared library file. With static linking, you must provide some other means for the recipient to relink, and the duties around notices and access to the library's source still apply.

These obligations are independent of how the rest of the application was written. Code a developer typed, code the assistant suggested and code copied from an internal repository all sit in the same build. The LGPL duty is triggered by linking and distributing the library, not by the authorship of your own code.

The practical consequence is that licence compliance for a distributed product belongs with the team that makes build and distribution decisions. It does not move to the assistant vendor.

Indemnity scope compared with LGPL duties

The table summarises how the two categories differ in practice. It is a working aid for architecture and legal discussions, not legal advice.

• What triggers it: Indemnity: a third-party claim over suggested output. LGPL: your decision to link and distribute a library.
• Whose code is involved: Indemnity: code the assistant generated. LGPL: existing third-party library code you included.
• Who holds the duty: Indemnity: the vendor responds to qualifying claims. LGPL: the distributor of the product, which is your organisation.
• Typical requirements: Indemnity: customer meets stated conditions. LGPL: relinking support, notices and source availability for the library.
• Primary evidence: Indemnity: configuration and suggestion records. LGPL: dependency inventory with licence and linking method per release.

Conditions that affect indemnity coverage

Indemnity is conditional. Coverage depends on the customer meeting the terms of the vendor's commitment, and those terms can reference controls such as the public code filter. If a control the terms rely on is disabled for a user group, you cannot assume the commitment applies to that group's output.

For enterprise architects this turns into a configuration management question. Record which Copilot settings, including the public code filter and code referencing, are enabled for each organisation or user group, and when they changed. Then have legal review compare those settings with the current indemnity terms. Terms and product behaviour can change, so this comparison should be repeated rather than done once.

Also decide who owns the exception path. If a team needs a setting that falls outside the conditions, that is a risk acceptance decision with a named owner, not a developer preference.

Keep the scope of any assumption narrow. Even when every condition is met, the commitment concerns claims over suggested output. It does not become a statement about the libraries in your dependency tree.

Where code provenance and policy enforcement fit

The controls above can be run manually, but they depend on records that are created at the time code is suggested. Reconstructing them later is slow and often incomplete.

Trussed provides code provenance, meaning the origin, licence and security context of code, and enforces policy in the execution path of coding assistants. Policy decisions are allow, redact or block, applied to individual interactions and tool calls, and enforced at runtime, not reviewed after the fact. Each enforcement action produces audit-ready evidence of what was permitted and under which policy. This is consistent with NIST's general point that assistant and agent behaviour can be constrained through scoped controls.

This does not change the legal boundary described in this guide. Provenance and enforcement evidence helps show what was suggested and under which policy. It does not discharge LGPL duties, and it does not determine whether a vendor's indemnity conditions are met. Those remain decisions for your legal and release teams.

Trussed supports self-managed deployment in the customer cloud, with configurable retention and data residency, which matters when evidence must stay inside your own boundary.