Cursor LGPL Code Coverage by Model: Enforcing License Policy Independent of Model Choice

Vendor-side protections are not a uniform control

When a coding assistant offers several underlying models, three layers of protection can apply to generated code: the assistant vendor's own settings and terms, the terms of the model provider that serves the request, and whatever controls the enterprise adds itself. Each layer has its own owner and its own scope. A public-code filter, a privacy setting or an indemnity may be defined by one party and conditioned on how the model is accessed.

For that reason, the question of how Cursor's LGPL coverage varies by model cannot be answered from the model's name. Model developers often do not disclose the specific data sources their models were trained on, and models differ in how open they are, from weights availability to training data and legal restrictions on use. Models also reach developer tools through licensing agreements and APIs, where data use may be governed by the provider's policies and any business agreements. An enterprise cannot infer license exposure from this information, and it should not infer uniformity either.

A practical position for security engineers is to separate two kinds of statement in internal documentation. The first is what a vendor documents and contractually commits to. The second is what the enterprise has verified or enforces itself. Vendor-side filters and indemnities belong in the first category, and they should be read for scope, conditions and exclusions per provider. Only controls the enterprise operates belong in the second.

Why LGPL is hard to detect in generated snippets

LGPL is a distinct obligation. It is not a permissive license that asks mainly for attribution, and it is not strong copyleft such as GPL, which generally extends its terms to the combined work. The LGPL sits between them. In general terms, it allows a library to be used by code under other terms, provided that users can replace the library with a modified version, and it expects changes to the library itself to remain under the LGPL. Confirm the exact obligations for the specific license version against the license text and with counsel.

Four obligations tend to matter in practice. Dynamic linking determines whether an application can use the library without carrying the library's terms into its own code. Modification covers changes made to the library itself, which attract sharing obligations. Relinking requires that a user be able to substitute a modified library, which is a property of how the application is built and shipped. Notice requires preserving copyright notices and license text.

Most of these obligations depend on context that a snippet does not carry. Whether a generated function is a derivative of library code, whether it will be dynamically linked, and whether the build allows relinking are facts about the surrounding project and the release process. A snippet may also have no license header at all. A reviewer looking only at the output can therefore miss an LGPL obligation, and a filter that matches known public code addresses only part of the problem. Teams should measure false negatives on their own generated code rather than assume detection is reliable.

What evidence the control should produce

Audit evidence should let a reviewer answer which LGPL obligations were or were not addressed for a given piece of generated code. Per output, capture the origin (the assistant, the model identifier as the tool reports it, the time and the user), the license context, the security context, the decision taken and the version of the policy that was applied.

The model identifier is a recorded attribute of the request. It is not a claim about model lineage or what the model was trained on, which providers often do not disclose. Its value is operational: if the enabled model list changes, the change appears in the recorded context, and the team can compare decisions before and after it. Without such records, a model change can alter exposure unnoticed.

Retention matters as much as content. Some contracts require delivery of source code and license files. For example, the EPA open source clause at 48 CFR 1552.239-71, which applies to EPA contracts only, requires source code, a license file and related materials, and the government asserts unlimited rights to furnished code unless the contract says otherwise, as of November 2026. Whether a given contract carries such terms is a contract-level question, but records of code origin and license context are what make those deliverables defensible.

Where Trussed fits

Trussed is runtime control and evidence infrastructure for regulated enterprises. It enforces policy in the execution path across coding assistants, models, agents and tools, with decisions to allow, redact or block. Its code provenance capability supplies the origin, licence and security context of code, so license policy is enforced at runtime, not reviewed after the fact. Trussed runs 100+ models under one policy plane, which is why one set of rules can apply when developers change models.

Enforcement generates continuous audit-ready evidence, mapped to frameworks including NIST, and deployment can be self-managed in the customer cloud with configurable retention and data residency. Trussed does not provide model provenance or lineage, and it does not replace legal review of LGPL obligations. It gives security teams a consistent enforcement point and a durable record of what was allowed, redacted or blocked.