SSPL vs AGPL-3.0 for AI-Generated Code: Which Service-Use Trigger Hits Software Vendors Harder?

How the two triggers differ in text and scope

Both licences extend copyleft beyond distribution. Section 13 of each attaches obligations to making software available as a service, not only to shipping binaries. That shared idea is where the similarity ends.

AGPL-3.0 Section 13 is framed around users interacting with a modified version of the program remotely over a network. The question it asks is whether the vendor modified the covered program and whether users reach that modified version. The disclosure obligation follows from that interaction, and it is expressed in terms of the modified program.

SSPL Section 13 is framed around offering the program's functionality as a service. Its obligation is broader in what must be released: the corresponding source for the entire service stack, including management, orchestration and hosting layers. In practice this means the unit of disclosure is the service, not the program.

The practical consequence for an architect is a difference in blast radius. Under AGPL-3.0 the analysis starts from a specific program and its modifications. Under SSPL the analysis starts from the service and everything that makes it run. A vendor whose hosting and orchestration layers are proprietary, or are built from components with their own licence terms, has more to examine under SSPL.

Which trigger is heavier by deployment pattern

The comparison below is a reading aid, not a legal conclusion. Each pattern should be checked against the exact licence text and the specific facts of the product.

• Hosted SaaS: AGPL-3.0: applies where a modified version is offered to users over a network, and the release concerns that modified version. SSPL: applies where the software's functionality is offered as a service, and the release extends to the service stack. SSPL is generally the broader obligation.
• Managed service offering: The pattern SSPL's wording targets most directly. Operating a covered program as a service for customers puts management, orchestration and hosting layers in scope. AGPL-3.0 still applies to modifications, but its disclosure remains narrower.
• Internal-only use: Both triggers turn on offering or network access for others. Where no outside party interacts with the software, exposure is generally lower under either licence. Confirm who counts as a user, including contractors, affiliates and customers with limited access.
• Embedded or distributed components: Shipping code to customers engages each licence's distribution terms in addition to Section 13. Hybrid products that both ship components and host a service need both analyses.
• Unmodified versus modified code: AGPL-3.0's trigger is tied to modification. This matters for AI-assisted work, because assistant output merged into a covered program can turn an unmodified deployment into a modified one.

Where AI-generated code adds uncertainty

Coding assistants produce suggestions that may resemble, or derive from, code released under network-copyleft or source-available licences. A developer accepting a suggestion usually cannot tell whether it does. The licence context that a human author would normally know is absent at the moment the code is committed.

This changes the risk in three ways. First, origin is unclear: the commit history records who accepted the code, not where it came from. Second, the licence is unknown, so a snippet under a network-copyleft licence can sit in a proprietary service without anyone having decided to include it. Third, the point of detection drifts late, to a periodic scan or a pre-release review, by which time the code may be spread across modules and deployments.

How this plays out differs by trigger. Under AGPL-3.0, the worry is that assistant output becomes part of a modified version that users reach over a network. Under SSPL, the worry is wider, because once covered code is part of a hosted service, the question of what must be released extends to the surrounding stack. Neither outcome is certain in any given case. Whether a particular snippet creates an obligation is a legal question, and the point here is that the facts needed to answer it are often not recorded.

NIST's SSDF Community Profile for generative AI, published in July 2024, takes a useful baseline position. It does not distinguish human-written from AI-generated source code, because it assumes all source code should be evaluated for vulnerabilities and other issues before use. A vendor can apply the same logic to licence questions: AI-generated code goes through the same gate as every other contribution, with no exemption for convenience.

Where runtime policy enforcement fits

Detection after the fact, through scheduled scans or pre-release audits, finds problems after the code has spread. Enforcing policy where the assistant output is produced moves the decision to the point where it is cheapest to act on.

Trussed enforces policy in the execution path of coding assistants, with the ability to allow, redact or block individual interactions and tool calls, enforced at runtime, not reviewed after the fact. It provides code provenance: the origin, licence and security context of code. Because enforcement itself generates the record, a regulated enterprise gets audit-ready evidence of what was permitted and what was not, which maps to the reviewer record described above.

This does not determine licence outcomes and does not provide legal protection. It supplies the facts about origin, licence and security context that counsel needs in order to apply either Section 13 to a given product.