EPL-2.0 Code Suggested by an AI Assistant: File-Level or Whole-Project Obligation

How EPL-2.0 scopes its copyleft

EPL-2.0 does not ask a recipient to license an entire product under the same terms. In outline, the licence works through a few defined terms. The Program is the licensed work as distributed under the licence. A Contribution is content that a contributor adds to or changes in the Program and then distributes. A Modified Work is a work that results from adding to, deleting from or modifying the Program's contents, and the licence is written so that a new file containing Program contents is treated as part of that picture.

The practical consequence is a boundary. Files and modules that contain or derive from the Program carry the licence's terms. Separately developed modules that interact with the Program, for example through its interfaces, are generally not treated as Modified Works merely because they interact. This is the sense in which EPL-2.0 is described as weak copyleft: the obligation follows the licensed code and its derivatives, not the whole codebase around it.

The exact wording of these definitions, including what counts as a separate module, should be read directly from the licence text and confirmed with counsel before a policy relies on it.

Integration patterns that keep an obligation at file level, and those that widen it

The table gives a working starting point for engineering triage. Each row is a general reading, not a legal conclusion, and each depends on how the result is distributed.

• Copied into an existing EPL-2.0 file: Obligation stays at that file, which is already under EPL-2.0. Distribution triggers the licence's terms for it.
• New file in an EPL-2.0 project containing suggested EPL-2.0 code: The new file likely carries EPL-2.0 terms. The obligation is file-level, but the project must handle it consistently.
• Original new file that only calls EPL-2.0 interfaces: Generally treated as a separate module. Keep the boundary clear and recorded, and confirm with counsel.
• EPL-2.0 library imported or linked unmodified: The library's own terms apply when you distribute it. Whether the combination widens anything depends on how it is packaged and distributed.
• Suggested EPL-2.0 code embedded in a proprietary file: That file likely falls under EPL-2.0. Proprietary logic in the same file is the main exposure, so this pattern is the one to block or escalate.
• Combination with GPL-licensed code: The Secondary License provision may allow distribution under a designated GPL licence in some cases. It depends on the original notices, so escalate.

What applies on distribution

EPL-2.0 obligations are mainly triggered by distribution. When Object Code containing EPL-2.0 material is distributed, the licence requires that the corresponding Source Code be made available under the licence's terms, and that copyright, patent and attribution notices be retained. The licence also contains patent terms that recipients and contributors should read, because they travel with the code. Purely internal use that involves no distribution is generally a different question from shipping a product, and teams should not assume the two are equivalent without counsel's view.

Several points should always go to counsel rather than be settled in engineering policy: whether a given file is a Modified Work or a separate module, how a Secondary License applies to a specific combination, how Source Code availability is met for a particular delivery model, and how the patent terms interact with your own patent position. Engineering's job is to supply accurate facts about what was suggested, where it landed and how it ships.

Why AI suggestions complicate the analysis

The scoping rules above assume you know what the code is and where it came from. With an assistant, origin is uncertain at the moment of suggestion. A developer sees a plausible snippet, not a licence. If it reproduces EPL-2.0 source and is pasted into a proprietary file, the pattern in the table changes from a clean boundary to a file-level obligation, and no one may notice until later.

Two general points help frame the review. First, NIST SP 800-218A does not distinguish between human-written and AI-generated source code, because all source code is assumed to need evaluation before use. That supports one review path at the point where assistant output enters the codebase, rather than a lower standard for AI output. Second, the U.S. Copyright Office's registration guidance addresses authorship: material whose expressive elements are determined by an AI technology is not the product of human authorship for registration purposes. That is a separate question from licence terms. Do not read "not copyrightable" as "free of licence terms" without counsel.

The outcome of each case should be one of four decisions: allow, rewrite, block, or escalate for human approval. The decision should follow from the integration pattern and distribution status, applied the same way across teams.

Enforcing the decision in the coding-assistant path

A review after commit finds problems late, once the code has spread through branches and builds. The decision is easier to apply and to defend when it is enforced before the suggestion is accepted.

Trussed provides code provenance, meaning the origin, licence and security context of code, and enforces policy in the execution path of coding assistants. Policy can allow, redact or block an interaction, or escalate it for human approval, and each outcome produces audit-ready evidence. For a compliance leader, that means an EPL-2.0 match can be handled by a written rule, and the record shows what was suggested, which rule applied and who approved it. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency.

The legal scoping questions above still belong with counsel. Enforcement ensures that the answers counsel gives are applied consistently and that each decision can be shown to an auditor.