Anthropic Indemnity and LGPL Vendored Dependencies: What the Contract Covers and What It Leaves with You
An AI vendor's IP indemnity is a contractual remedy for defined claims about generated output. It does not perform the obligations that arise when your team modifies a vendored LGPL library, such as making the modified source available, preserving the ability to relink or replace the library, and keeping license notices intact. Whether any indemnity reaches an AI-assisted edit to LGPL code depends on your signed terms, so confirm them with counsel and place the compliance controls in the development workflow.
Workflow controls that reduce exposure
- 1
1. Identify vendored LGPL paths
Inventory vendored directories and files, record each library's license and version, and mark the paths as restricted in a form that tooling can read.
- 2
2. Set a policy for AI-assisted edits
Decide per path whether edits are allowed, redacted, blocked, or escalated for human approval. Blocking or escalation is a sensible default for LGPL paths.
- 3
3. Enforce at the point of the edit
Apply the policy when the assistant proposes or makes a change, not in a later review. After-the-fact review tends to find problems once code has moved on.
- 4
4. Check notices and linking impact
For approved edits, confirm license headers and notices are intact and that the change does not alter how the library is linked or packaged.
- 5
5. Route modified source to release
Add modified vendored libraries to the release checklist so the source obligation is met when the product is distributed.
- 6
6. Retain evidence
Keep records of the origin of the code, its license, the policy decision, any approver, and the resulting change.
Contract terms to check before relying on an indemnity
- Covered services and plans: whether the coding assistant you actually use, under your specific agreement and plan, is within the indemnity.
- Output definition: whether an edit, patch or diff to an existing file counts as output, or whether output means only newly generated material.
- Exclusions for modified or combined code: whether coverage falls away when output is altered by your team or combined with other materials, such as an existing library.
- Use that breaches third-party terms: whether using output in a way that fails a license condition is excluded.
- Conditions of coverage: any required settings, safeguards or usage practices that must be in place for the indemnity to apply.
- Notice and cooperation duties: how quickly you must notify the vendor of a claim, and what control over defence and settlement you give up.
Indemnity is a narrow remedy, not a compliance control
Enterprise teams often ask whether a vendor's IP indemnity settles open source license risk for AI-assisted code. It helps to start from what an indemnity is. It is a promise, under stated conditions, to respond to certain third-party claims. It does not change what the code is, where it came from, or what license obligations attach to it.
NIST's draft Generative AI Profile (AI 600-1 initial public draft) recommends updating third-party contracts, service agreements and warranties to address generative AI risks, and notes that these may include GAI-specific indemnity clauses. It frames indemnity as one risk control among several, alongside dispute resolution mechanisms and other controls. That framing is the right one for this scenario: the contract is one layer, and it does not replace the others.
It is also worth keeping risk categories distinct. NIST's final profile describes intellectual property risk in terms of copyrighted works and fair use. LGPL compliance is a different question. It concerns the conditions of a license that your organisation accepts when it uses and modifies a library, and it is not resolved by copyright analysis alone.
How LGPL obligations attach to a modified vendored library
Vendoring means a third-party library's source is copied into your repository and maintained there. Once your team, or an AI assistant acting for it, edits those files, you hold a modified version of an LGPL-licensed library. The obligations that follow come from the license and from how you distribute the product, not from who or what typed the change.
In general terms, LGPL obligations for a modified library include making the source of the modified library available to recipients, preserving the recipient's ability to relink with or replace the library, and keeping copyright and license notices intact. How these apply depends on the license version, on whether the library is statically linked, dynamically linked or bundled into a larger artifact, and on whether and how the product is distributed. Counsel should map these points to each vendored library and to your distribution model.
The key point for this guide is that these duties are performed by your organisation. An indemnity may bear on a claim after something goes wrong. It does not publish modified source, keep a library replaceable, or restore a stripped notice.
Where the gap leaves residual risk
The table separates what an indemnity might plausibly address, subject to its terms and exclusions, from what remains with the customer. It is a framing aid, not a legal conclusion.
- Third-party claim about generated output: An indemnity may respond, if the output is in scope and no exclusion or condition applies. Your team still owns the underlying license position.
- Edits to existing LGPL files: Coverage is uncertain where terms exclude modified or combined code. The LGPL duties for the modified library remain with you either way.
- Source availability for the modified library: Not addressed by an indemnity. Your release process must make the modified source available to recipients.
- Relinking or replacement rights: Not addressed by an indemnity. Build, packaging and linking choices determine whether the library stays replaceable.
- License notices: Not addressed by an indemnity. Notices must be preserved through every AI-assisted edit and refactor.
- Use that breaches license terms: Commonly a point to check as a possible exclusion. Prevention depends on controls before the change is merged.
Enforcing path-level policy and keeping evidence
Counsel and auditors will usually want to see that an organisation knew which code carried LGPL obligations, controlled changes to it, and can show what happened. Specify the evidence standard with counsel in advance. It typically covers the origin and license of the code, the change made, the policy applied, and any human approval.
Trussed enforces policy in the execution path of coding assistants, at the level of individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact, with outcomes of allow, redact, block, or escalate for human approval. Trussed's code provenance records the origin, licence and security context of code, and enforcement produces audit-ready evidence for a regulated enterprise. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.
These capabilities support the workflow described above. Trussed does not provide indemnity and does not determine legal compliance. Whether a given edit satisfies the LGPL remains a decision for your counsel.
Two separate questions in the LGPL vendored-dependency scenario
Indemnity
A contractual remedy with defined scope, exclusions and conditions.
LGPL obligations
Duties that attach to your organisation when it modifies and distributes a library.
Workflow controls
Policy on AI-assisted edits to vendored paths, applied before changes land.
Evidence
Records of code origin, license context and change history for counsel and auditors.
Put controls where the edits happen
Talk through how policy on AI-assisted edits to vendored paths and audit-ready evidence of code origin and licence would work in your environment.
Talk to an Expert