Copyleft Policy Enforcement for AI-Generated Code: Different Rules for SaaS and Distributed Products

Why one organisation-wide licence rule fails

Copyleft licences, of which the GNU General Public License is the canonical example, require derivative works to carry the same licence. Permissive licences contain no such requirement. What a copyleft licence demands in practice depends on how the software reaches its users. The working assumption in this guide is that distributing a binary can trigger GPL and LGPL obligations, and that network use of a SaaS can trigger AGPL obligations without any distribution. Your legal reviewers should confirm how each licence applies to your products before the tiers below are adopted.

If that assumption holds, a single rule cannot serve both delivery models. A rule strict enough for distributed products blocks code that a SaaS-only service may be able to use. A rule relaxed for SaaS exposes distributed products. Platform teams that share repositories and assistant tooling across both need the rule to change with the deployment model.

AI coding assistants sharpen the problem. Suggested code can arrive with unclear origin and licence, and a developer accepting it has no signal that the snippet matters to the delivery model. The decision has to be made with the deployment context attached, at the point the code is produced.

Define three policy tiers

A SaaS here is a provider-run application that users reach through a browser or program interface, without controlling the underlying infrastructure. That makes it a distinct deployment model, and the first tier.

SaaS-only: code runs on infrastructure you operate and is never shipped to customers. Network copyleft is the main concern. Strong and weak copyleft are more likely to be acceptable, subject to legal approval.

Distributed: code ships to customers as binaries, packages, images or devices. Strong and weak copyleft both matter, and network copyleft is usually excluded as well.

Mixed: the repository, or a library inside it, feeds both kinds of product. Define the default before rollout. The simplest default is to apply the stricter tier, with a documented exception route for components proven to stay on the SaaS side.

Store the tier as repository metadata that the enforcement point can read per request. Inventory repositories first, and assign an owner to each tag so that reclassification is a controlled change.

Map licence families to outcomes per tier

The matrix below is an illustrative starting point, not legal advice. Legal owners should approve the final version before enforcement is enabled. Redact means the matching snippet is removed from the response while the rest of the interaction proceeds. Block stops the interaction. Escalate holds it for a named human approver.

• Permissive: SaaS-only: allow. Distributed: allow, with attribution notices retained. Mixed: allow.
• Weak copyleft (for example LGPL, MPL): SaaS-only: allow. Distributed: escalate, or redact if the match is a verbatim snippet. Mixed: escalate.
• Strong copyleft (for example GPL): SaaS-only: allow or escalate, per legal decision. Distributed: block. Mixed: block.
• Network copyleft (for example AGPL): SaaS-only: escalate, or block if legal prefers. Distributed: block. Mixed: block.
• Unknown or undetected licence: SaaS-only: escalate. Distributed: block. Mixed: block. Decide this row deliberately, because it will be hit often.

Provenance signals each decision needs

A tier-aware rule needs three kinds of signal about the code, plus deployment metadata.

Origin: where the code appears to come from, for example an identified public project, a dependency, or your own repositories. Without origin, attribution and match decisions cannot be made.

Licence: the licence attached to that origin, normalised to a family so the matrix above can be applied. Dual-licensed and modified-licence cases should resolve to escalate, not to a guess.

Security context: known vulnerabilities or risky patterns associated with the origin. This is not a copyleft input, but the same lookup supplies it, and a single decision can then account for both licence and security.

Deployment metadata: the repository tier, and for mixed repositories the component-level exception if one exists.

Plan for missing data. When origin or licence cannot be determined, the outcome should come from the unknown row of the matrix, not from silence. Align the assistant-related controls with the NIST secure software development profile for generative AI, and run a pilot on one SaaS repository and one distributed repository to measure false positives before wider rollout.

Execution-path enforcement versus after-the-fact review

Enforcing in the execution path means the policy is evaluated on individual interactions and tool calls, and the outcome is applied before the output is used. Review after the fact relies on scanning commits or builds, which means copyleft-licensed code may already be merged, copied elsewhere or shipped in an artifact when it is found. Remediation then involves rewrites and re-reviews. Post-hoc scanning still has value as a backstop, but it cannot show that a rule was applied when the code was generated.

Trussed enforces policy in the execution path for coding assistants, with allow, redact, block and escalate for human approval outcomes. Its code provenance supplies origin, licence and security context for the code, and enforcement produces audit-ready evidence. The scope is individual interactions and tool calls, so tier definitions and the licence matrix remain your decisions. Whatever tooling you use, ask whether enforcement happens before output reaches the developer, how missing provenance is handled, and how mixed repositories are resolved.