GPL-3.0 Claim Notice and Cooperation Deadlines When Code Comes From Multiple AI Coding Tools

Three families of deadlines, three different authors

When a GPL-3.0 claim is raised against a codebase, the first mistake is to treat "the deadline" as a single date. In a multi-tool environment there are at least three families of time-bound obligations, and each is written by a different party with a different purpose.

The first is the licence itself. GPL-3.0 section 8 deals with termination of rights and with the conditions under which a licensee can cure a violation and have rights reinstated. It is the only family prescribed by the licence text, and it attaches to the party that is the licensee of the covered code. The specific periods and triggers should be read directly from the clause rather than from summaries.

The second is vendor terms. Each AI coding tool vendor publishes its own terms, and some offer indemnity or similar programmes for intellectual property or open-source claims. These instruments can include conditions on how and when the customer notifies the vendor, how the customer cooperates, and who controls the defence. They differ by vendor, by plan and by effective date, so the version in force when the code was generated matters.

The third is contractual. Customer agreements and insurance policies may require notice of a claim within a stated period, and may require cooperation with the counterparty or insurer. These are internal to the enterprise and are often tracked by different teams than the ones who manage developer tooling.

What each family is typically triggered by

The table summarises the category of trigger to look for in each instrument. It is a framework for reading the documents, not a statement of what any particular document says.

• GPL-3.0 section 8: Triggers are defined in the clause and tie to events such as a violation, receipt of notice and the end of the violation. Confirm the periods and who may give notice. Owner: legal and open-source compliance.
• AI coding tool vendor terms and indemnity programmes: Triggers often tie to the customer becoming aware of a claim or receiving a demand. Confirm notice format, cooperation duties, control-of-defense conditions and any eligibility conditions. Owner: procurement and legal.
• Customer contracts: Triggers tie to notice of a claim, an infringement allegation or a change in the licence status of delivered software. Confirm the notice period and recipient. Owner: contract management.
• Insurance policies: Triggers tie to when a claim is made or first known, and often to cooperation conditions. Confirm reporting windows. Owner: risk and legal.

Why the multi-tool case is an attribution problem

Every row above depends on a prior question: which code is disputed, and where did it come from? If a repository contains output from three assistants, plus human-written and third-party code, the enterprise has to attribute each disputed segment before it can say which vendor's terms are relevant, which licence context applied, and whether a section 8 analysis even concerns the code in question.

The date of awareness is the other fixed point. Several triggers turn on when the enterprise knew or was notified, but the instruments may define that differently. Recording the date and the channel through which the claim arrived, and who received it, lets counsel test each trigger against the actual wording.

Vendors are an unreliable source for attribution. An FTC comment to the Copyright Office reports that participants are often unable to tell whether their work was included in AI training, in part because many AI model developers have chosen not to disclose what is in their training data. By extension, an enterprise should not expect a vendor to reconstruct the origin of a particular output after the fact. The enterprise's own records, made when the code was generated, are the more dependable basis for attribution.

Recording origin and licence evidence at the point of generation

The minimum an enterprise should be able to produce for any disputed segment is the originating tool, the licence context that applied when it was produced, and a timestamp. Reconstructing these from commit history or developer recollection is slow and rarely conclusive, particularly when several assistants touch the same files. Records made at generation time avoid that problem, because they exist independently of the dispute.

This is where runtime enforcement becomes relevant. Trussed provides code provenance covering the origin, licence and security context of code, and enforces policy in the execution path of coding assistants. Policy can allow, redact, block or escalate an interaction for human approval, and it is enforced at runtime, not reviewed after the fact. Enforcement produces audit-ready evidence, so the enterprise can identify affected code and document its response. Trussed does not determine which deadlines apply or whether a clause has been satisfied. That remains a question for counsel reading the specific agreements.

The practical value is narrower than it might sound, and it is worth stating plainly. Evidence does not extend or shorten any period. It reduces the time spent establishing facts, which leaves more of the available time for the decisions that count: notifying the right party, in the right form, with a documented record of cooperation.

Tradeoffs and where counsel review decides the outcome

A deadline map is only as accurate as its reading of the instruments. Vendor terms change, programmes carry eligibility conditions, and a clause that appears to set a period may be qualified elsewhere in the agreement. Customer contracts and insurance policies are negotiated individually and vary widely. For these reasons, outcomes depend on counsel review of the specific licences, vendor agreements, customer contracts and policies, and nothing here should be read as a statement of what any of them requires.

There is also an operational tradeoff. Capturing origin and licence context at generation adds a control point in developer workflows, and policy that blocks or escalates will occasionally interrupt work. Teams should decide which licence contexts warrant a block, which warrant human approval, and which can simply be allowed with evidence recorded. Setting those thresholds before a claim is easier than defending the absence of any threshold after one.

For compliance leaders, a useful test is whether, within a day of receiving a claim, the team can name the tools involved, the instruments that apply, the owner of each notice duty and the date awareness began. If any of those require investigation, that gap is where to start.