Writing an Open-Source License Policy for AI Coding Assistants: GPL, AGPL, EPL and Runtime Enforcement

Why dependency-era policies do not cover assistant output

Most open-source policies were written for a human choosing a package. Someone selects a dependency, a scanner or reviewer checks its license, and the decision is recorded. An AI coding assistant removes that gate. It can suggest or generate code that resembles or reproduces copyleft or weak-copyleft code, and the developer may accept it in seconds with no license check at all.

NIST's Generative AI Profile (AI 600-1, published July 2024) gives a useful anchor. Control GV-1.1-001 calls for aligning generative AI development and use with applicable law, including copyright and intellectual property law, and for updating acceptable use policies to address proprietary and open-source generative AI technologies and data, as well as contractors, consultants and other third-party personnel. Two scoping decisions follow. The policy should cover assistant output, not only dependency adoption. It should also apply to everyone who uses an assistant against your repositories, including third parties.

This guide describes a policy that engineers can implement as rules. It is not legal advice, and the license-specific positions below should be confirmed with counsel against the license texts.

Treating GPL, AGPL and EPL differently

A single "copyleft" bucket is too coarse to enforce. The three licenses are triggered by different events, so the policy question differs for each. The starting tiers below are examples for counsel to confirm, not conclusions.

On the GPL, NIST's description is high level: if you give someone a binary with GPL code linked into it, you must provide the source if asked, and when software under different licenses is combined, all of the licenses must be obeyed. GPL v2 and v3 have different terms, so the policy should name which versions it addresses and leave the detailed reading to counsel.

• GPL (v2 and v3): Trigger: distribution of a work that incorporates the code. Policy question: will this repository's output be distributed to customers, partners or devices? Example starting tier: block in distributed products, escalate elsewhere.
• AGPL: Trigger: associated with network use, so obligations can matter for hosted services even without shipping binaries. Policy question: is the repository a network-facing service? Example starting tier: block for service repositories, escalate for internal tools.
• EPL (including EPL 2.0): Trigger: weak copyleft applied at file and module level, with secondary-license provisions in EPL 2.0. Policy question: can the code stay isolated in its own file or module with its license intact? Example starting tier: escalate, with allow only where isolation and attribution can be shown.
• Unknown or unmatched license: Trigger: no reliable license signal. Policy question: what happens when provenance is missing? Example starting tier: escalate for sensitive repositories, allow with evidence for low-risk ones.

Provenance signals the decision depends on

The policy decision needs inputs. Three are useful: the origin of the code (where it appears to come from), its license, and its security context (for example, what repository, data or secure development practice it touches). NIST's guidance points toward documenting content provenance and including AI in secure coding practices under SP 800-218, which supports treating security context as a provenance dimension alongside origin and license.

What each assistant exposes at generation time varies, so the policy should state which signals the enforcement point can actually obtain and what it does when one is missing. A missing license signal should map to a defined tier, not to silent approval. Without that rule, the unknown case becomes the default path for exactly the output you cannot classify.

The decision and its inputs should be recorded together. A record that says only "blocked" cannot be defended later. A record that shows the origin, license, security context, policy version and resulting action can.

Evidence to retain for auditors and counsel

The test of the policy is whether you can show, for a given piece of AI-assisted code, how it was handled. Define the evidence fields in the policy itself so retention is a requirement, not an afterthought. Retention periods and formats are your decision, and counsel should confirm them.

Trussed produces continuous, audit-ready evidence as a by-product of enforcement, with self-managed deployment in the customer cloud and configurable retention and data residency. Teams that deliver code under federal contracts should also check contract terms on ownership of custom developments and source disclosure with contracting and counsel, because those terms may affect which assistant output can be used.

• Decision record: Action taken, timestamp, user, assistant and repository.
• Provenance inputs: Origin, license and security context used for the decision.
• Policy version: The rule set and tier mapping in force at that moment.
• Approval trail: Approver, rationale and expiry, linked to the specific suggestion.
• Exception register: Open and expired exceptions by repository and license family.
• Retention settings: Retention period and data residency applied to the records.