The LGPL Relinking Requirement and AI-Generated Code in Mobile Apps

The requirement follows the combination, not the author

LGPL is one of the common open source licences found in enterprise software, alongside GPL, MIT, Apache-2.0 and BSD-3-Clause. Its relinking and replacement provisions concern what an organisation must make possible for recipients of a product that combines its own code with an LGPL-covered library. The trigger is the act of combining and distributing the library, not the way the surrounding code was produced.

A function written by an engineer and a function suggested by an assistant are equally part of the application that links the library. For that reason, AI generation does not by itself create the relinking obligation, and it does not remove it. Whether the licence applies depends on which library is present, how it is combined into the build and how the build is distributed. The exact obligations differ between LGPL v2.1 and v3, so the text of the version that applies to each component should be read directly by legal counsel.

What AI assistance changes is the reliability of the record. Teams may not know whether a generated snippet reproduces LGPL code, or whether a suggested import pulls in an LGPL-covered library. A comment filed by the FTC with the Copyright Office reports participants raising concerns about transparency and the provenance of works generated by AI tools. The same concern applies inside an engineering organisation: the issue is often an unknown origin, not a known violation.

Static and dynamic linking in iOS and Android builds

Linking mode determines what relinking would mean in practice. With static linking, the library's compiled code is merged into the application executable at build time. A recipient who wanted to use a modified version of the library would need the application's linkable build inputs and a way to produce a new executable. With dynamic linking, the library remains a separate file that the application loads at runtime, so replacement is conceptually closer to substituting that file.

Mobile toolchains make the choice less visible than on a server. Dependency managers, prebuilt frameworks and transitive dependencies can fix the linking mode without any engineer deciding it explicitly. An assistant that adds a package or suggests a build setting can therefore make a linking decision as a side effect. Architects should treat linking mode as a recorded property of each component on each platform, not as an assumption inherited from the dependency manager.

The iOS and Android cases should be assessed separately. The same library may be statically linked in one build and packaged as a separate loadable component in the other, and the licence analysis can differ accordingly.

Where AI-generated output creates LGPL exposure

Three patterns account for most of the exposure in mobile builds. Each one is a provenance gap before it is a legal conclusion.

• Reproduced LGPL code: An assistant emits code that closely matches an LGPL-covered library's source. The code is then compiled into the app with no dependency entry that signals the licence.
• Added LGPL dependencies: A suggested import, package or build change introduces an LGPL-covered library, directly or transitively, that no one reviewed against licence policy.
• Unreviewed linking choices: A generated build configuration links a library statically, or bundles it in a way that makes later replacement harder than the team intended.

Distribution constraints and what they do to evidence

Apps delivered through a store typically come without source code access, and vetting commonly works from the app binary. NIST also advises that organisations should not assume an app is fully vetted or meets their requirements simply because it is available through an official app store. For licence purposes, this means store review is not evidence of compliance. The organisation needs its own build records, and binary analysis can serve as a cross-check of declared dependencies.

Code signing adds a further consideration. NIST describes code signing as a control that helps protect the integrity of executables. Integrity controls are designed to detect modification, so the question of how a recipient could replace a library inside a signed, store-distributed package needs an explicit answer for each platform. Architects, legal counsel and release engineers should settle that answer together and document it. Where the answer is difficult, the choice of linking mode, or of a different library, is a design decision to make before release rather than after.

Process decisions for enterprise teams

Start by adding licence policy requirements for LGPL alongside the security requirements already defined for app vetting. NIST's software usage restriction control, CM-10, calls for applying all applicable software verification techniques when using open source components or licensed software. Mapping that practice to mobile pipelines gives licence checks the same standing as security checks.

Next, make AI-assisted contributions attributable. Commit signing and per-account accountability let a reviewer see which changes came from a person or a tool. Treat the SBOM as the candidate record of components and provenance, and confirm that it captures licence and linking mode as well as names and versions. Where an SBOM does not hold those fields, extend the build record rather than relying on memory.

Finally, assign ownership. Legal, security and architecture each hold part of the answer: legal interprets the licence, architecture controls linking and packaging, and security owns verification. One named owner should be accountable for the release-level assessment, and approval should not rest on a store listing.

Enforcing policy in the coding assistant path

Review after the fact depends on reconstructing what an assistant produced. Enforcing policy at the point of generation is more reliable. Trussed enforces policy in the execution path of coding assistants, with actions to allow, redact or block an interaction, enforced at runtime, not reviewed after the fact. It also provides code provenance: the origin, licence and security context of code. Because enforcement generates the evidence, teams get audit-ready evidence of what was permitted and what was produced.

This supports the assessment described above. It does not replace the legal determination of what LGPL requires for a given linking and distribution arrangement. Its value is that legal, security and architecture owners can answer the question of what was allowed and what was generated from a durable record. Trussed runs self-managed in the customer cloud, with configurable retention and data residency.