JetBrains AI Local Models and GPL Code Risk: What Indemnity Does Not Cover

How local model output can reproduce GPL-covered code

Code models are trained on large corpora that include public repositories, and many of those repositories carry copyleft licences such as GPL-2.0 and GPL-3.0. A model does not store files as files, but it can learn sequences that appear often or distinctively enough to regenerate them. When a prompt, surrounding file context or a function signature closely matches material the model has seen, the completion can be verbatim or near-verbatim.

Nothing about a model being local changes this. A locally hosted open-weight model has the same training-derived behaviour as the same model served elsewhere. What changes is who operates it, who chose it, and what contractual protection surrounds it. In an IDE that lets developers point an assistant at a self-hosted endpoint, the choice of model can sit with an individual developer rather than with a security or legal review.

The GPL conditions distribution of covered code and derivative works on providing source and licensing under the same terms. Whether a particular snippet is protectable, and whether including it creates an obligation, is a legal question that depends on the snippet and the product. This guide does not answer it. The engineering point is narrower: if copyleft-derived code enters a codebase without anyone knowing, the organisation cannot make an informed decision about it.

Where vendor indemnity applies and where it may not

Indemnity is defined by contract. It typically attaches to a named service, under stated conditions, and often depends on the customer using the vendor's own features correctly. That structure matters for local models. If output is generated by a model the enterprise selected, downloaded and operates, the vendor did not produce that output through its hosted service, and there is no reason to assume the vendor's promise extends to it.

The same logic applies to mixed configurations. An IDE may offer both a vendor-hosted assistant and a connection to a local or third-party endpoint. Each path can sit under different terms for data handling and responsibility for output. Hosted usage is generally governed by the provider's policies and business agreements, as the FTC has noted in describing how AI models are incorporated into software development tools. A self-hosted endpoint falls outside those agreements by design.

For each configuration in your estate, the useful question is which party operated the model that produced the output, and what the written terms say about that path. Where the answer is the enterprise itself, the licence exposure stays with the enterprise and should be managed as such.

What exposure remains with the enterprise

The technical exposure is the entry of code with unknown origin into repositories, builds and shipped products. Without detection, a snippet that resembles GPL source looks identical to any other accepted completion. It can pass code review because reviewers rarely have a reference for what a model reproduced, and it can persist through refactoring.

The contractual exposure arises downstream. Customer agreements, open-source policies and acquisition due diligence commonly ask the organisation to represent what is in its software and under which licences. If AI-assisted code was accepted without any record of origin, those representations rest on assumption.

The operational exposure is the absence of runtime policy. Many organisations restrict which models developers may use in principle but cannot enforce that restriction where the assistant runs. A policy document that is not enforced in the path produces neither prevention nor proof.

Evidence an auditor or acquirer will look for

Reviewers generally want to see that a control existed, that it operated, and what it decided. For AI-assisted code that means a record linking a code change to the model that generated it, the policy in force at that moment, the licence and origin context that was assessed, and the outcome. A policy statement alone shows intent. A record of enforcement decisions shows operation.

Voluntary frameworks can help structure this. NIST published a secure software development community profile for generative AI and a generative AI profile for its AI Risk Management Framework in July 2024. Both are guidance, not binding requirements, and they are useful as reference points for mapping which practices your assistant controls support.

Evidence should be generated by the control itself as it operates. Evidence assembled after the fact from developer recollection or scattered tool logs is slower to produce and harder to trust.

One control option: code provenance and enforcement in the execution path

Trussed is one option for this control layer. It enforces policy in the execution path for coding assistants and other AI interactions, with decisions to allow, redact, block, rate limit or escalate for human approval. Enforcement applies to individual interactions and tool calls, so a suggestion can be handled before it becomes part of a change.

Trussed also provides code provenance, covering the origin, licence and security context of code. That context feeds the policy decision: for example, a suggestion whose licence context conflicts with organisational policy can be blocked or sent to a reviewer. Each decision is enforced at runtime, not reviewed after the fact, and generates audit-ready evidence mapped to frameworks including NIST. Trussed deploys self-managed in the customer cloud with configurable retention and data residency, which matters when source code cannot leave your environment.

Trussed has run in continuous production in a regulated enterprise for more than 18 months and holds SOC 2 Type II and ISO 27001, among other attestations. Whether it fits depends on your assistant configurations, the coverage you need, and your evidence requirements. The criteria above apply equally to any alternative.