Proprietary source code licenses for AI training: trade-secret and regurgitation terms

This page covers contract clauses only. To scope and buy the data itself, see licensing source code for AI training and proprietary code datasets with full Git history. For the wider rights framework, start at the AI training data licensing hub.

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

Why trade-secret status drives the confidentiality clause

Confidentiality terms decide whether a licensed repository keeps its trade-secret status once it leaves the owner's control. Under the federal Defend Trade Secrets Act definition, information is a trade secret only if the owner takes reasonable measures to keep it secret and it derives value from not being generally known [1]. A license that lets a buyer copy code into broadly accessible buckets, share it with contractors without obligations, or ship a model that reproduces it verbatim weakens the licensor's argument that reasonable measures existed. Expect counsel on the supply side to push hard here, and treat that as a sign of a real asset, not obstruction.

Negotiate the confidentiality section around how training actually works:

• Defined "Licensed Code" that covers the repositories, Git history, issues, review comments and any derived artifacts (tokenized shards, embeddings, deduplicated subsets), so confidentiality follows the data through the pipeline.
• Need-to-know access limited to named teams, with processors such as cloud training providers bound by written terms at least as strict. The processor and API terms page covers fine-tuning on hosted models.
• Storage controls stated as outcomes: encrypted at rest, access logged, no public or cross-tenant buckets, no copies in shared notebooks.
• Model weights carve-out. Licensors sometimes argue weights are a derivative of their secrets. Agree explicitly whether weights are "Confidential Information" and, if not, what output-side controls replace that protection.
• Survival. Confidentiality usually survives termination; pair it with a clear position on retained copies and trained models, discussed in derivative and successor model rights.

Regulators add their own confidentiality layer. The EU AI Act binds market surveillance authorities and notified bodies to protect trade secrets and confidential business information, explicitly including source code [12]. California's AB 2013 training-data disclosures, required since 1 January 2026 for generative AI systems offered to Californians, call for a high-level summary of training datasets, and commentators flag a direct tension with keeping dataset details secret [13]. Draft the license so the buyer may make legally required disclosures, and agree in advance the most general description of the licensed code and its source that counsel considers compliant.

Who removes secrets, and what "removed" means

The license should make credential removal a named obligation with a verification standard, because secrets in Git history survive a simple HEAD cleanup. A key deleted in a later commit still sits in every earlier tree, every packfile and every bundle cut from the full history. Language models memorize training sequences that an adversary can extract by querying the model [2], and code models in particular reproduce memorized fragments of their training code, including sensitive strings [3].

Pattern-based scanners help but are incomplete. GitHub's secret scanning distinguishes provider-specific patterns from generic ones such as private keys and database connection strings, and coverage differs by product version [4]. Research on enterprise secret detection reports that hard-coded credentials are common and that pattern rules alone miss a meaningful share, which is why entropy checks and ML classifiers are layered on top [5]. The secrets removal guide for code datasets walks through full-history scanning and verification.

Contract points to settle:

1. Responsibility. The licensor scans before transfer; the buyer re-scans on receipt. Neither scan alone is enough.
2. Scope. All refs, tags, stashes, LFS objects, CI configuration, .env samples, notebooks and issue or review text, not only the default branch.
3. Method record. Tools and versions used (for example Gitleaks, TruffleHog or GitHub secret scanning), rule sets, and how findings were handled: history rewrite, token replacement or file exclusion.
4. Rotation. The licensor rotates any live credential found, because redaction in a copy does not revoke a key that already left the building.
5. Late discovery. If the buyer finds a secret after delivery, it notifies the licensor within an agreed window, quarantines affected shards and receives a corrected delivery. State whether models already trained on the affected shard must be retrained or only filtered.

Personal data needs a parallel clause. Commit author names and emails, customer identifiers in fixtures and log samples are personal data in many jurisdictions; decide whether author identities are pseudonymized and whether that breaks blame-based features you need.

Separating first-party code from third-party and open-source files

A licensor can grant rights only in code it owns, so the license should exclude or separately govern every third-party file inside the repositories. Proprietary monorepos routinely contain vendored libraries, copied Stack Overflow snippets, generated clients, forks of GPL or AGPL projects and code received from contractors under their own terms. The licensor's training grant does not cure any of those inbound obligations.

Ask for a dependency and license inventory as a delivery item. ScanCode's LicenseDB curates more than 2,000 license texts with identifiers used in automated detection [8], and BigCode's open datasets show the established pattern of repository-level license detection, filtering and near-deduplication before training [6][7]. Open dataset metadata is often unreliable: one large audit found license omission above 70% and error rates above 50% on popular hosting sites [9], so do not assume vendored files carry accurate headers. The open data license compatibility matrix helps triage what remains.

