Does Modifying AI-Suggested MPL-2.0 Code Change Your Source Disclosure Obligations?

What the license text actually defines

MPL-2.0 works at the level of files, and its obligations follow from a few definitions in Section 1.

Covered Software is Source Code Form to which the initial contributor attached the license notice, the Executable Form of that Source Code Form, and Modifications of it, in each case including portions of it. The phrase "including portions" matters for AI-suggested code, because a reproduced fragment of a covered file can itself be Covered Software.

Modifications has two limbs. The first is any file in Source Code Form that results from an addition to, deletion from, or modification of the contents of Covered Software. The second is any new file in Source Code Form that contains any Covered Software. Modifications are themselves Covered Software, so the license travels with the edited material.

Executable Form means any form of the work other than Source Code Form, such as a compiled binary. A Larger Work is a work that combines Covered Software with other material, in a separate file or files, that is not Covered Software.

Nothing in these definitions turns on who typed the code. The license looks at what a file contains and how it relates to Covered Software, not whether a developer or an assistant produced it.

Walking through the modification scenarios

Unmodified reproduction. If an assistant suggests a covered file or a portion of one and the developer commits it as is, that material remains Covered Software. The license notices within it must be kept, and any distribution of it in Source Code Form must be under MPL-2.0 terms.

Modified file. If the developer edits the suggested code, the resulting file falls within the first limb of Modifications, so editing does not exit the license. The source-availability question moves to the whole edited file, not just the changed lines. If edits are so extensive that nothing recognisably derived from the covered file remains, whether Covered Software is still present is a fact-specific question for counsel, not something a diff can settle.

New file containing Covered Software. If a developer moves suggested covered code into a new file, that file falls within the second limb of Modifications. Creating a new file does not avoid the license when covered content is inside it.

New file that only uses Covered Software. A new file that calls or links to a covered file, and contains none of its code, is not Covered Software for that reason alone. It becomes part of a Larger Work. Section 3.3 allows a Larger Work to be distributed under terms of your choice, provided you still comply with the license for the Covered Software inside it.

This is why the license is called file-level copyleft. The obligations attach to covered files and their Modifications, not to every file in the product.

When the obligation attaches: distribution, not editing

The source-availability conditions in Section 3 are framed around distribution. Under Section 3.1, distribution of Covered Software in Source Code Form must be under the terms of the license, and recipients must be told how to obtain a copy. Under Section 3.2, if you distribute Covered Software in Executable Form, you must also make the corresponding Source Code Form available and tell recipients how to obtain it by reasonable means, in a timely manner, at a charge no more than the cost of distribution.

The scope of that duty is the Covered Software, meaning the covered files including your Modifications. It is not the whole Larger Work. Separate files in the same product can remain under other terms. Section 3.4 also bars removing or altering the substance of license, copyright, patent or warranty notices in the covered Source Code Form.

Internal use that involves no distribution does not trigger these conditions in the same way. Where internal use ends and distribution begins is a factual and legal question. Transfers to affiliates, contractors, customers or acquirers should each be assessed with counsel rather than assumed.

So modification neither triggers the obligation nor narrows it. Distribution triggers it, and the file-level contents determine what must be disclosed.

Why after-the-fact review falls short

Scanning a repository before release can find files carrying MPL-2.0 notices. It is less reliable for a snippet that arrived without a notice, was reshaped by a developer, and was placed in a file with other code. By then the origin is not visible, and the team can neither apply the file-level analysis nor show an auditor how it decided.

An auditor reviewing such a decision is likely to want to see the evidence the team had at the time, the rule it applied, who approved the outcome, and that the record was kept consistently. The license analysis above is only usable if the origin and licence information exists before the code enters the codebase.

Where runtime provenance fits

Trussed addresses this operational gap. It provides code provenance, meaning the origin, licence and security context of code, and enforces policy in the execution path of coding assistants. A policy can allow a suggestion, redact it, block it, or escalate it for human approval, and it is enforced at runtime, not reviewed after the fact. A regulated enterprise could, for example, allow suggestions with permissive licence context and escalate those with MPL-2.0 context to a reviewer.

Each enforcement decision produces audit-ready evidence, so the determination for a specific suggestion can be shown later. Trussed can be self-managed in the customer's cloud, with configurable retention and data residency.

This does not replace the legal judgment about distribution or about whether Covered Software remains in an edited file. It supplies the origin and licence context that judgment depends on, captured at the point of suggestion.