SSPL Code Suggested by an AI Assistant: Licence Exposure for Managed Services

What SSPL requires when software is offered as a service

Most enterprise licence policies were written around distribution: obligations arise when software is shipped to someone else. The Server Side Public License differs in where it places its main obligation. Section 13 addresses the case where a program, or functionality derived from it, is offered to third parties as a service. In that case the licence calls for the source of the service, and the supporting software used to run it, to be made available under the SSPL.

That shifts the risk profile for a company that sells its product as a managed or hosted offering. A codebase that never leaves the company's own infrastructure can still be in scope if customers consume it as a service. The practical consequence for licence policy is that SSPL-covered code is not equivalent to code under a typical permissive licence, and many organisations treat it as a category that needs explicit approval.

This page does not offer legal conclusions. Interpretation of Section 13 for a given product is a matter for qualified counsel. The engineering task is narrower: know when SSPL-covered code enters the codebase, so that counsel is asked before release rather than after.

How SSPL-covered code can arrive through assistant suggestions

An AI coding assistant can bring licensed code into a repository in three broad ways. The first is verbatim reproduction, where a suggestion matches existing source closely enough to be a copy. The second is close paraphrase, where the structure and logic follow a licensed project but the text differs, which makes simple string matching unreliable. The third is dependency suggestions, where the assistant proposes adding a package or library that is itself under the SSPL, or that pulls one in.

Each path looks different to a developer. A pasted block of code is visible in a diff. A suggested import or package entry is a single line, and its licence implications sit several layers down in the dependency tree. A paraphrase may carry no obvious marker at all.

Industry guidance treats this class of risk in general terms. An initial public draft of NIST's Generative AI Profile (AI 600-1) lists intellectual property as a risk, described as eased production of alleged copyrighted, trademarked or licensed content. The same draft includes an action to review generated code. NIST's secure development guidance for generative AI extends the Secure Software Development Framework, but the SSDF is a security framework and not a licence-compliance standard. Teams should map any licence control to those practices without assuming the frameworks already cover it.

Factors that determine whether a managed-service offering is affected

Several questions determine whether SSPL-covered code in a codebase creates an obligation that matters. These are inputs for legal review, not a substitute for it.

First, is the code actually derived from SSPL-licensed work, or merely similar in a way that reflects common patterns? Second, is it part of the service customers use, or confined to internal tooling, tests or build scripts? Third, is the product offered to third parties as a service at all, or delivered as software they run themselves? Fourth, is the SSPL-covered component a dependency of the service, and how is it linked or invoked? Fifth, how much of the surrounding stack would be pulled into the licence's requirement for supporting software?

None of these can be answered from the code alone, but all of them depend on knowing the origin and licence of what was added, and on when it was added. A record that ties a specific suggestion to a specific commit lets reviewers scope the question quickly. Without it, the review begins with an investigation of the repository history.

Enforcing policy at suggestion time, and what it does not replace

After-the-fact review has real strengths. Scanners at build and release see the full dependency graph, and human reviewers apply context that tools lack. Its weakness is timing: by the time a finding appears, the code may be merged, built on by other changes, and difficult to separate.

Enforcement at suggestion time addresses that gap, but it complements later checks rather than replacing them. It needs three things: origin and licence context for the suggested code, a policy that maps that context to an action, and enforcement in the execution path so the action takes effect before acceptance. The actions are allow, redact, block, or escalate for human review. Escalation matters for the ambiguous cases, such as a close paraphrase or a dependency whose licence status needs a decision, where neither automatic approval nor automatic rejection is appropriate.

Trussed provides this at the coding assistant layer. Code provenance gives origin, licence and security context for code, and policy is enforced in the execution path across coding assistants, enforced at runtime, not reviewed after the fact. Enforcement applies to individual interactions and tool calls. Each decision produces audit-ready evidence of what was allowed, redacted, blocked or escalated. Trussed can be self-managed in the customer cloud, with configurable retention and data residency.