Useful clauses here:

• Ownership representation limited to "Licensor-Authored Code," with a schedule of excluded paths (vendor/, third_party/, node_modules/, generated directories).
• Contractor and employee assignment confirmation for code written by non-employees, since an unassigned contractor contribution is not the licensor's to license.
• Inbound license flags for copyleft files the scan finds, with the option to remove or to keep under a documented decision.
• Warranty and remedy tied to the inventory, discussed further in data warranties for AI training licenses.

Regurgitation limits and output-similarity filtering

A regurgitation clause turns "the model must not leak our code" into a testable output standard with a defined measurement method. Absolute bans on reproduction are unworkable, because short idioms, boilerplate and API call sequences recur everywhere. The negotiable question is what length and type of verbatim match counts as a breach and what the buyer must run to prevent it.

Elements that make the clause enforceable:

• Threshold. A minimum contiguous match, measured in tokens or normalized lines after whitespace and comment stripping, above which output counts as reproduction. Exclude matches that also appear in a public reference corpus.
• Filter obligation. The buyer runs an output-side similarity filter against an index of the licensed code (exact n-gram or suffix-array matching, often with MinHash for near-duplicates) on any externally served product.
• Distinctive-string canaries. Licensors may plant canary strings or ask for extraction testing using prompts seeded with real file prefixes, mirroring published extraction methods [2][3].
• Internal identifiers. Hostnames, internal service names, package namespaces and ticket prefixes reveal architecture even when no line is copied. List them for blocklist filtering.
• Training-side mitigations. Deduplicating repeated files and limiting epochs over the licensed set reduce memorization; record what was done rather than promising an outcome.
• Reporting and audit. Periodic filter hit rates and incident reports, linked to audit and usage-reporting rights.

Private code also has an evaluation benefit. Benchmarks drawn from public repositories risk contamination because permissively licensed code is likely already in pretraining corpora, which is why SWE-Bench Pro keeps part of its tasks on private code [10]. If you plan to hold out licensed repositories for evaluation, write that into the field of use and keep the held-out set out of every training mix.

Term sheet for a proprietary code training license

The table below sets out common opening positions on each side as a starting point for redlines; actual positions vary by deal.

Illustrative example: invented to show structure; it does not describe an available dataset.

A manifest record that ties these clauses to the delivery might look like this:

Illustrative example: invented to show structure; it does not describe an available dataset.

repository: payments-core
history: full (bundle, 41,200 commits, 2014-2025)
excluded_paths: [vendor/, third_party/, gen/]
license_inventory: inventory/payments-core.spdx.json
secrets_scan:
  tools: [gitleaks 8.x, trufflehog 3.x]
  scope: all refs, tags, LFS
  findings: 37 (rotated: 37; history rewritten)
author_identity: pseudonymized (stable hash)
internal_identifiers_blocklist: blocklists/payments-core.txt

Regulatory hooks that touch code license terms

Code licenses should anticipate disclosure duties that apply to the model provider rather than the licensor. In the EU, providers of general-purpose AI models have since 2 August 2025 had to maintain a copyright compliance policy and publish a summary of training content, and as of October 2026 the AI Office's enforcement powers apply to new models [11]. The license should let the buyer list the licensed code at the category level in that summary without breaching confidentiality.

In the US, the FTC has warned model-as-a-service companies that breaking promises not to train on customer data can be unfair or deceptive [14]. If the licensor is itself a software vendor, ask it to confirm the code was not collected from its customers under terms that forbid training. The trade secret law overview explains the misappropriation theories behind these clauses.

How SourceX handles proprietary code requests

SourceX sources operational datasets, including engineering records, from US companies on request and manages the commercial process from finding a supplier through licensing and ongoing purchases. Nothing is held in stock, and a request does not guarantee a match. Every release is approved by the supplying company, and each dataset is rights-reviewed for ownership and consents before it is delivered under a license that defines records, uses, term and delivery.

The process runs Find, Assess (data and licensing permissions), Agree (pricing and allowed uses in a license), Transact and Manage, and nothing is contracted until a supplier agrees. Diligence materials covering source, rights, preparation and allowed use are prepared per dataset, and personal details such as names and emails are removed or replaced, with the method recorded and a sample checked; no method is perfect. Delivery runs through private, access-controlled workflows only after an executed agreement. Describe the code you need on the buyer request page.

Request licensed proprietary code for your code model

If your team needs proprietary repositories with history for code models or coding agents, describe the languages, domains and allowed uses you need rather than specific companies. SourceX looks for US businesses that hold matching data and agrees pricing and allowed uses with each supplier in a license. Start a buyer request.