Software export controls

The application of US export control regulations, principally the Export Administration Regulations (EAR, 15 CFR 730-774), to software source code, object code, and related technical data, addressing three issues distinct from general item/equipment export control: (1) whether the software qualifies as 'published' and therefore outside EAR jurisdiction under 15 CFR 734.7 (or fundamental-research-excluded under 734.8), based on whether it was released without restriction on further dissemination; (2) whether the software has cryptographic functionality subject to the separate Category 5 Part 2 encryption controls (ECCNs 5A002/5D002/5E002) and associated License Exception ENC or self-classification requirements; and (3) whether granting a foreign national visual, electronic, or repository access to controlled, non-published source code constitutes a deemed export under 15 CFR 734.13, independent of whether any file is physically transmitted abroad.

ByCASRAI Editorial Board

· Last updated 18 Jul 2026

Worked examples

Is an instance

A university lab posts the source code for a research software tool to a public GitHub repository with no access restrictions and no separate encryption functionality, as part of an open-science data-sharing plan. Because the code is unrestricted and publicly accessible at no more than the cost of reproduction, it qualifies as 'published' under 15 CFR 734.7 and is not subject to the EAR, regardless of who subsequently downloads or views it.

Is an instance

A cybersecurity research group develops software that implements a novel encryption algorithm and keeps the repository access-restricted to lab members while a related paper is under review. Because the code is not yet published and provides cryptographic functionality, it is evaluated under Category 5 Part 2 (ECCN 5D002) independent of its other technical characteristics, and a foreign national postdoc on the team is granted repository access only after the export control office confirms a deemed-export license exception applies or a Technology Control Plan is in place.

Looks similar, but isn't

Not an instance

A lab assumes that because its non-encryption research software will eventually be published in an open-access repository, no export control analysis is needed for foreign national access to the private development repository in the meantime. Restricted-access code is not yet 'published' under 734.7, and access by a foreign national before public release can still be a deemed export, independent of the team's eventual publication intent.

Not an instance

An institution treats encryption source code the same as any other software for EAR purposes because it plans to publish it. Encryption software carries an additional, separate notification requirement to BIS and the NSA under 15 CFR 742.15(b) before the publicly-available exemption applies -- publication intent alone does not satisfy it.

Software export controls are the subset of US export-control rules (chiefly the Export Administration Regulations, EAR, 15 CFR Parts 730-774) that apply specifically to source code, object code, and technical data for software, as distinct from the physical equipment or general technical data covered by the same regulatory scheme. Software raises issues equipment does not: it can be transmitted electronically in seconds, it can be posted publicly online in a way that changes its regulatory status, and simply letting someone view or work with controlled code can itself be a controlled event even with no file ever leaving the country. Research institutions that write, distribute, or give foreign nationals access to research software need a classification and access analysis that goes beyond the general ECCN determination process and Technology Control Plan used for equipment.

The publicly available / open-source exemption

Under 15 CFR 734.7, software (like technology) that has been made available to the public without restriction on further dissemination — through unrestricted publication, a library or public collection, an unrestricted conference release, or posting on the internet where any member of the public can access it at no more than the cost of reproduction — is considered published and is not subject to the EAR at all. BIS’s 2015 rule clarified that posting source code publicly online, including on a public GitHub-style repository with no access or dissemination restrictions, qualifies as publishing it. Separately, 15 CFR 734.8 excludes software that arises during, or results from, fundamental research and is intended for publication, from EAR jurisdiction.

Encryption source code gets its own, narrower exemption: under 15 CFR 742.15(b), publicly available encryption source code classified under ECCN 5D002 is not subject to the EAR, even if it is distributed subject to a licensing fee for commercial products built from it — but the exporter must still email a notification (and, for some categories, the source code or an internet location for it) to BIS and the NSA before or upon posting. This distinguishes true public-release encryption code from encryption code that merely happens to sit in an internal, access-restricted repository: restricting who can pull the repository defeats the exemption, because the code is then no longer "published" under 734.7.

Encryption-specific controls: EAR Category 5, Part 2

Software that provides or uses cryptographic functionality is separately controlled under Commerce Control List Category 5, Part 2 (information security) — encryption hardware falls under ECCN 5A002, encryption software under 5D002, and related encryption technology under 5E002 — layered on top of whatever ECCN the software would otherwise receive for its non-cryptographic function. Most commercial and open-source encryption software qualifies for License Exception ENC or mass-market treatment (self-classified against parameters in 15 CFR 742.15 / Supplement No. 6 to Part 774, sometimes requiring a one-time self-classification report or classification request to BIS rather than a full license), but a research team building or modifying cryptographic code cannot assume this automatically — exactly the scenario the ECCN determination process exists to resolve, and practitioner guidance commonly flags encryption items as a case where a formal BIS Commodity Classification is worth requesting rather than relying on self-classification alone.

