Export Controls on Source Code for AI Training: What Non-US Buyers Should Check

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

Which US export regimes can reach a licensed codebase?

Two regimes matter for code: the Export Administration Regulations (EAR, 15 CFR 730-774) administered by Commerce, and the International Traffic in Arms Regulations (ITAR, 22 CFR 120-130) administered by State. The EAR covers commercial and dual-use items, and it treats "software" and "technology," including source code, as items that can be exported by electronic transmission, not just by shipment [1]. The ITAR covers defense articles, technical data and defense services, and its technical-data definition reaches information required for the design, development, production, operation or maintenance of defense articles [4].

Classification is the supplier's job, done with its counsel. The buyer's job is to ask for the result, check that the result is plausible for what is in the repository, and give the supplier truthful destination, end-user and end-use information. A clean classification for the application tier says nothing about the vendored crypto library or the firmware directory sitting in the same monorepo.

For engineering records beyond code, such as CAD files, test reports and CNC programs, see the companion guide on export-controlled technical data in AI training sets.

Why encryption functionality is the most common trigger in commercial code

Encryption is the trigger most likely to appear in ordinary enterprise code, because TLS handling, key management, custom cipher implementations and VPN or secure-messaging features are common in SaaS and device codebases. As of October 2026, encryption source code is typically classified under ECCN 5D002 in Category 5, Part 2 of the Commerce Control List; whether any mass-market or other release applies to source code is a question to confirm against the current Category 5, Part 2 text with counsel. Many 5D002 items can be exported under License Exception ENC (15 CFR 740.17), and non-public encryption source code generally falls in the ENC tier that carries its own classification and reporting conditions.

Publicly available encryption source code is treated differently from proprietary code. The EAR excludes published and publicly available information and software from its scope through 15 CFR 734.3(b)(3) and 734.7 [1]. For encryption, 15 CFR 742.15(b) adds a condition: since BIS's 2021 encryption rule, publicly available source code implementing "non-standard cryptography" falls outside the EAR only once a notification is sent to BIS, so the supplier's counsel should confirm that step for any open-source crypto that ships inside the corpus.

The practical gap for buyers: a private repository that calls OpenSSL is different from a private repository that contains a proprietary cipher or a modified crypto module. The first is often low-risk because the library is publicly available and the calling code may not itself implement encryption. The second is unpublished encryption source code, and its classification and any ENC conditions must be settled before release.

ITAR code is usually out of scope for commercial AI licensing

Code that is a defense article, or that is technical data for one, generally needs State Department authorization before release to foreign persons, and most commercial AI-data deals are not structured for that. ITAR separately defines software and technical data, so code for guidance, targeting, fire control, military avionics or satellite payloads may fall inside the US Munitions List even when it looks like ordinary C++ [4]. Commentary also warns that training or integration assistance tied to defense articles can itself be a defense service [5].

Expect suppliers with any defense business to carve those repositories out entirely rather than try to clear them. Ask in writing whether any delivered repository, branch or historical commit came from a program with USML or 600-series (EAR military) items, because git history can preserve files that were later moved to a segregated system.

How deemed exports affect your staff, contractors and labeling vendors

Releasing controlled source code to a foreign person inside the United States can itself be an export. BIS treats the release as a deemed export to that person's most recent country of citizenship or permanent residency, under 15 CFR 734.13(b), with "release" defined in 734.15 [2][1]. That means a US-based annotation contractor or a visiting researcher can trigger the same analysis as a transfer abroad.

For buyers, the consequence runs through the whole data pipeline. If a supplier classifies part of a corpus above EAR99, your access-control plan should cover who can open the raw files: storage location, nationality-based access groups, and any downstream labeling or evaluation vendor. Many suppliers simply exclude controlled code so that no deemed-export plan is needed. Note also that the EAR lists certain activities that are not exports at all, including some transfers of properly encrypted technology or software, in 15 CFR 734.18; whether a given cloud or transfer setup qualifies is a question for counsel, not an assumption [3].

What screening to expect before code crosses a border

Expect three screens: destination, parties and end use. Destination screening checks the country against EAR country groups and embargo rules in 15 CFR Part 746. Party screening runs your legal entity, parent, affiliates, named end users and sometimes key personnel against restricted-party lists; the Commerce Department's Consolidated Screening List combines Commerce, State and Treasury lists into one search, and a possible match usually triggers further due diligence rather than automatic refusal. End-use screening asks what the code will train and whether any prohibited end use under 15 CFR Part 744, such as military-end-use or weapons-related activity, is involved.

Suppliers may ask for a signed end-use statement, an ownership chart and confirmation that no listed party has access to the data. Supply these early: an incomplete answer is a frequent reason deals stall after commercial terms are agreed.

Buyer-side export review checklist

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

How to verify exclusions recorded in a code delivery

A supplier that excludes controlled components should give you a machine-readable exclusion manifest, not a sentence in an email. The manifest lets your team confirm that nothing excluded reappears through forks, vendored copies or old commits, and it gives counsel a record of what was screened. Treat it the same way you treat a secrets-scan report (see secrets removal in code datasets).

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

{
  "delivery_id": "dlv-example-0001",
  "repository": "payments-platform",
  "classification_summary": { "default": "EAR99", "reviewed_by": "supplier counsel", "review_date": "2026-09-30" },
  "excluded": [
    { "path": "libs/fastcrypt/", "reason": "proprietary cipher implementation; ECCN 5D002 under review", "history_purged": true },
    { "path": "firmware/hsm-bridge/", "reason": "key management module; excluded pending classification", "history_purged": true }
  ],
  "retained_third_party_crypto": [ { "package": "openssl", "status": "publicly available, unmodified" } ],
  "verification": { "method": "path and SHA-256 hash scan of all commits", "sample_checked": true }
}

Two failure modes recur. First, an excluded directory is removed from HEAD but survives in earlier commits, so the delivered git history still contains it. Second, the same code is vendored under a different path, so a path-based exclusion misses it; hash-based or near-duplicate matching catches more (see deduplicating code training data).

Contract terms that carry the export analysis

The license should record what was classified, what was excluded, and what you may and may not do with the data afterward. Useful provisions include a representation that you are not a restricted party, an end-use covenant, a re-export clause covering moves to other countries or cloud regions, and a notice obligation if your ownership changes. Pair these with the trade-secret and regurgitation terms covered in source code license terms for AI training and with code ownership due diligence.

For broader context on how export controls interact with data licensing, see the SourceX note on data licensing and export controls. If you are scoping the request itself, the code dataset request specification guide shows how to state languages, history depth and exclusions up front.

How SourceX handles cross-border code requests

SourceX serves AI teams wherever they are based and sources operational datasets, including engineering records, from US companies on request. Every dataset is rights-reviewed for ownership and consents and delivered under a license that defines records, uses, term and delivery. Every release is approved by the supplying company, nothing is contracted until a supplier agrees, and delivery runs through private, access-controlled workflows only after an executed agreement. You can describe the code you need on the SourceX buyer page; a request does not guarantee a match. See also proprietary codebases with full git history and licensing source code for AI training, or start from the code data hub and the AI data buyer hub.

Request source code data for AI training

SourceX prepares diligence materials per dataset covering source, rights, preparation and allowed use, and works through Find, Assess, Agree, Transact and Manage with the supplier. Pricing and allowed uses are agreed per deal in a license. Describe your code data needs, destination and intended use at sourcex.si/buyers.