Gemini Code Assist vs Tabnine vs Windsurf vs JetBrains AI: Copyleft Coverage and Gaps Compared

Why copyleft risk needs a consistent comparison

Copyleft licenses such as GPL and AGPL attach conditions to code that is incorporated into other software. If an assistant reproduces copyleft-licensed material in a proprietary codebase, those conditions can become a question for the organization that ships the code. The exact obligations depend on the license, its version, and how the resulting software is used or distributed, so legal counsel should own that interpretation. Security engineers still need to supply the technical facts counsel will ask for.

The four assistants in this comparison are built by different vendors, and vendors differ in how they describe training data, whether they detect or cite public-code matches, whether filtering is configurable, what indemnification they offer, and which controls an administrator can enforce. Comparing them feature by feature produces lists that look similar and mean different things. A fixed set of criteria, applied identically to each tool, makes the differences visible and keeps the review defensible.

The point of the exercise is to separate what a vendor documents and contractually commits to from what your organization assumes. Where a vendor's documentation is silent on a criterion, record it as not documented. Do not fill the gap with an assumption that the capability exists.

The five criteria and the residual gap behind each

Use the same five rows for Gemini Code Assist, Tabnine, Windsurf and JetBrains AI. For each row, record the vendor's current documented position, the plan tier it applies to, and any stated exclusions. The right-hand description in each item is the gap that typically remains even when the vendor answer is favorable.

• Training-data licensing posture: Establish what the vendor states about the licensing basis of its training data. Residual gap: a statement about training data does not guarantee that any individual suggestion is free of copyleft-licensed material.
• Public-code matching and citation: Establish whether the tool compares output with public code and whether it surfaces the source and license of a match. Residual gap: matching is bounded by the vendor's reference corpus and thresholds, and code from private or unindexed origins is outside it.
• Configurable filtering: Establish whether matched output can be suppressed, and whether that setting can be locked by an administrator or left to the developer. Residual gap: a filter that the individual can disable is a preference, not a control.
• Indemnification scope and conditions: Establish which plans are covered, which settings must be enabled, and what the terms exclude. Residual gap: indemnification addresses the allocation of loss after a claim. It does not tell you what code you hold or which license it carries.
• Enterprise admin controls: Establish which policies can be enforced organization-wide and which records the admin can export. Residual gap: vendor admin settings cover that vendor's tool only, so a multi-assistant estate has several policy surfaces and no common record.

Reading vendor coverage without over-reading it

Three distinctions prevent most misreadings. First, mitigation is not elimination. Matching and filtering reduce the chance that identifiable public code reaches a developer, but they work on similarity to known material. Code that was adapted, partially reproduced, or pulled in through a dependency suggestion may not trigger a match, and a match that is shown as a citation still needs someone to act on it.

Second, a contractual protection is conditional. Indemnification terms commonly depend on plan tier, on required settings being enabled, and on the customer using the tool as intended. Read the conditions as configuration requirements for your environment. If the protection assumes a filter is on, then confirming that the filter is enforced across every seat is part of keeping the protection in force.

Third, a feature in documentation is not evidence in your audit file. Even where a vendor offers citation or admin reporting, that data lives in the vendor's product, in the vendor's format, for the vendor's retention period. An auditor asking how your organization controlled copyleft exposure will expect your own records of what was generated, what was checked, and what was done about it.

Where vendor-side coverage ends

The boundary is easiest to see by following a single suggestion. The vendor's responsibilities cover the model, its training, and any matching or filtering applied before the suggestion appears. From that point the code enters your environment: it is accepted by a developer, edited, committed, and merged. Nothing that the vendor does at suggestion time can describe what happens afterward, and nothing in a single vendor's tool can compare its behavior with the other assistants your teams also use.

That leaves a set of questions your organization has to be able to answer independently of any vendor. Which assistant produced this code, and when? What was its origin, and under which license? Was a match detected, and what was the decision? Was the policy that applied at the time consistent across teams and tools? Without these records, a favorable vendor position is a statement about the vendor, not a demonstration about your codebase.

A practical consequence is that comparing the four tools should not end in a single winner on copyleft grounds. It should end in a documented baseline for each tool and a list of the conditions your own controls must satisfy regardless of which tool a team chooses.

Provenance enforced in the execution path

Review after the fact has a structural weakness for this risk: by the time a license question is raised, the code may already be merged and built upon. Enforcing a check when the code is generated or when a tool call is made moves the decision to the point where it is cheapest to act on, and it produces a record as a by-product of the decision itself.

This is the role Trussed fills as a complementary control. Trussed enforces policy in the execution path across coding assistants, and its code provenance capability supplies the origin, license and security context of code. Policy outcomes such as allow, redact, block, or escalate for human approval are enforced at runtime, not reviewed after the fact, and the enforcement generates audit-ready evidence. Because the control sits in the path and not inside one vendor's tool, the same policy and the same evidence format apply to each assistant. The scope is individual interactions and tool calls. Trussed can be self-managed in your cloud, with configurable retention and data residency.

This does not replace vendor mitigations or indemnification. The two layers answer different questions: the vendor layer reduces what is likely to be produced and defines contractual protection, and the enterprise layer shows what actually happened in your environment.