Amazon Q Developer Indemnity and MPL-Licensed Code in Automated Java Upgrades

What an indemnity is, and what it is not

An IP indemnity is a term in a contract. It describes a vendor's commitment to respond to certain third-party claims, and it is bounded by conditions and exclusions. Typical categories of condition include how the service was configured, whether the output was modified, and notice and cooperation requirements. Whether any of these apply to a given feature is a matter for the current text of the vendor's service terms and product documentation, read by legal counsel.

Two points follow from the nature of the instrument. First, indemnity is about who responds to a claim, not about whether your organisation is complying with a licence. Second, it is not a record. It will not tell an auditor which file came from where, under which licence, or who approved it.

For Amazon Q Developer, the practical step is to treat the Code Transformation (Java upgrade) feature as its own question. Do not assume that a statement about suggestions made in the editor extends to batch transformation output. Ask for the answer in writing, tied to the specific feature and the current terms.

How MPL obligations attach to files

The Mozilla Public License is usually described as a weak or file-level copyleft licence. The obligations attach to files rather than to an entire application. In general terms, if you modify a file that is covered by the MPL, or distribute it, the licence's conditions apply to that file, including making its source available under the licence when you distribute it. Separate files under other licences can generally sit alongside it in the same product.

That file-level scoping is why the question matters for automated changes. A transformation operates on files. If an MPL-covered file is added to the repository, or an existing MPL-covered file is edited, the unit of analysis is that file, and the facts that matter are which file, what changed, and how the result is distributed.

Whether a specific addition triggers specific duties in your distribution model is a legal determination. Engineering's role is to give counsel accurate facts: the file list, the licence identified, the change made and the distribution path.

How licensed code can enter during a Java upgrade

A Java version upgrade is more than a compiler setting. Moving a codebase to a newer Java version commonly involves several kinds of change, and each has a different licence implication.

Source edits modify files you already own or have already licensed. If any of those files carry an MPL header, the edit is a modification of an MPL-covered file. Dependency manifest changes alter which library versions resolve at build time, and a newer version of a library may be under different terms than the one it replaces. New dependencies may be added where an older library is replaced or a removed platform API needs a substitute. Transitive dependencies can then arrive without anyone naming them.

The common thread is that none of these changes necessarily looks like adding code. A diff of a manifest is short. A resolved dependency tree can be long. Unless the licence inventory was recorded before the upgrade and compared afterwards, MPL-licensed material can enter with no recorded origin, licence or review decision.

If the tool offers licence-reference or similarity-filtering features, ask whether they apply to transformation output at all, and what they record. A filter that flags suggestions in an editor is a different control from one that inventories dependencies after a batch change.

The evidence needed to act on those answers

Answers from a vendor and counsel are only useful if the repository can support them. That requires evidence created at the time of the change, because reconstructing it later from a merged commit is unreliable.

Start with a baseline. Before any automated upgrade, capture the dependency manifest and a licence inventory so that the post-upgrade state can be compared against it. Then, for each AI-modified or AI-added item, retain a record of its origin (which tool and which run produced it), the licence identified, the reviewer and the decision taken. Where a library was added, record the resolved version and the licence found for it, including transitive dependencies. Where a file was edited, record whether it carries a licence header that changes how it must be handled.

Access scope also matters. NIST's draft SP 800-218A community profile, which is an initial public draft and not a final requirement, includes language on protecting source code, executable code and configuration-as-code using least privilege, so that only authorised personnel, tools and services have access. Applied here, it is a reasonable reference for deciding which repositories and branches an automated transformation tool may read and write.

No single record format is mandated. What matters is that each entry lets a reviewer answer three questions: how did this material enter, what licence applies, and what was decided.

Where runtime enforcement and code provenance fit

The evidence described above is easiest to produce where changes are made, which is the execution path of the coding assistant. Reviewing after the fact depends on someone reconstructing what happened. Policy enforced at runtime can act on each interaction or tool call as it occurs.

Trussed enforces policy in the execution path of coding assistants, with actions that include allow, redact, block, rate limit and escalate for human approval. Its code provenance capability records the origin, licence and security context of code. In the scenario in this guide, that means a rule such as escalating for human approval when a change introduces material under a licence your counsel has flagged, with the decision and its context retained as audit-ready evidence generated by the enforcement itself. The scope is individual interactions and tool calls.

This does not alter or extend any vendor's indemnity, and it does not decide how MPL applies to your products. It supplies the factual record that counsel, auditors and engineering need in order to apply the contract and the licence. Trussed can be self-managed in the customer cloud, with configurable retention and data residency, which matters when evidence about source code must stay within your own environment.