Key Points
- This is a US/EU-focused primer. Shipping software across borders — by publishing on GitHub, collaborating with people abroad, or making controlled technology or source accessible to non-residents — can put you inside an export-control regime, even when "my code isn't a weapon" feels obvious. The question is not "is the server overseas?" but "who can now obtain or use the controlled technology?" Most public open-source release lands in a publicly-available exemption, so the real first task is sorting out whether the rules reach you at all.
- Who this is for: solo and side-project developers shipping public repos (the main audience), plus engineers and compliance staff at companies building in or for the US or EU. No prior legal knowledge needed.
- What you get: why ordinary software can be in scope (dual-use logic + software treated as an export in its own right — including, inside the US, as a "deemed export") + a five-category screen plus the triggers that actually matter + the minimum you need on the major regimes (US EAR / ITAR, EU Dual-Use, Wassenaar) + a self-diagnosis checklist to run before you cross a border.
- Out of scope (consult an export-control specialist): confirming a specific classification, filing for a license, sanctions / denied-party screening details, and cross-border personal-data transfer (GDPR / national privacy law — a separate regime, not export control).
この記事の要点(日本語版はこちら)
- 本記事は 米国・EU 法を背骨にした「国際版」 です(日本語版の翻訳ではなく、対象法域が異なる対の記事)。米 EAR / ITAR・EU Dual-Use 規則・Wassenaar を軸に、暗号や AI を含むソフトを国境を越えて出すときに輸出管理が「自分に効くか」を切り分けます。
- 日本法(外為法・該非判定・公知技術例外)を主役にした解説は 日本語版 を参照してください。
Written: 2026-06 / Jurisdiction focus: United States & EU (Japan and China are covered briefly, with detail in the Japanese edition) / last_updated: 2026-06-04 Changelog: 2026-06-04 first published as an international (US/EU) edition
This article is educational material, not legal advice
Export control turns on the exact item, destination, end-use, and end-user, and violations carry criminal penalties (prison time and fines for individuals; export-privilege denial for companies). This article is an educational overview of US and EU rules; it does not determine whether any specific act is lawful, and it is not a substitute for advice on your own facts. Out of scope: confirming a specific classification / advising whether a license is required or filing one / sanctions and denied-party screening details / cross-border personal-data transfer. For real decisions, consult the US Bureau of Industry and Security (BIS), a national export-control authority, your trade-compliance department, or a qualified export-control attorney. All information is provided "AS IS," without warranty of any kind as to accuracy, completeness, or currency. To the maximum extent permitted by law, the author and YATA-NODE accept no liability for any loss or damage arising from the use of or reliance on this article. Use it at your own risk. The law is amended over time, so always confirm the current version at the time you rely on it.
About this series: part of YATA-NODE's "rights basics" series. The hub is the pre-ship rights checklist; related pieces are the legal boundaries of scraping (the line a fetcher must honor when reaching foreign sites) and how to read OSS licenses (vetting the crypto and AI dependencies you bundle). Each piece stands on its own — no need to read them in order.
A few terms (for newcomers):
- Classification: checking whether the software or technology you are shipping is listed (controlled) or not listed under the rules. It is the entry point to all of export control.
- Dual-use: technology usable for both civilian and military ends — cryptography, AI, semiconductor design, and the like. It is the heart of what export control covers.
- Export of software / "intangible" transfer: alongside shipping a physical good, sending software, source code, or technology across a border by electronic means is itself an export — by email attachment, a push to an overseas repo, or an overseas deployment. A related but distinct concept is a "deemed export": under US rules, releasing technology or source code to a foreign person inside the United States (for example, giving a foreign employee access) counts as an export to that person's home country (EAR §734.13). The throughline: handing over a USB stick is not the only way to "export."
- Publicly available exemption: a carve-out under which technology already released to the public is outside the controls. Most open-source release lands here — but only when it is genuinely available to anyone (private / gated / specific-recipient release does not qualify).
- Catch-all (end-use / end-user) controls: even an item that is not on a list can require a license when there is a weapons-of-mass-destruction (WMD) or similar concern.
"Will my software get caught by export control, and is shipping it legal?" — the answer depends on jurisdiction, and on a screen you can run yourself today. Building in or for Japan? The Japanese edition covers Japanese law (FEFTA, the classification process, and the same screen) under that jurisdiction.
Why software you think is "none of your concern" can still be in scope
The technology to build a refrigerator is hard to repurpose for war. But cryptography, AI, quantum computing, semiconductor design, and intrusion software serve civilian and military ends. That is dual-use, and export control exists to let such items circulate for civilian use while keeping a state's hand on the items whose military diversion would threaten national security. The structure has three layers: multilateral regimes agree a common list, but the regimes themselves carry no direct legal force — each takes effect only once a country writes it into national law. In the US that national layer is mainly the EAR (Export Administration Regulations); in the EU it is the Dual-Use Regulation.
The piece individual developers most often miss is that software is treated as an export in its own right, not only as a physical good. US law treats an electronic transfer of technology or source code across a border as an export in its own right, and separately captures the release of technology or source code to a foreign person inside the US as a "deemed export" (EAR §734.13); EU law likewise reaches "transfers of software and technology" by electronic means. In practice, all of the following can fall inside that reach:
- Sending source code as an email attachment, pushing to an overseas repository, or deploying to an overseas data center — these are exports (cross-border electronic transfers)
- Granting a foreign employee inside the US access to controlled source code or technology — this is a "deemed export" to that person's home country (foreign-employee access at an overseas office is instead a reexport)
So "I never handed anyone a USB stick" is not a defense. In modern development, where cloud and GitHub are the default, you can be making an "intangible transfer" without noticing.
That said, there is no need to panic. The system has a large built-in exemption: technology already released to the public falls outside the controls — the publicly-available exemption (in the US, EAR §734.7), and a general public release that anyone can download from GitHub / npm / PyPI / crates.io mostly lands inside it. The catch is that the exemption requires availability to the public at large: a private repository, an invite-only program, a gated model (released only to approved parties), or a release closed to specific foreign recipients is not "publicly available." (One carve-out to flag early: encryption software classified under ECCN 5D002 follows a special track — even when published it stays subject to the EAR unless the §742.15(b) conditions are met; for standard algorithms that track is light, with no notification, as the encryption-notification section below explains.) The next section sorts out what to look at to tell whether the rules reach you.
Telling whether the rules reach you — five categories and the overseas triggers
The starting point is simple: does the primary function of your software fall in one of the commonly-controlled categories? These five are representative examples developers most often run into — not the law's exhaustive classification.
| Category | Rough trigger | How often a solo dev meets it |
|---|---|---|
| Cryptography | Symmetric key over 56 bits, asymmetric RSA over 512 bits, ECC over 112 bits, and the like | High (easy to hit via a dependency without realizing it) |
| AI / Machine learning | Training compute (FLOPs), chip performance, etc. (the framework is in flux) | Med–High |
| Quantum computing | Number of physical qubits, quantum key distribution (QKD) | Low (mostly research institutions) |
| EDA (chip design automation) | Design tools at advanced nodes (around 3 nm) | Low (limited to that industry) |
| Intrusion software / cyber surveillance | Evading detection + extracting data + altering execution paths | Med (security industry / OSS) |
The actual thresholds live on separate lists: in the US the ECCN (Export Control Classification Number) under the EAR, in the EU the entries of Annex I to the Dual-Use Regulation. (Cross-references exist, but the lists are not identical.) For day-to-day work, three points matter most:
- Bundling a crypto library. OSS that includes AES / RSA / ECDSA formally falls in the cryptography category (US 5D002, etc.), but most of it clears via the publicly-available exemption. "I use crypto, therefore I'm out of bounds" is wrong.
- Where you release an AI model. Watch the geographic restrictions on the model's own license (for example, some Llama models restrict provision to EU residents or EU-based businesses). But that is a contractual license restriction, not the government's export control itself — easiest to reason about as an extension of how to read OSS licenses.
- Pentest tools / vulnerability research. These touch the intrusion-software category, but Wassenaar's revisions expressly carve out technology shared for vulnerability disclosure and cyber-incident response (this is a targeted carve-out, not a blanket exemption for all research or education).
And even when you touch one of the five, a license is not automatically required — but the checks are separate gates, not a single combined test. Run them independently: classification (does it map to a listed ECCN / list-control number); destination (does the Commerce Country Chart mark an "X" for that destination under the applicable Reason for Control — under EAR §738.4 a license can be required on destination alone, regardless of end-use); whether a License Exception applies; and finally the end-use / end-user / catch-all controls (which can require a license even for a non-listed item, e.g., a WMD-diversion concern). Any one gate can trigger a requirement on its own — so a push abroad, an overseas deployment, or foreign-employee access is the moment to check each gate, not to assume you're clear because the others don't apply. (Low-risk groupings differ by regime — in the US the closest analogue is EAR Country Group A:1, broadly the Wassenaar participating states; the UK, Germany, and France are typical low-risk allied destinations; confirm the applicable list.)
Rule of thumb: if (1) your primary function is not in the five categories, and (2) you publish as genuinely public OSS, most solo developers sit inside the publicly-available exemption. Conversely, if you provide crypto or AI closed to a specific foreign recipient, it is worth treating classification seriously.
The major regimes — just enough to act on
Even development that stays inside one country can't ignore US rules if it is the direct product of US-origin technology or software (the trigger for the Foreign Direct Product Rule below) or routes through US infrastructure or US persons — and separately, incorporating US-origin components/software/technology is analysed under the de minimis rule (§734.4), a different mechanism from the FDPR. Here is the minimum needed to tell whether the rules reach you.
| Jurisdiction | Main law | What a developer should watch |
|---|---|---|
| United States | EAR (dual-use) / ITAR (defense articles) | publicly-available exemption (§734.7) / encryption notification rules / FDPR (extraterritorial reach) |
| EU | Dual-Use Regulation 2021/821 | cyber-surveillance items / confirming with the national competent authority |
| Other (Japan / China) | Japan: FEFTA / China: OECL | "deemed export" reach / re-export controls — Japan detail in the Japanese edition |
Four things are worth holding onto.
First, the US split between EAR and ITAR. The EAR (15 CFR Parts 730–774) governs dual-use items administered by BIS, while ITAR (22 CFR Parts 120–130) governs defense articles on the US Munitions List, administered by the State Department's DDTC. Almost all ordinary commercial software sits under the EAR, not ITAR — but if your work touches military-specific items, the regime, and the consequences, are different.
Second, the US Foreign Direct Product Rule (FDPR). This extends US controls to foreign-made products that are the direct product of US-origin technology or software (or are made by a plant or major component that is itself such a direct product), when destined for controlled destinations/end-users (§734.9) — the textbook case where "we made it abroad, so the US doesn't apply" fails. (Merely incorporating US-origin content is a separate question handled by the de minimis rule, §734.4.) Pair an awareness of your degree of US dependence with a check on whether a collaborator is on a restricted list (the Entity List, etc.).
Third, the encryption-notification rules when you open-source crypto. The EAR has three easily-confused mechanisms; conflating them leads to over-compliance (such as believing you owe an annual report):
- Published encryption source code (EAR §742.15(b)): published code using a standard algorithm needs no notification; only non-standard code requires an email notification at first publication and when the crypto functionality changes. No annual report.
- Mass-market / commercial ENC (EAR §740.17): a separate mechanism for compiled binaries and commercial products.
- Annual self-classification report: yet another mechanism, where only in-scope items file the prior calendar year's entries. This is mainly for commercial-product and SaaS vendors; ordinary individual OSS release usually doesn't trigger it.
For most individual OSS developers, using standard cryptographic algorithms keeps you in the no-notification lane.
Fourth, AI export rules are in flux as of 2026-06. In the US, a comprehensive framework once announced (the "AI Diffusion" framework) was effectively suspended in 2025 when BIS stated it would not enforce it (the formal rescission process is still underway as of this writing — note that GAO B-337935 (2026-05-12) held the non-enforcement announcement is itself a "rule" under the Congressional Review Act, so the AI Diffusion Rule (which created the ECCN 4E091 model-weight control) remains on the books in the CFR until a formal rescission completes), and a successor rule was not finalized at the time of writing. Separately from the AI Diffusion non-enforcement, license requirements for advanced computing ICs (ECCN 3A090 / 4A090) to D:5 countries and Macau still apply (EAR §742.6; BIS issued guidance on 2026-05-31) — a suspended AI framework does not mean all advanced-computing controls are gone. On the EU side, Annex I of the Dual-Use Regulation is amended on a rolling basis (the most recent update added quantum and advanced semiconductor-manufacturing items). Treat anything AI-related as "check BIS and the national authorities directly for the current state," and do not rely on this article as the latest confirmed position.
Don't confuse it: Japan's 2025 FEFTA amendment expanded inbound investment screening — tightening review of foreign investment into Japan — which is a different axis from export controls that ship software out. Don't mix it up with the outbound (OSS-release) story. China's OECL (Export Control Law, in force since 2020) likewise belongs to the "other jurisdictions" bucket here; for Japanese detail, see the Japanese edition.
Summary — a self-diagnosis checklist before you cross a border
You don't need a "yes" on everything. Use this as a map of where to look, given your software and how you ship it. Paste it into a dev note or an internal check sheet.
[Solo / side-project developer]
□ 1. Checked whether the primary function falls in the five categories (crypto / AI / quantum / EDA / intrusion software)
□ 2. If crypto is involved, checked whether it uses a standard algorithm (in the US, standard = no notification)
□ 3. Checked that general release to GitHub / npm / PyPI etc. stays inside the publicly-available exemption (genuinely public, not gated)
□ 4. If using / releasing an AI model, checked the license's geographic restrictions (a separate axis from export control)
□ 5. Checked that the destination doesn't include a sanctioned / embargoed country or region (lists differ by jurisdiction and change over time — US OFAC / EAR Country Group E, EU, Japan all keep separate lists; confirm the current version)
□ 6. If providing to a specific foreign recipient on a closed basis, ready to confirm classification with a specialist
[Company export-compliance staff]
□ 1. Inventoried overseas pushes / overseas deployments / foreign-employee access as "intangible transfers"
□ 2. Even where not list-controlled, checked the catch-all factors (end-use / end-user / "informed" notice)
□ 3. Checked US technology/component dependence (FDPR) and whether counterparties are on the Entity List
□ 4. Automated sanctioned-country / counterparty screening in CI (the US Consolidated Screening List — Commerce/State/Treasury combined, incl. the BIS Entity List)
□ 5. Where in scope, confirmed the need for a bulk or individual license with the relevant authority
Three axes hold it together: (1) software is treated as an export (covering overseas pushes, deployments, and access); (2) screen first with the five categories plus the overseas triggers (most public OSS clears via the publicly-available exemption); and (3) hand the final classification to a specialist (this article takes you only to the entry point).
From here, confirming a specific classification or whether a license is required is beyond this article's reach. If you're building under US jurisdiction, BIS's own guidance is the primary reference; under EU rules, the regulation text and your national competent authority are; and where you're unsure, an export-control attorney is the reliable backstop. Building in or for Japan? The Japanese edition walks the same screen under Japanese law (FEFTA), with CISTEC's free public materials as a starting point. For the wider rights picture, start from the pre-ship rights checklist; to vet bundled dependencies, how to read OSS licenses is the quick path.
References
Primary materials where available; export control moves through amendments and changing enforcement, so everything reflects the position as of writing (June 2026). A trailing (primary) marks a primary source; (supporting) marks commentary or guidance used to locate or interpret the primaries. Where a point rests on fast-moving developments, confirm the current version at the time you rely on it.
United States (primary — statutes / regulations / agency)
- 15 CFR Parts 730–774 — EAR (full text)(primary)
- EAR §734.7 — Published / publicly available(primary)
- EAR §740.17 — License Exception ENC(primary)
- EAR §742.15 — Encryption items / notification(primary)
- EAR §740.22 — License Exception ACE (cyber research)(primary)
- 22 CFR Parts 120–130 — ITAR (USML, defense articles)(primary — DDTC / State Dept.)
- BIS — Bureau of Industry and Security (current AI-rule confirmation point)(primary — agency)
- BIS — Rescission of the AI Diffusion Rule (press release, 2025-05-13)(primary — agency)
- GAO B-337935 — the non-enforcement announcement is itself a CRA "rule"; the AI Diffusion Rule remains legally in effect in the CFR until formal rescission (2026-05-12)(primary — GAO decision)
- EAR §742.6 — license requirements for advanced computing ICs (ECCN 3A090/4A090) to D:5 / Macau, continuing independently of the AI Diffusion non-enforcement(primary — law)
- BIS Encryption controls (guidance)(primary)
- Consolidated Screening List (free denied-party screening)(primary)
European Union (primary)
- Regulation (EU) 2021/821 — Dual-Use Recast(primary — base regulation)
- Dual-Use Annex I — amended on a rolling basis (most recent: Delegated Reg. (EU) 2025/2003, in force 2025-11-15)(primary — Annex amendment)
- Regulation (EU) 2021/821 — consolidated text incl. Annex I (as of 2025-11-15)(primary — consolidated version)
Multilateral regime / exemptions
- The Wassenaar Arrangement — legal status (agreement only; force only via national law)(primary — international regime)
Other jurisdictions (Japan / China — detail in the Japanese edition)
- Japan — METI Security Export Control(primary — Japan; FEFTA detail in the Japanese edition)
- China — Export Control Law of the PRC (2020; English)(primary). The PRC's Regulation on Export Control of Dual-Use Items (State Council) and the unified Dual-Use Items Export Control List (MOFCOM, published 2024-11-15) both took effect 2024-12-01. Primary texts: Regulation on Export Control of Dual-Use Items (State Council Decree No. 792) (State Council English release) and the unified Dual-Use Items Export Control List (MOFCOM Announcement No. 51 of 2024).
Fast-moving developments (confirm at time of use)
- The US "AI Diffusion" framework was placed under a non-enforcement posture in 2025 and is effectively suspended (formal rescission underway); no successor rule was finalized as of 2026-06 — confirm with BIS.
- EU Dual-Use Annex I continues to be amended — confirm the current version on EUR-Lex.
- Japan's 2025 FEFTA amendment (expanded inbound investment screening — a separate axis from export controls).
On AI assistance: Starting from points the author already knew, the author used Claude (Anthropic) to research, organize, and summarize, then verified the facts against the primary sources (statutes and agency documents) cited above and built the article on that basis. Export control moves through amendments and changing enforcement, so article text, thresholds, and the latest developments reflect the position as of writing (June 2026). Confirm any point marked for re-checking against the primary sources at the time you rely on it. For the "not legal advice" note and what is out of scope, see the disclaimer at the top.
About the author
More than 20 years of electrical and software development — from control engineering at a major electronics manufacturer — plus about 10 years of solo development. Across hardware and software, and across enterprise and individual work, I publish the basics that "become a risk if you don't know them," and I plan to cover practical ways to use AI as well. More at About this blog.