MPL-2.0 vs LGPL for AI-Suggested Code: Which Obligations Follow the File and Which Follow the Binary

The unit each licence attaches to

MPL-2.0 is usually described as file-level copyleft. It defines Covered Software and Modifications around source files. A Modification includes changes to existing covered files, and it also includes a new file that contains Covered Software. When a covered file is distributed, its source must be made available under MPL-2.0, and licence notices must be kept intact. When the software is distributed in executable form, recipients must be told how to obtain the source of the covered files. The MPL allows a Larger Work to combine covered files with files under other terms, so the obligation does not spread to unrelated files in the same product.

LGPL (versions 2.1 and 3.0) works at a different level. It distinguishes the Library from an Application that uses it, and version 3.0 names the result of combining them a Combined Work. Changes to the Library itself must remain under LGPL. The application can generally stay under its own terms, but the distributor of a Combined Work must give notice that the library is used and covered by the licence, supply the licence text, and let recipients modify the library and relink. This is usually met either by dynamic linking through a suitable shared library mechanism or by providing material that enables relinking. Version 3.0 adds installation information requirements for certain consumer devices.

In short, MPL-2.0 asks which file a piece of code lives in. LGPL asks which library it belongs to and how the finished product is assembled, linked and shipped.

Side-by-side scope of obligations

The table summarises the mechanics at a level suitable for architecture discussions. Confirm the exact wording of the licence version in use before relying on it.

• Unit of copyleft: MPL-2.0: the source file (Covered Software and Modifications). LGPL: the Library, with special rules for a Combined Work that uses it.
• Source disclosure: MPL-2.0: source of covered files, including new files containing covered code, on distribution. LGPL: source of the Library and its modifications, plus material needed for relinking where applicable.
• Rest of the product: MPL-2.0: files under other terms may sit alongside covered files in a Larger Work. LGPL: the application may keep its own terms if the combined work meets the licence conditions.
• Binary-level duties: MPL-2.0: tell recipients how to get covered source when shipping executables. LGPL: replaceability of the library, through shared linking or relinking material.
• Notices: MPL-2.0: preserve licence notices in covered files. LGPL: prominent notice of library use and inclusion of licence texts.
• Where reviewers look: MPL-2.0: file inventory and file headers. LGPL: dependency graph, linking method and build and packaging.

What this means when an assistant suggests code

The scenario matters more than the licence name. Consider three cases.

Verbatim or near-verbatim reproduction placed in a new file. Under MPL-2.0, a new file that contains Covered Software is itself a Modification, so the file carries MPL terms if distributed. A suggestion that reproduces LGPL library code in a new file raises a different question: whether you have, in effect, created a modified copy of the library, which would need to remain under LGPL, or a separate work.

A snippet inserted into an existing MPL-covered file. This is a Modification of a covered file. Source availability and notice duties for that file follow on distribution, whether or not the snippet came from an assistant.

A snippet inserted into proprietary application code that merely calls an LGPL library. The LGPL concern is usually not the snippet but the linking and packaging decisions around the library: static or dynamic linking, whether recipients can replace the library, and whether notices ship with the product. A close adaptation of library internals in application code is harder to classify, and teams should treat it as a case for legal review.

The boundary between a modification and a separate work is a legal judgement that depends on the facts, including how much was copied, how it is used and how the product is distributed. Internal use without distribution generally triggers different duties from shipping binaries or hosting for others, and that question also belongs in review. An engineering team can narrow the question by knowing what was suggested, what it resembled, where it was placed and how the product ships. It should not try to settle the legal answer by itself.

Where runtime enforcement helps and where legal review remains

Enforcement at the point of suggestion is useful because licence questions are cheaper to answer before code enters a repository than after a release. A policy can allow suggestions with no origin concern, redact or block those whose origin or licence context conflicts with organisational rules, and escalate ambiguous cases for human approval. Rules that are specific to a licence family are easier to maintain than a single blanket rule, because MPL-2.0 and LGPL concerns differ: file placement for one, linking and distribution for the other.

Trussed provides code provenance covering the origin, licence and security context of code, and enforces policy in the execution path of coding assistants, with actions to allow, redact, block or escalate for human approval. Because policy is enforced at runtime, not reviewed after the fact, each decision produces audit-ready evidence of what was suggested and what was permitted, which supports the records listed above.

This does not replace legal judgement. Whether a snippet is a modification, whether a combination creates a Combined Work, and what a given distribution model requires remain legal determinations. A sound division of labour is to automate the consistent, repeatable decisions and reserve the contested ones for counsel, with the evidence ready when they are asked.