Deemed exports via source code access

The general deemed export rule — that releasing controlled technology or technical data to a foreign national inside the United States is treated as an export to that person’s country of citizenship — applies to software with a specific wrinkle: for source code, the "release" can happen through visual or electronic access alone. A foreign national researcher who is granted read or write access to a controlled private code repository, allowed to view controlled source on a screen, or included in a design discussion about how a controlled algorithm works has received a deemed export of that technology, whether or not any file is copied, emailed, or physically leaves the building. This makes source-code access control — who has repository permissions, who is in the room during a code review, whether a shared development server segregates controlled and non-controlled branches — a first-order compliance question for any lab running EAR-controlled software with a mixed-nationality team, and it is exactly the kind of access risk a project-specific Technology Control Plan is built to manage once a classification analysis confirms the code is genuinely controlled and not published or fundamental-research-excluded.

Practical sequence for research software

Classify first. Determine whether the software is subject to the EAR at all (is it published, or does it arise from fundamental research intended for open publication?) before asking which ECCN applies — 734.7 and 734.8 can remove software from EAR jurisdiction entirely, which is a different and prior question to classification against the Commerce Control List.
Check for encryption functionality separately. Cryptographic capability triggers Category 5 Part 2 analysis independent of the software’s primary function, and self-classification for encryption items carries more compliance risk than most CCL categories.
Decide the publication path deliberately. If the intent is genuinely open release, publishing the source code without access restriction (a public repository, a journal’s code-availability requirement, an unrestricted preprint archive) can trigger the 734.7 published exemption — but restricting a repository to "collaborators only" or a private lab server does not, and keeps the code inside EAR jurisdiction with deemed-export exposure for any foreign-national collaborator.
If it is controlled and not fully published, control access, not just storage. A Technology Control Plan needs to name who may view or modify the repository, not only who may copy files off it.

References

15 CFR 734.7 (Published) and 15 CFR 734.8 (Fundamental research), Export Administration Regulations, Bureau of Industry and Security, US Department of Commerce.
15 CFR 742.15(b), Encryption items — publicly available encryption source code notification requirement.
15 CFR 774, Supplement No. 1, Category 5 Part 2 (Information Security): ECCNs 5A002, 5D002, 5E002.
15 CFR 734.13, Deemed export / deemed reexport.
BIS, “Encryption FAQs” and “Encryption Items Not Subject to the EAR,” bis.gov/learn-support/encryption-controls.

Use in your systems

JATS XML <role> element

xml

<role vocab="credit"
      vocab-identifier="https://casrai.org/dictionary/"
      vocab-term="Software export controls"
      vocab-term-identifier="https://casrai.org/dictionary/term/software-export-controls" />

Schema.org DefinedTerm (JSON-LD)

json

{
  "@context": "https://schema.org",
  "@type": "DefinedTerm",
  "@id": "https://casrai.org/dictionary/term/software-export-controls",
  "name": "Software export controls",
  "identifier": "https://casrai.org/dictionary/term/software-export-controls",
  "description": "The application of US export control regulations, principally the Export Administration Regulations (EAR, 15 CFR 730-774), to software source code, object code, and related technical data, addressing three issues distinct from general item/equipment export control: (1) whether the software qualifies as 'published' and therefore outside EAR jurisdiction under 15 CFR 734.7 (or fundamental-research-excluded under 734.8), based on whether it was released without restriction on further dissemination; (2) whether the software has cryptographic functionality subject to the separate Category 5 Part 2 encryption controls (ECCNs 5A002/5D002/5E002) and associated License Exception ENC or self-classification requirements; and (3) whether granting a foreign national visual, electronic, or repository access to controlled, non-published source code constitutes a deemed export under 15 CFR 734.13, independent of whether any file is physically transmitted abroad.",
  "inDefinedTermSet": "https://casrai.org/dictionary/domain/research-security#set",
  "url": "https://casrai.org/dictionary/term/software-export-controls",
  "sameAs": [],
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "publisher": {
    "@id": "https://casrai.org/#organization"
  },
  "dateModified": "2026-07-18T03:03:59",
  "inLanguage": "en"
}