Amazon Q Developer Indemnity and LGPL Code: Where Coverage Ends and Compliance Begins

What an indemnity settles, and what it leaves open

An IP indemnity is a promise about who bears the cost and defence of certain third-party claims. It is a risk-transfer instrument. It sits in the contract, and its reach is defined by the wording of the terms that apply to your agreement and service tier at the time you use the tool. Those terms set the scope, the conditions a customer must satisfy, and the exclusions. Compliance teams should read the indemnity as written and avoid assuming it is broader than its text.

What an indemnity does not do is change the licence status of a piece of code. If a suggestion resembles or derives from LGPL-licensed source, the licence terms that govern that source are unaffected by who would pay if a claim followed. The obligations that come with using the code, and the work of showing you met them, stay with the organisation that accepted and shipped it.

The question of liability among users, AI tool developers and the developers of training data is still being raised publicly. An FTC comment to the U.S. Copyright Office poses it as an open question, not a settled rule. That is a reason to rely on written contractual terms and on your own evidence rather than on general assumptions about where responsibility falls. Nothing here is legal advice.

Why LGPL needs its own treatment

The LGPL is usually described as a weak copyleft licence. Unlike a permissive licence, which mainly asks for attribution and notices, it attaches conditions to the library itself. Unlike a strong copyleft licence, it is generally understood to allow the library to be used inside a larger work, including a proprietary one, provided specific conditions are met.

Those conditions are commonly discussed in four groups: preserving licence and copyright notices, making the library's source available (including any modifications to it), allowing recipients to modify the library and relink the application against the modified version, and respecting how the library is linked and distributed. Which of them apply depends on the licence version, on whether the code is dynamically or statically linked, and on whether the software is distributed or only run internally. Counsel should make those determinations.

This is where AI-generated code creates a practical gap. A suggestion that reproduces or closely follows LGPL source can be pasted into a proprietary module, where there is no library boundary, no notice and no relinking path. The obligation is easy to trigger and hard to see afterwards, because the code now looks like any other file in the repository.

Indemnity compared with licence compliance

The two protect against different failures and need different evidence. Treating one as a substitute for the other leaves a gap that neither fills.

• Question answered: Indemnity: who bears the cost of a covered claim. Licence compliance: whether the code was used on terms the licence permits.
• Source of the rule: Indemnity: the vendor's contract terms. Licence compliance: the licence text and how the code is linked and distributed.
• Who acts: Indemnity: the customer must meet conditions and make a claim. Licence compliance: the enterprise must meet obligations before and after release.
• Evidence needed: Indemnity: proof that conditions were met. Licence compliance: origin, licence, linking and notice records for each affected component.
• Failure mode: Indemnity: a claim falls outside scope or conditions were not evidenced. Licence compliance: an obligation goes unmet because no one knew the code was LGPL.

Making indemnity conditions provable

Indemnities for AI-generated output commonly depend on how the customer used the tool: which service tier or plan, which settings were enabled, and how flagged or referenced suggestions were handled. Whatever the current terms require, the practical test is the same. Could you show, for a specific accepted suggestion, that each condition held at the moment it was accepted?

That requires capturing facts that are difficult to reconstruct later: the tool and version in use, the configuration in effect, any licence or reference information shown with the suggestion, and what the developer or reviewer did in response. Tool version is a recordable attribute of a development environment, and treating it as a record from the start is cheaper than inferring it after a dispute.

Retention matters as much as capture. A record that expires before a claim or audit arises does not help. Decide in advance how long reference and licence information is kept, whether it can be exported out of the tool, and where the authoritative copy lives. Those decisions belong to compliance and legal, not to individual developers.

Where Trussed fits

Trussed provides code provenance, which records the origin, licence and security context of code, and enforces policy in the execution path across coding assistants. Policy decisions such as allow, redact, block or escalate for human approval are enforced at runtime, not reviewed after the fact. That enforcement produces audit-ready evidence of what was permitted and what happened, which is the kind of record the controls above call for.

This is a complement to the contractual position, not a replacement for reading the indemnity terms or for legal review of LGPL obligations. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency.