EPL Secondary License and Shipping AI-Generated Code Under GPL

What the secondary license mechanism does

The Eclipse Public License 2.0 is a weak copyleft licence. Its default position is that source code received under the EPL is redistributed under the EPL. The secondary license mechanism is a narrow exception to that default. It lets the original licensor allow recipients to make the code available under a named alternative licence, which can be the GNU General Public License.

The key point for compliance is who holds the choice. The permission is not something a downstream user can invoke on their own. It exists only if the licensor has attached the Exhibit A notice to the source and named the secondary licence in it. Without that notice, the code remains under the EPL alone.

This is technical analysis, not legal advice. Outcomes depend on the specific notices attached to the specific code, and counsel should confirm any distribution decision.

Conditions that must hold before GPL distribution

Three conditions need to be satisfied together. First, the licensor must have designated the GPL, with its version and any exceptions or additional permissions, as a Secondary License in the Exhibit A notice. Second, the notice must actually accompany the source you received. A notice that existed in the upstream repository but was stripped in transit does not help you. Third, the distribution must meet the conditions the EPL-2.0 sets for Source Code Form and for combined works.

The combined-works condition is where teams most often go wrong. The permission to use a Secondary License is tied to how the EPL-covered material is combined with other material and how the resulting files are made available. Treating the whole product as freely relicensable because one file carries a designation misreads the mechanism.

The practical consequence for GPL compatibility is that the answer is conditional. EPL code that lacks a Secondary License designation cannot be assumed to be distributable under the GPL. Compatibility turns on the licensor's notice, not on a general reading of the two licences.

Why AI-suggested code breaks the usual assumptions

Conventional open source review starts from a known component: a package, a version, a repository, a licence file. AI-suggested code arrives without any of that. A snippet may be original output, a close paraphrase of licensed source, or a near-verbatim reproduction, and the assistant does not tell the developer which.

That gap defeats each condition above. If the origin is unknown, you cannot say whether the code derives from EPL material. If it does, you cannot say whether the Exhibit A notice existed, since the snippet rarely carries it. And you cannot identify which terms attach, so you cannot test whether distributing under the GPL satisfies them.

The result is that the compliance question becomes a provenance question. The legal analysis is manageable once origin, licence and notice are known. The difficulty is that, for AI suggestions, those facts are usually missing at the moment the code enters the codebase.

Controls in the developer workflow that can supply the evidence

There are two places to intervene. Review after commit relies on developers and scanners to notice a problem once the code is in the repository. By then the suggestion's context is gone, and attribution of a snippet to an assistant is often unrecoverable.

Intervention at the point of suggestion is stronger for this problem. A provenance check at that moment can surface origin and licence context before the code is accepted, and a policy can determine what happens next. Useful outcomes include allowing the suggestion, redacting the matching portion, blocking it, or escalating to a human reviewer when the licence is copyleft or the notice status is unclear.

When evaluating any such control, ask whether it runs in the assistant's execution path or only afterward, what information it records for each decision, and how long that record is retained. A control that cannot show its decision after the fact does not meet the evidence list above, however accurate its detection.

How Trussed enforces policy at suggestion time

Trussed enforces policy in the execution path of coding assistants. Its code provenance capability surfaces the origin, licence and security context of code, so a suggestion that resembles licensed source can be handled according to policy. Policy can allow, redact or block the suggestion, or escalate it for human approval. Enforcement is at runtime, not reviewed after the fact.

Each decision produces audit-ready evidence. For the question in this guide, that means a record of what was suggested, what licence context applied, and what the policy decided. Whether a particular Exhibit A designation exists remains a determination for the reviewer the case is escalated to, supported by that record.

Trussed is deployed self-managed in the customer cloud, with configurable retention and data residency, so the evidence can sit where the regulated enterprise requires it.