土法炼钢兴趣小组的算法知识备份

【开源许可与版权工程】出海合规：ECCN、实体清单、加密出口、基金会与 OFAC

2026-04-22 · architecture · opensource · #export-control #eccn #ear #ofac #entity-list #encryption #openssl #sm2 #apache #linux-foundation

文章导航

分类入口
architectureopensource
标签入口
#export-control#eccn#ear#ofac#entity-list#encryption#openssl#sm2#apache#linux-foundation

目录

很多中国开发者把”合规”想象成一件离自己很远的事情：那是律师、外贸、大厂法务部门的工作。直到某一天：

对于做基础设施、做加密、做数据库、做云、做操作系统、做区块链的团队，出口管制（export control）几乎不可回避。本篇我们梳理 EAR（Export Administration Regulations，出口管理条例）框架、ECCN 体系、实体清单（Entity List）、OFAC（Office of Foreign Assets Control，美国海外资产控制办公室）制裁名单，以及它们如何落到”开源项目 / 开源基金会 / 个人贡献者”这一层。

本文不是法律意见，是一份工程参考。具体场合请咨询律师。

在继续之前，先给读者一个整体的心态校准：

一、出口管制的基础框架

1.1 EAR（出口管理条例）概述

EAR 由美国商务部（Department of Commerce）下属的 BIS（Bureau of Industry and Security，工业与安全局）颁布，法规文本位于《美国联邦行政法典》第 15 编第 730–774 部分（15 CFR Parts 730–774）。它管控的不是”纯粹的军品”（那些在 ITAR 下，由国务院管），而是所谓的”两用物项”（dual-use items）：既可民用，也可军用。

EAR 的管辖对象非常宽泛：

对开源软件来说，最常打交道的是”软件”（software）和”技术”（technology）这两类，以及它们落到加密类别下的那些条目。

EAR 并不是美国唯一的出口管制机制。旁边还有几个需要同时关注的：

对中国开发者来说，欧洲的”Dual-Use Regulation”（EU 2021/821）、英国的”UK Strategic Export Control Lists”、日本的”外汇及对外贸易法”都是与 EAR 有协调关系的多边体系（这些体系的底层都参考 Wassenaar Arrangement 瓦森纳安排）。做跨多国生意时，至少要扫过这几套名单。

把 EAR 的管辖要点列成表，便于对照：

管辖面 触发条件 对开源的含义
U.S.-origin 物项 在美国研发 / 生产 / 首发 美国开发者主导的开源项目天然落入 EAR
de minimis 非美国产品含超过 10%（对古巴 / 伊朗等为 0% 或 25%）美国受控成分 你在香港发布的 SDK 如果 80% 代码来自 OpenSSL，则整包须同等对待
FDP Rule 用美国受控技术 / 软件 / 设备在第三地生产 用美国 EDA 工具在大陆流片的芯片，可能仍受 EAR
deemed export 在美国境内，向外国人披露受控技术 在美分公司雇佣中国籍工程师、接触 5E002 技术，触发
re-export 从 A 国出口到 B 国 把美国发布的库再打包上传到俄罗斯镜像站，可能违规

理解这张表后再看后续的开源豁免就会明白：开源之所以能全球流通，不是因为 EAR 不管，而是因为它为”公开可用”留了口子。

1.2 ECCN（出口管制分类编号）体系

EAR 附录中的 CCL（Commerce Control List，商业管制清单）把受控物项编号为 ECCN，格式形如 5D002：

开源开发者最熟悉的几个：

几个”看似无害但其实值得留意”的条目：

不在 CCL 上的物项归为 EAR99——仍在 EAR 管辖内，但一般不需要许可证，除非目的国 / 最终用户 / 最终用途触发了限制。大量普通商业软件（不涉及加密、不涉及高性能计算、不涉及核材料）都落在 EAR99。

大量普通商业软件（不涉及加密、不涉及高性能计算、不涉及核材料）都落在 EAR99。

补充几个开源项目对号入座的例子：

可以看出，“是否含加密”比”是否高科技”对 ECCN 的影响更大。

1.3 开源软件的特殊豁免

EAR 对开源软件有两条关键豁免：

  1. 公开可用（publicly available）例外。见 15 CFR §734.3(b)(3)：已公开发布、可被公众无限制获取的”已发布”技术和软件，通常不属于 EAR 管辖范围。但这条不适用于加密软件——加密是个特例。
  2. TSU 豁免（License Exception TSU）中的 “Unrestricted Encryption Source Code”。15 CFR §740.13(e)：以源代码形式公开可用的加密软件，只要在首次发布时向 BIS 和 NSA ENC Encryption Request Coordinator 发送一封”URL 通知”邮件，就可以走这条豁免路径，向绝大多数国家出口。这也是 Linux 内核、OpenSSL 等开源加密项目能在全球合法分发的法律基础。

“公开可用”这个术语本身也有精确定义。§734.7 给出了几种情况：

反过来，一些不算公开可用的情况：

于是就出现了一个微妙的区分：

场景 适用条款
非加密的开源软件 §734.3(b)(3) 公开可用，不在 EAR 管辖
加密的开源源代码 §740.13(e) TSU，在 EAR 管辖但有豁免
加密的开源二进制 也可走 §740.17 ENC 等路径
闭源加密商业软件 5D002，需分类（CCATS）+ 许可证或 ENC 豁免

后面的章节会把这张表展开。

需要澄清的一点：EAR99 与 §734.3(b)(3) 是两件事。EAR99 是 CCL 未分类的状态，它依然”在 EAR 管辖之内”，只是不需要许可证（除非目的地 / 最终用户触发）。而 §734.3(b)(3) 则是”直接移出 EAR 管辖范围”。对开源而言：

二、加密软件的出口分类

2.1 5D002：大多数加密软件的 ECCN

在 CCL 上，5D002 覆盖了”为加密而设计或修改的、使用 对称密钥长度超过 56 比特 / 非对称密钥长度超过 512 比特 / 椭圆曲线超过 112 比特 的软件”。简单说：几乎所有带 TLS 1.2+、AES-128+、RSA-2048+、ECC P-256+ 的软件都会落到 5D002。

几个常见的误解：

  1. “我只是调用 HTTPS，不算密码学实现”：EAR 看的是软件对外提供的功能，而不是”是不是自己实现的”。只要最终用户能通过该软件使用受控强度的加密，一般就归 5D002。
  2. “我用的是系统自带的库，不算我的”：打包 / 分发环节决定管辖，如果你的 binary / image / installer 把加密库捆绑了进去（无论是静态链接还是 bundle so / dll），出口时按整体分类。
  3. “研究论文里的加密算法代码也算 5D002”：纯学术 / 教育用途的公开发布，可走 §734.3(b)(3) 的例外之一（“fundamental research”），但边界需要与具体机构的 technology control plan 结合判断。

这意味着：

判断的关键词是”functionality”而不是”行数”。只要最终产物对外暴露出加密能力，就倾向归入 5D002。

但 5D002 只是分类，不等于”禁止出口”。真正决定是否需要许可证的，是”目的地 + 最终用户 + 最终用途”三要素。

2.2 EAR99 与公开可用豁免

如果你的项目：

那它归为 EAR99。EAR99 + 公开可用的项目，加上 §734.3(b)(3) 的豁免，实际上处于”几乎不受 EAR 管辖”的状态。但即便如此，仍然有三条红线：

  1. 不能出口到禁运国（E:1 / E:2 国家名单，包括古巴、伊朗、朝鲜、叙利亚，以及受限制的俄罗斯 / 白俄罗斯领土）；
  2. 不能向 SDN / Entity List 上的最终用户出口；
  3. 不能用于被 EAR §744 禁止的用途（大规模杀伤性武器 / 特定军事最终用途等）。

这三条对开源软件意味着：GitHub 在识别到某个账户位于伊朗时会主动锁定，这不是 GitHub 愿意，是 EAR 和 OFAC 要求。

值得展开的一点是 EAR §744 的”最终用途”清单，通常包括：

这些”use-based”控制是开源项目最容易忽视的红线之一——即便软件本身是 EAR99，如果知道或应知最终用户是这类用途，仍然不得出口。典型应对：在用户协议或 README 里添加一段”prohibited use”说明，并配合 CI 扫描检测已知高风险用户模式。

2.3 TSU 豁免（Technology and Software — Unrestricted）

§740.13 下的 TSU 豁免包含几种小类，其中 §740.13(e) 专门给开源加密源代码：

Publicly available encryption source code classified under ECCN 5D002 (and corresponding object code resulting from the compiling of such source code) is released from “EI” and “NS” controls …

使用条件：

  1. 源代码是 “publicly available”（通常指发布在公开的网站、代码仓库）；
  2. 在首次发布或首次公开可获取之时（不是后续每次更新），向 BIS 的 crypt@bis.doc.gov 和 NSA 的 enc@nsa.gov 发送一封邮件，内容是源代码的 URL（或者告知该 URL 在哪里）；
  3. 如果后续代码移动到新 URL，一般需要再次发送通知。

Apache 基金会在 https://www.apache.org/licenses/exports/ 维护了一份”ECCN Matrix”，把所有顶级项目的 ECCN、加密算法、TSU 通知情况列出来。这是给下游用户（特别是美国及其合作国用户）看的合规证据。

一封”符合 §740.13(e)“的 TSU 通知邮件长什么样？大致如下（实际文本以 BIS 最新指南为准）：

To: crypt@bis.doc.gov
Cc: enc@nsa.gov
Subject: TSU notification for publicly available encryption source code

Pursuant to 15 CFR §740.13(e), this is a notification that the following
publicly available encryption source code has been posted on the
Internet and is available for download without restriction:

  Project:      <project name>
  URL:          https://github.com/<org>/<repo>
  Description:  <one-paragraph description; algorithms used>
  Maintainer:   <name, affiliation, country>

Any future changes in URL will be notified.

Regards,
<name>

这封邮件不是”申请许可证”，是”通知”。一般不会收到批准回执，保留发信记录即可。

2.4 如何判断你的项目的 ECCN

工程上一般走这个流程：

  1. 梳理项目中出现的加密函数 / 库的依赖。包括直接依赖和传递依赖；特别注意 TLS 实现、哈希、签名、对称加密、KDF。
  2. 查 Apache ECCN Matrix / 依赖项目的上游声明。OpenSSL、Bouncy Castle、WolfSSL 等都有发布过自己的 ECCN。
  3. 判断你的项目是”单纯调用加密” 还是 “提供加密功能给他人使用”。前者一般随主功能分类（5D002 仍然常见但不一定），后者几乎肯定是 5D002。
  4. 判断是否公开发布。GitHub 公开仓库 = publicly available。
  5. 走 TSU 通知。真正商业化 / 闭源化的版本，另外做 CCATS（Commodity Classification Automated Tracking System，商品分类自动跟踪系统）分类请求。

再补充几条”不太容易踩的”细节：

下面的伪代码把判断过程写成一个函数，便于在仓库 CI 中执行：

def classify(project) -> str:
    if project.uses_crypto:
        if project.source_publicly_available and project.license.is_osi_approved:
            return "5D002 (TSU exempt under 15 CFR 740.13(e))"
        if project.is_mass_market:
            return "5D992.c (ENC (b)(1), self-classification)"
        return "5D002 (requires CCATS / ENC classification)"
    if project.is_high_performance_compute:
        return "4D001 (check APP thresholds)"
    return "EAR99"

这个函数不是权威依据，但能让团队在项目立项时就回答”我会落在哪里”的问题。

本文附的 SVG 决策图是对以上流程的可视化：

出口管制决策流程

三、实体清单与基金会

3.1 实体清单（Entity List）简介

Entity List 是 EAR 附录 4（15 CFR Part 744, Supplement No. 4）列出的”受限最终用户”名单。被列入后，向其出口 / 再出口 / 国内转移任何 EAR 管辖物项通常需要许可证，且大多数申请会被”推定拒绝”（presumption of denial）。

与 OFAC 的 SDN 列表不同：

一个实体可能同时出现在两个名单上，也可能只在其一。

除了 Entity List 和 SDN，开发者还会遇到：

对出海企业来说，仅做一次 SDN 筛查远远不够，通常需要引入 Dow Jones Risk & Compliance / Refinitiv World-Check / 海关 screening API 之类的商业服务，一次把十几张名单打平。

几个容易被忽略的”名单交叉”细节：

3.2 2019 年 BIS 对华为的限制

2019 年 5 月 16 日，BIS 将华为技术有限公司及其约 68 家关联子公司列入 Entity List，生效日为 5 月 16 日。随后进行了多轮补充，包括 2019 年 8 月追加 46 家、2020 年 8 月追加 38 家，以及 2020 年 5 月 / 8 月两次扩展 FDP 规则，封堵使用美国技术 / 设备在第三地生产的芯片。

对开源生态的直接震荡：

  1. Android：Google 宣布对华为新机暂停提供 Google Play 服务的许可版本，但 AOSP（Android Open Source Project，安卓开源项目）部分因为是 §734.3(b)(3) 公开可用，华为仍可下载和使用。
  2. ARM：因为其部分 IP 含有美国成分，一度宣布暂停与华为的合作，后又在内部评估 IP”美国成分比例”后恢复了部分 ISA 层面的许可。
  3. SD 协会、Wi-Fi 联盟、JEDEC 等：短期内将华为从会员中移除或暂停投票权，之后随着法律评估完成，基本都恢复了其成员身份。
  4. GitHub：继续为华为员工提供公有仓库访问，依据即是 EAR 对公开可用内容的豁免。

这件事的意义在于：它让整个开源社区第一次大规模地认识到”开源项目 / 开源基金会 / 开源账号”在出口管制体系下并非完全中立。

从时间线看，2019 年之后的几次重要加码：

这些都不直接涉及开源项目，但开源基础设施（特别是 AI 开源社区）的模型权重、训练集群、硬件适配层，都因此出现了”上游非美国化”的动作，比如 llama.cpp 的 CPU 推理优化、国产 GPU 厂商与 PyTorch 的后端集成。

3.3 Apache 基金会的声明与应对

ASF（Apache Software Foundation）在 2019 年 5 月 23 日发布声明（“Apache Software Foundation statement regarding the U.S. Department of Commerce restrictions on Huawei Technologies”），要点：

  1. Apache 项目的源代码以 Apache License 2.0 开源，是公开可用的出版物，受 EAR §734.3(b)(3) 和 §734.7 约束之外；
  2. 这些代码的获取、使用、再分发不因 Entity List 而改变；
  3. ASF 本身位于美国，遵守美国法律；
  4. 任何个人和组织均可继续参与 Apache 项目，遵循项目的社区规则。

这条声明保护了大量与华为 / 中国公司有关的贡献者，也让”贡献代码给 Apache 项目”这件事没有立刻变得复杂。Apache 的 ECCN Matrix 依然把含加密的项目登记为 5D002 并以 TSU 豁免方式出口。

其中一些更细的操作值得一提：

3.4 Linux 基金会的声明

Linux Foundation 在 2019 年 6 月发布声明，明确：

  1. Linux 内核源代码以 GPLv2 开源，是公开可用信息，不受 EAR 限制，亦适用 §734.3(b)(3) 豁免；
  2. 基金会及其项目（含 CNCF / Hyperledger / LF Networking 等）继续欢迎中国公司和开发者参与。

Linus Torvalds 本人的位置（芬兰 / 美国）和 kernel.org 基础设施（分布在多地）让内核项目在法律上有很强的”国际公开可用”属性。

除了”声明”这种形式，Linux Foundation 还通过几项结构性设计降低了合规单点：

3.5 CNCF 的处理方式

CNCF（Cloud Native Computing Foundation，云原生计算基金会）作为 Linux Foundation 旗下的子基金会，同样适用 LF 的声明框架。

CNCF 的治理特色使它对”国际化合规”友好：

这种”社区治理 + 基金会法务双轨”在出现合规事件时更具韧性：日常运营不因国际政治波动而变化，合规事件由基金会法务按事件处理，不波及治理结构。

3.6 对中国开发者参与基金会项目的实际影响

从工程视角看，实体清单事件留下的几个长期影响：

  1. 公有云服务 ≠ 开源代码。华为可以下载 TensorFlow 源码，但不能用 Google 的公有云 AI 服务。很多中国公司因此在内部建立了”对外依赖清单”，把”源代码”与”云服务 / 商业许可证”分开管理。
  2. 基础设施多点化。大型中企的代码镜像会同时放在 GitHub、GitLab 自建、Gitee、GitCode、Codeberg 等多处，避免任一家出现合规限制时整个研发停摆。
  3. 法律评估前置到架构。涉及加密的开源库版本锁定 + 本地镜像 + 许可证矩阵评估成为大厂 OSPO 的标配（详见本系列第 17 篇《OSPO 与合规自动化》）。一些典型的架构策略：
合规风险 对应架构动作
GitHub 访问不稳 主 repo 推 Gitee / 自建 Gitea 双向同步
Docker Hub 拉取受限 自建 Harbor，统一镜像路径 registry.corp.cn/library/*
npm / pypi 被墙 自建 Verdaccio / Nexus / devpi
闭源组件授权被停 梯度替换为开源平替，提前列出候选
关键美国开源库断更 保留长期支持分支，内部打补丁
云厂商合作被卡 多云策略（AWS + 阿里云国际 + 华为云）
特定地区客户下载 CDN 前置 GeoIP 规则
  1. 基金会投名状。中国公司在 Apache / CNCF / LF 参与度显著提高；一方面是业务需要，另一方面也是”成为规则参与者而非旁观者”的主动姿态。
  2. 从”使用者”到”贡献者”再到”捐献者”的进化。过去十年，中国企业对开源从”基本只使用”到”开始贡献”再到”主导捐献项目”的转变，部分动因就是：只有成为上游规则的塑造者，才能减小被合规风险打乱节奏的概率。Apache DolphinScheduler、Apache ShardingSphere、Apache IoTDB、CNCF Harbor、CNCF KubeEdge、Apache OpenDAL 等都是中国企业主导捐献并已毕业的项目。

四、OFAC 制裁与开源贡献

4.1 OFAC 制裁名单（SDN）与制裁国

OFAC 在美国财政部之下，执行经济 / 金融制裁。其主要名单：

对开源而言，关键在两个层面：

  1. 贡献者个人：如果一个贡献者被 OFAC 认定在这些制裁国 / 在 SDN 上，项目（尤其是由美国组织持有代码库的项目）从事与其相关的”service”可能受限；
  2. 最终用户 / 部署地：即使代码公开可用，GitHub / npm / Docker Hub 等平台可能对来自制裁地区的 IP / 账号做限制。

注意，“source code 公开可用”豁免主要来自 EAR，而 OFAC 的 sanction 在”service”（例如私有仓库管理、付费计划、支持服务）层面执行起来独立于 EAR。2019 年 GitHub 锁定伊朗账户时给出的解释就是”私人仓库、组织账户等属于 service，受 OFAC 管辖”。

一个有用的区分：

所以即使一个项目的代码完全”自由流通”，其背后的 CI / 协作工具也可能在制裁触发时不可用——这也是为什么大型中国项目越来越重视”CI 自主可控”。

4.2 俄罗斯内核维护者被移除事件（2024）

2024 年 10 月，Linux 内核 6.12 开发周期中，Greg Kroah-Hartman 提交了一个补丁（commit 6e90b675cf942e50c70e8394dfb5862975c3b3b2 附近，在 MAINTAINERS 文件中），将一批俄罗斯籍或在俄罗斯实体工作的维护者从 MAINTAINERS 文件中的条目删除。提交信息中写道：

Remove some entries due to various compliance requirements. They can come back in the future if sufficient documentation is provided.

在 LKML 和 Phoronix、LWN 的后续讨论中：

  1. Linus Torvalds 公开表示，这是因为相关维护者受到美国 / 其他国家的制裁法律的影响，Linux 基金会法律部门要求处理；
  2. 该调整不删除他们既往的贡献（Git 历史不被 rewrite），只是不再把他们作为官方 MAINTAINERS；
  3. 将来若能提供”不受制裁约束”的证明（例如不在被制裁实体就职），可以恢复身份。

这次调整覆盖的面很小，据公开信息大约十几位维护者，涉及的子系统多集中在特定硬件驱动。邮件列表的回复中有人质疑”为什么不直接说是哪条制裁条款”，Greg KH 的回答大意是：具体条款细节由基金会法律部门判断，他不对外转述法律意见，这是一次”合规执行”而不是”社区价值判断”。Linus Torvalds 在补充回复中措辞更直接：作为身在美国的内核首席维护者，他”个人不喜欢这件事，但也不会去打这场官司”。

从时间线看，这件事并不是孤立的：

对关心 Linux 内核治理的开发者，这件事是一个值得长期观察的分界点。

这件事的意义：

4.3 伊朗、朝鲜、古巴、叙利亚开发者的处境

这几个国家的开发者长期面临：

  1. GitHub 账户可能被锁定（2019 年有批量锁定伊朗账户事件，后经调整，公开仓库读写在 2021 年前后部分恢复）；
  2. npm / PyPI / Docker Hub 等平台对制裁地区 IP 的访问限制；
  3. 无法注册 Google Cloud / AWS / Azure / OpenAI 等需要支付的服务；
  4. 某些 CLA 要求填写国籍 / 所在地，会直接触发法务评估。
  5. 学术合作和会议发表受限，研究生出国念书时签证困难；
  6. 开源项目中以”真实姓名 + 所在机构”署名可能遭致项目维护者顾虑。

2019 年 GitHub 限制伊朗账户事件后，社区的反应：

古巴、朝鲜、叙利亚因为综合制裁更严，开发者几乎完全无法使用主流美国平台。部分人的选择：

对中国开发者的提醒：不要用”VPN + 虚假国籍”去帮制裁国同事注册服务，这在美国法律下是”帮助规避制裁”，风险远大于收益。一个折中方案：与制裁国同事的技术合作，尽量在”公开代码层”进行——PR、issue、公开邮件列表这些路径是 EAR 豁免保护的。需要私有协作（内部 Slack、私有 repo、未公开技术文档）时，先咨询法务。

一些社区（包括 Gitea、Codeberg、SourceHut）明确把自己定位为”不受美国管辖为主的平台”，希望为这些开发者保留代码托管能力。

对中国开发者的借鉴：即便今天没人主动锁你，“建立异地镜像”也是成本低、收益大的保险。常见做法是：

  1. 在 GitHub 主仓库上同时配置 Gitee / GitCode / Codeberg / 自建 Gitea 的 push mirror；
  2. CI 产物（binary / image）同时发布到 GitHub Releases、Docker Hub、quay.io、阿里云 ACR、Harbor 开源镜像站；
  3. 对外文档声明”如主站不可用，可从以下镜像获取”，避免”单点失联”。

4.4 GitHub 的制裁执行实践

GitHub 在 https://docs.github.com/en/site-policy/other-site-policies/github-and-trade-controls 里详细说明了自己的合规框架：

  1. 公开仓库的浏览、克隆、提交 issues 和 PR，在大多数情况下可用，依据是 EAR §734.3(b)(3) 和 §734.7；
  2. 私有仓库、付费计划、组织账号 等”service”功能，则受到更严格的限制；
  3. 被 SDN 或位于综合制裁地区的账户会被限制功能；
  4. 用户可以通过申诉流程证明”不在受制裁实体”或”已搬离受制裁地区”从而恢复。

这套模型对所有美国托管平台（GitLab.com、Bitbucket、Docker Hub、npm、PyPI 等）都适用。

4.5 开源基金会如何应对

开源基金会面对制裁时大致采取”分层”策略：公开代码保持全球开放；平台服务按法律要求收紧；治理权限 case by case 处理。具体展开：

代码层：

服务层：

治理层：

主流基金会的共性做法：

  1. 在总部所在国家（多为美国）聘请合规律师，维护项目 ECCN 列表；
  2. ICLA / CCLA 中加入出口合规声明（见本系列第 18 篇《CLA 与 DCO》），贡献者承诺其贡献不违反适用的出口管制 / 制裁法律；
  3. 对涉及加密的新项目做 TSU 通知；
  4. 必要时调整 MAINTAINERS / 权限（如上文 Linux 案例）；
  5. 在声明中区分”代码 / 项目的公开可用属性”与”平台服务的可用性”，前者尽量保持全球可用，后者遵守当地法律。
  6. 对接”安全披露 / 漏洞报告”流程做国际化适配：PSIRT 或 security@ 邮件组如果完全托管在美国，收到来自制裁国研究者的漏洞报告时会触发复杂评估；部分基金会在多个司法辖区分散设置协调人（例如 Apache 有 security committee、CNCF 有 security TAG）。

不同基金会的具体姿态有差异：

中国开发者参与不同基金会时，“美国成分”的暴露程度天然有差异，但基本都是：只要不在 SDN、不代表 Entity List 实体、不试图把代码或服务出口给禁运国，参与本身没有障碍。

五、加密出口的具体问题

5.1 OpenSSL 与 EAR

OpenSSL 项目是加密出口管制史上最经典的案例之一。

回顾美国加密出口政策的几次大转折，对开源开发者理解今天的规则有帮助：

这段历史让”开源加密 + TSU 通知”成为今天的标准操作。反过来，一些国家（如俄罗斯、印度、越南）在自己的加密进口管制上还保留着早年的繁琐流程，出海企业依然会遇到相应成本。

值得一提的还有几个同领域项目的分类：

对工程上的启示：

  1. 在产品设计里尽量把加密层抽象到一个清晰的模块，便于做 ECCN 分类；
  2. 不要 fork 维护私有版本的 OpenSSL，除非你愿意自己承担分类和许可证责任；
  3. 做白盒加密 / 国密算法模块时，专门评估出口合规——这是 5.2 要讲的。
  4. 对 TLS 握手链路上的依赖做明确记录。很多产品文档里只写 “uses HTTPS”，真到合规审计时需要给出具体实现，一时找不到。
  5. 升级 OpenSSL 主版本时重做一次 ECCN 审查。例如从 OpenSSL 1.1 升到 3.x 时，引入了新算法（如 KTLS、新的 KEM 接口），最好复核 ECCN Matrix。

5.2 国密算法（SM2/SM3/SM4）的出口与”回流”

中国国密算法（SM2 椭圆曲线签名、SM3 哈希、SM4 分组密码、SM9 基于身份的密码、ZUC 祖冲之序列密码）属于中国 OSCCA（State Cryptography Administration，国家密码管理局）管辖的商用密码。详情可见本系列姊妹文《国密算法工程实战》。

出口视角：

  1. 在中国境内研发并发布开源实现（如 GmSSL、Tongsuo（铜锁）、go-gmsm、Bouncy Castle 的 GM 分支）：源头遵守中国《密码法》《商用密码管理条例》，公开发布需满足中国境内商用密码的合规要求；出口境外使用时一般不再由 EAR 管辖，但会被当地国家的加密进口法规（例如俄罗斯 FSB 认证）管辖。
  2. “回流”场景：开源 SM 实现被 OpenSSL、BoringSSL、rustls 等美国主导项目集成之后，代码本身又成为 5D002 的一部分；此时按”美国项目”规则再出口。
  3. 商业 SDK：国内商密 SDK 出海时，通常要在目标国做”加密进口备案”（法国 ANSSI、俄罗斯 FSB、越南 MIC 等都有类似制度），和美国 EAR 是平行体系。

开发者尤其要注意：“国密的安全性符合国标”与”国密模块在海外合法分发”是两件事。后者需要做出口 + 进口双向评估。

再细化一些常见的国密 + 出海模式：

  1. 客户端是国产系统，服务端在海外：典型如面向华人群体的 APP，客户端要用国密适配国产手机的内置算法库，服务端在新加坡。服务端 TLS 用国际算法，应用层包体再叠一层 SM2/SM4。合规上源头 SDK 出境遵守中国商密；目标国进口侧一般不限制；“端到端”只要在法域边界解密 / 再加密清晰即可。
  2. 金融行业数据跨境：在香港 / 澳门开展对中国大陆客户的服务时，香港侧要支持国密以便与内地清算网关对接；同时本地监管要求使用国际算法。解决方案是”双栈”并行。
  3. 政企出海的 VPN / 专网：向”一带一路”沿线客户提供含国密的专网设备，往往会被当地列入”本地加密进口”审查。不少国家会要求提供算法白皮书、证明无”后门”。
  4. SM2 作为可选签名算法出现在国际协议扩展：OpenSSL 3.x 已经内置 SM2 / SM3 / SM4 支持。当一个国际开源项目接收 SM 相关 PR 时，PMC 不需要重新走一次 TSU 通知——SM 系算法被视为 5D002 的具体实例，Matrix 里更新版本号即可。
  5. SM9 / ZUC 向学术社区的贡献：这两类算法的公开参考实现已经被 ISO 标准化（ISO/IEC 14888-3、18033-3 等），在学术发表和 IETF 文稿中可以自由引用和实现。

5.3 含加密功能的商业软件出海

闭源商业软件如果归为 5D002，出口路径一般有三条：

  1. §740.17 License Exception ENC：按照条款（b)(1)“最终用户 = 美国子公司 / 外国政府”、(b)(2)“mass market”（大众市场）等不同小类，配合向 BIS 提交的分类请求或 “self-classification report”。
  2. CCATS 分类 + License：对高强度加密（如量子安全、某些长度以上的 KEM 等）或向受限国家出口时申请单独许可证。
  3. 特定项目下的豁免：例如对盟国政府的某些 IT 合同、ITAR 项下军用密码移交国务院等。

无论哪条路径，“每年 self-classification report”和”semi-annual sales report”是常规动作。出海团队要把这部分流程化，否则一年后补报会非常痛苦。

以一个典型的出海 SaaS 产品为例，合规的每年度操作清单大致如下：

时间点 合规动作 输出
新版本发布 核对 ECCN Matrix / 算法变更 内部 changelog + ECCN 更新说明
首次发布或大版本迁址 发 TSU 通知 邮件存档
每年 2 月 1 日前 向 BIS 提交 self-classification report（涵盖上年度 5D002 发货） CSV 上传 + 回执
每年 2 月 / 8 月 向 BIS 提交 semi-annual sales report（特定 ENC 条款下） CSV 上传 + 回执
客户出现变动 重新做 SDN / Entity List 筛查 screening log
年度审计 审查合同 / 付款 / 客户清单 审计报告

把这些动作写进 OSPO 的年度日历，甚至自动化执行，是企业成熟度的一个标志。

把”开源 vs 商业、含加密 vs 不含加密”画成 2x2 矩阵，会更直观：

不含加密 含加密
开源 / 公开可用 EAR99 + §734.3(b)(3)，几乎自由 5D002 + §740.13(e) TSU，发一次通知
商业闭源 EAR99，避开制裁地区 / 客户 5D002 + ENC，年度 report；高强度需许可证

绝大多数中国出海开源项目都落在右上角；要做闭源 SaaS / SDK 时才会真正进入右下角。

六、中国开发者在 Apache 基金会的注意事项

6.1 贡献代码的出口合规

ASF 是美国（Delaware）注册的 501(c)(3) 非营利组织，其运营适用美国法律。中国开发者贡献到 Apache 项目时：

  1. 你签的 ICLA 包含 “Contribution” 的授权声明，没有直接的”出口合规”条款，但通过 ASF 的政策隐含：“你提交的内容可以被 ASF 自由分发到全世界”，这意味着你事实上同意”以 TSU / 公开可用 形式公开发布”。
  2. ASF 的 “Export Control” 页面要求”Committer 在向涉及加密的项目 commit 加密相关 patch 前，先与 PMC / VP, Legal Affairs 联系”，必要时更新 ECCN Matrix。
  3. 对于中国籍贡献者身份本身，只要不在 SDN 名单、不在被综合制裁的国家、不代表被 Entity List 实体，参与是完全合法的。

如果你是项目外来贡献者，PR 被合并后你不会直接”触发”任何出口动作——是 ASF 以基金会身份对外分发，你只是”把代码交给基金会”。这一设计简化了个体贡献者的合规负担。相对的，Committer 和 PMC 作为基金会代理人，合规责任更大一些。

6.2 Committer / PMC 身份的注意事项

成为 Committer 之后，你获得的是对 ASF 基础设施的写权限。这不同于”贡献公开代码”：

  1. 访问 ASF 基础设施（svn、git、JIRA、邮件列表）属于 ASF 提供的 “service”，受 OFAC / EAR 管辖的面比”纯公开代码”更大；
  2. 如果你搬到了综合制裁地区（例如去伊朗 / 朝鲜工作），ASF 可能不得不暂停你的账号；
  3. PMC 成员参与投票 / release 流程时，是以 ASF 项目管理者身份行事，涉及的合规关注比 Committer 更多，尤其是发布含加密代码的 release 时要走 “ECCN update” 流程。
  4. 跨多个项目拥有 Committer 身份（俗称 “Committer at ASF” 而非某项目 Committer）时，可以在 people.apache.org 的个人页登记所在国家，以便基金会在需要时快速评估；
  5. 变更雇主 / 所在地后，建议主动更新 committer-info，而不是等到基金会查出”某位 Committer 现在在制裁地区工作”才被动处理。

对中国 Committer / PMC 的建议：

6.3 涉及加密模块的贡献

实操建议：

  1. 新增 / 修改加密算法 的 PR 要在 description 里注明算法、密钥长度、调用来源，方便 PMC 判断是否更新 ECCN；
  2. 引入 OpenSSL / BoringSSL / BouncyCastle 等依赖，并不要求重新分类，但要注明版本；
  3. 引入国密（例如给 Apache ShardingSphere / Apache IoTDB 添加 SM2 / SM4 支持），需要特别提示——它在中国合规视角叫”商用密码”，在美国 EAR 视角下仍然落在 5D002 的通用加密范畴，需要走 TSU 豁免或 ENC；
  4. 写单元测试使用的测试密钥要公开、足够短或明示为测试用途，避免被误判成”真实商业加密部署”。

6.4 涉及中国政府 / 国密的项目捐献

近几年一个活跃的方向是：中国公司把自家的国密增强项目捐献到国际开源基金会。例如 Tongsuo（铜锁）早期在 GitHub 开源、后续引入多家企业共同维护；Apache 的部分 Committer 在 PMC 决策中讨论过”国密支持是否进入主线”。从出口合规角度看：

  1. 捐献过程涉及代码 copyright transfer / license 再授权，该走 Software Grant Agreement；
  2. 捐献后新主库一旦在 Apache / CNCF 基础设施上托管，ECCN 由基金会登记，整体落入 TSU 豁免链条；
  3. 中国原主库的”镜像”或”长期维护版本”仍然留在 Gitee / 自建 Gitea，面向中国境内客户使用，走中国商密体系；
  4. 海外用户下载基金会版本，合规路径清晰；海外用户若希望”商业支持”，一般由上游公司在当地法人提供。

这套路径既满足了”真正国际化”，也不牺牲”中国境内合规”。对想把国产基础软件推向全球的团队，值得参考。

Apache 的 ECCN Matrix（https://www.apache.org/licenses/exports/）是所有 TLP（Top-Level Project，顶级项目）的 single source of truth。中国 PMC 成员通常不直接碰这个矩阵，但要在 release vote 时留意 RM（Release Manager，发布经理）是否勾选”此 release 包含加密功能”并更新相应条目。

进一步给一个具体的 PR template 示例，方便项目 Owner 借鉴：

## 本次贡献的内容
- [ ] 功能描述
- [ ] 涉及加密 / 哈希 / 签名算法？若是，列出算法与密钥长度
- [ ] 是否引入 / 升级加密相关的第三方依赖？
- [ ] 是否已通知 PMC 更新项目 ECCN Matrix？

## 出口合规声明
我确认：
- 我不位于 15 CFR §746 列出的综合制裁地区；
- 我不是 OFAC SDN 名单上的个人，也不代表被美国 Entity List 限制的实体以该身份贡献；
- 我的贡献将按项目适用的开源许可证被公开发布。

把这样一段加进 CONTRIBUTING.md 或 PR 模板，本身就是对项目合规姿态的最小成本表达。

七、云厂商出海合规实践

7.1 阿里云在欧洲 / 中东的部署

阿里云 Alibaba Cloud 在法兰克福、伦敦、迪拜、吉达、利雅得、雅加达等地设有 region。出海合规的核心动作：

  1. 数据本地化与 GDPR：欧洲 region 的数据默认留在欧盟，控制面由阿里云海外法人运营；
  2. 加密合规：TLS / KMS 等产品使用的加密算法在不同 region 有差异——例如中国 region 默认支持国密算法，境外 region 默认仅支持国际算法，二者不交叉；
  3. 实体清单 / SDN 筛查：在客户注册、实名认证时做 OFAC / EU sanction 名单筛查；
  4. 与美国制裁的互动：阿里云作为中国公司，不受美国 EAR 直接管辖，但其海外 region 所使用的部分芯片 / 软件来自美国供应商，仍要遵守这些供应商的出口条款（这也是所谓”美国成分”问题）。
  5. 合规认证：逐步拿下 C5（德国）、IRAP（澳大利亚）、SOC 2、ISO 27001 / 27017 / 27018 等，增加 enterprise 客户选型时的可信度。

7.2 华为云的合规框架

华为云 Huawei Cloud 由于 2019 年 Entity List 事件，更早建立了一整套多国合规体系：

  1. 三朵云战略：中国、香港、新加坡、荷兰、沙特、巴西等多 region 运营，分别由当地法人作为合规主体；
  2. 产品的”美国成分”替换：逐步用国内 / 非美供应链替代部分 x86 / GPU / 软件组件，减少 FDP Rule 触发面；
  3. 客户端侧加密：KMS / HSM 服务同时支持国密和国际算法，按 region 策略选择；
  4. 出口合规团队：向海外客户出货 / 部署服务器时，走自己的 ECCN 评估流程。
  5. 国密与国际算法双栈：中国境内用国密、海外 region 用国际算法，编译期 / 部署期通过 feature flag 切换，避免单一版本跨境误用。
  6. 对欧盟 NIS2 / GDPR / CSA、英国 UK Cyber Essentials 等合规框架的逐一响应：这些虽然不是”出口管制”，但与”服务向海外用户”紧密相关。

7.3 字节 / 腾讯 / 快手的海外业务

非基础设施云之外，内容 / 社交类应用出海也会遇到加密合规：

这些公司本身虽不是开源基金会，但他们贡献的开源项目（OpenJDK Dragonwell、Kuasar、OceanBase、ByConity 等）在 release 时会带上对应 ECCN 说明，某种意义上也是”基金会级别”的合规姿态。

7.4 小团队如何避免一开始就掉进陷阱

对三五个人的出海创业团队，给不起一支合规团队，可以按这个优先级处理：

  1. 先别碰闭源强加密 SDK 这条路。能走开源 + TSU 就走，法律负担最轻。
  2. 所有对外付费接口通过 Stripe / Paddle 等成熟 MOR（Merchant of Record）。他们替你处理 OFAC 筛查和税务合规。
  3. 公司注册地与客户法域分开考虑。中国境内研发 + 香港 / 新加坡 / 开曼控股公司 + 美国 / 欧洲销售实体，每一层做一件合规的事情，不要让一个实体背所有风险。
  4. 保留一次小额外聘律师预算。在”签第一份海外企业客户合同”、“第一次融资”、“第一次出货给中东 / 非洲”前找一次律师，远比事后补救便宜。
  5. 宁愿多拆一层法律实体，也不要为了省事把中国研发与美国销售揉在同一家公司。许多小型 SaaS 被并购或 IPO 时，尽调阶段的第一个”红旗”往往就是”实体未分层”，事后重组成本十倍。

这两家的经验对中小出海团队的启示：region 选择 + 算法支持 + 客户筛查 + 供应链美国成分 是需要同时设计的四条线，忽略任何一条都可能在某个客户、某个订单、某个审计时爆雷。

把”出海合规”拆成可执行的检查项，可以这样列：

维度 关键问题 工具 / 输出
项目分类 ECCN 是什么？是否走 TSU？ ECCN Matrix、TSU 邮件存档
依赖审查 是否含未审 5D002 依赖？ SBOM + ECCN DB
供应链 美国成分占比？是否触发 FDP？ BOM + 成分表
客户筛查 客户是否在 SDN / Entity List？ Sanctions screening 服务
部署地 是否服务于 E:1 / E:2？ Region 拓扑 + GeoIP
加密强度 算法是否超出 ENC 自分类阈值？ 算法清单
国密支持 是否在中国 region 默认开启国密？ Region 配置矩阵
数据本地化 数据是否跨境？是否触发 GDPR / PIPL？ DPIA 报告（参考本系列第 17 篇 OSPO）

八、工程实践

8.1 禁用特定地区下载

典型做法：在 CDN / 对象存储 / 下载站前置一个制裁名单 filter：

# nginx 示例：按 GeoIP 拦截制裁国下载
geo $ofac_blocked {
    default 0;
    include /etc/nginx/geoip/sanctioned.conf;  # CU, IR, KP, SY, 克里米亚等
}

server {
    location /download/ {
        if ($ofac_blocked) {
            return 451 "Unavailable for legal reasons";
        }
        try_files $uri =404;
    }
}

几个要点：

1.HTTP 451 Unavailable For Legal Reasons 是正确的语义状态码（RFC 7725）； 2. GeoIP 不是 100% 准确，合规目标是”reasonable efforts”而不是”perfect blocking”； 3. 对于开源加密项目，这个 filter 的适用范围一般限定在 商业版本 / 付费下载，开源源代码 + TSU 豁免的部分仍应全球可用——否则反而违反 TSU 的”publicly available”前提。 4. 对命中地区，建议给出申诉入口（例如一个 compliance@<domain> 邮箱），允许”我已搬离”或”VPN 误判”的用户请求人工复核。 5. 定期（至少每月一次）从 BIS / OFAC 官网更新名单，不要硬编码在代码里——制裁地区会变。

对 SaaS 而言，这套 filter 应当位于 登录 / 注册 / 支付 / 下载 四个环节，单纯在前端 JS 里做拦截是不够的（用户改一下 User-Agent 就绕过）。

8.2 贡献者所在地登记

ICLA / CCLA（见本系列第 18 篇）通常要填写国家 / 地址。工程上可以：

  1. 通过 CLA Assistant / EasyCLA 等工具，在贡献者签署时收集国家字段；
  2. 把字段与 OFAC 制裁国列表做对照（使用 Treasury 提供的 SDN XML 定期同步）；
  3. 命中时不自动拒绝，而是转人工复核：很多情况下，贡献者可能只是 VPN / 临时旅行 / 双重国籍，需要额外证明。
  4. 把贡献者记录的法律基础以隐私政策的形式明示：为什么收集、存多久、是否共享。欧洲贡献者会特别在意这一点（GDPR）。
  5. 把”国籍”与”实际工作国”分开记录，前者可能更稳定，后者才是合规判断依据（例如一位中国籍开发者长期在瑞士工作，其贡献应按瑞士法律风险评估）。

8.3 git 仓库审查

对于涉及加密、涉及海外客户的项目，发布前对 git 仓库做一次审查：

  1. grep -ri "aes\|rsa\|ecdsa\|sm2\|sm3\|sm4" --include='*.go' --include='*.c' . 列出加密算法出现位置；
  2. 把这些模块与 ECCN Matrix 对齐：是自己实现 ? 调用依赖 ? 可配置关闭 ?
  3. 检查 commit author / committer 的 email 域名是否涉及制裁实体；
  4. 对 tag / release 打包时，自动产出 SBOM（见本系列第 16 篇《SCA 与 SBOM》），SBOM 中包含每个组件的 ECCN。
  5. 扫描 *.pem、*.key、id_rsa 等文件，确保没有把生产密钥 / 客户密钥误 commit；这是 security 与 compliance 交叉的高危点。
  6. 对 git 的 committer identity 做一次年度清理，离职的外籍贡献者如果还挂名 MAINTAINERS 却失联，可能在合规审计时被问询。

8.4 CI/CD 中的出口合规检查

# GitHub Actions 示例
name: export-compliance
on:
  pull_request:
  workflow_dispatch:

jobs:
  eccn-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Generate SBOM
        run: syft packages dir:. -o cyclonedx-json > sbom.json
      - name: Match SBOM against ECCN DB
        run: |
          python scripts/eccn_match.py sbom.json > eccn-report.json
      - name: Fail if unreviewed 5D002 components
        run: |
          jq -e '.unreviewed | length == 0' eccn-report.json
      - uses: actions/upload-artifact@v4
        with:
          name: eccn-report
          path: eccn-report.json

  sdn-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check committer emails against SDN
        run: python scripts/check_sdn.py

搭配一份由安全团队维护的 eccn_db.csv（package name → ECCN → 是否已走 TSU 通知），就能在 PR 阶段就拦截”新引入了未分类加密依赖”的情况。

一个最小可用的 eccn_db.csv 长这样：

name,ecosystem,eccn,tsu_notified,note
openssl,apt,5D002,yes,upstream notified
boringssl,git,5D002,yes,Google maintains
wolfssl,apt,5D002,dual-license,"GPL or commercial"
rustls,cargo,5D002,yes,ISRG hosted
libsodium,apt,5D002,yes,
mbedtls,apt,5D002,yes,Trusted Firmware
bcprov-jdk18on,maven,5D002,yes,Bouncy Castle
cryptography,pip,5D002,yes,PyCA
tongsuo,git,5D002,notified-by-self,Chinese-origin; SM2/SM3/SM4
gmssl,git,5D002,notified-by-self,
jackson-databind,maven,EAR99,,
commons-lang3,maven,EAR99,,

配合 eccn_match.py 这样的脚本，就能把 SBOM 里的每一项与 DB 做 join，未命中条目自动标记为 “unreviewed”，由合规评审兜底。

8.5 Release 发布前的 checklist

在 release vote 或 GA（General Availability）tag 之前，建议跑一次：

#!/usr/bin/env bash
set -euo pipefail

echo "== SBOM =="
syft packages . -o cyclonedx-json > dist/sbom.json

echo "== ECCN 匹配 =="
python scripts/eccn_match.py dist/sbom.json

echo "== 贡献者国籍检查 =="
git log --format='%ae' v$(PREV)..HEAD | sort -u | python scripts/check_sdn.py

echo "== 加密算法扫描 =="
rg -n --hidden --no-heading \
    -e 'AES' -e 'RSA' -e 'ECDSA' -e 'Ed25519' \
    -e 'SM2' -e 'SM3' -e 'SM4' -e 'ZUC' \
    -g '!vendor' -g '!node_modules' > dist/crypto-grep.txt

echo "== 许可证检查 =="
license-checker --production --json > dist/licenses.json

echo "== Docker 镜像签名 =="
cosign sign --yes $IMAGE

echo "OK. 请人工复核 dist/*.json"

把这个脚本接入 release pipeline，是从”靠人记忆”迈向”靠流程”的关键一步。

8.6 出口合规文档模板

推荐每个出海项目在仓库根目录放一份 EXPORT_COMPLIANCE.md，内容大致：

# Export Compliance

## Classification

This software is classified as ECCN **5D002** under the U.S. Export
Administration Regulations (EAR).

## Exemption

Publicly available encryption source code is released from "EI" and "NS"
controls pursuant to 15 CFR §740.13(e). A TSU notification was sent to
`crypt@bis.doc.gov` and `enc@nsa.gov` on `<YYYY-MM-DD>`.

## Cryptographic algorithms used

| Algorithm | Purpose | Source |
| --- | --- | --- |
| TLS 1.2/1.3 | Transport security | OpenSSL 3.x |
| AES-256-GCM | Data at rest | libsodium |
| Ed25519 | Release signing | cosign |
| SHA-256 | Integrity | standard library |

## Sanctioned destinations

This software should not be exported, re-exported, or transferred to:

- Comprehensively sanctioned regions (Cuba, Iran, North Korea, Syria,
  Crimea, Donetsk, Luhansk, Zaporizhzhia, Kherson).
- Any party on the BIS Entity List, Denied Persons List, Unverified
  List, or OFAC SDN List, without appropriate U.S. government
  authorization.

## Questions

Contact `compliance@<your-domain>`.

把类似文档放在仓库中，一次性解决用户、律师、合规审计员的大部分疑问。

8.7 发布渠道与镜像策略

对中国发起的出海开源项目，通常建议的发布拓扑：

关键原则：不把任何”唯一的关键节点”放在可能被单边切断的服务商上。同时也不把任何”唯一的关键节点”放在仅境外服务商上——中国用户的体验和全球用户的体验要同时保障。

8.8 合规事件响应 runbook

当真正发生合规事件（GitHub 账号被限制、维护者被要求确认身份、客户被列入 Entity List）时，有一份 runbook 能让团队不慌：

EVENT:  贡献者账号被 GitHub 限制 / maintainer 被质询身份
---
T+0h    事件发现方把信息同步到 #compliance 内部频道
T+1h    由 OSPO / 法务接手，确认事件性质（合规 or 账号问题）
T+4h    对外保持沉默，不公开猜测；只在私下与当事人确认细节
T+24h   如涉及合规，由法务起草对外措辞；给 PMC / 社区 lead 预览
T+48h   必要时对外声明，保留充分"我方已合作"证据
T+1w    做一次内部复盘，更新 EXPORT_COMPLIANCE.md 与 runbook

提前有 runbook 的项目比没有的项目，在舆论和法律两端的表现都会稳得多。

8.9 数据跨境与出口管制的重叠

数据跨境（cross-border data transfer）是另一条平行的合规线。在中国，《个人信息保护法》（PIPL）、《数据安全法》（DSL）、《关键信息基础设施安全保护条例》（CII）都有对”重要数据”出境的限制。与出口管制的关系：

  1. 一套”向海外客户提供 SaaS”的部署会同时触发：EAR（软件出口）、OFAC（服务提供）、PIPL（个人信息出境）、GDPR（欧盟用户数据处理）；
  2. 好的架构会让数据尽量留在客户法域内（“data residency by default”），控制面才是跨境流通的核心；
  3. 开源代码本身一般不包含个人数据，因此”代码出境”与”数据出境”是两件事——把它们分清楚能避免把简单问题复杂化。

中国数据跨境合规的具体做法（PIPL 标准合同、安全评估、认证机制三条路径）不在本文范围，推荐另起专题阅读。

九、工程坑点

下面是常见的”踩过才知道”的坑：

  1. 以为开源就一定不受 EAR 管辖：错，加密软件是特例，需要走 TSU 豁免而不是 §734.3(b)(3)。
  2. 把”不在 SDN”当作完整的筛查：还要查 Entity List、DPL（Denied Persons List）、Unverified List、MEU（Military End User）list、各国的本地制裁名单。
  3. VPN 解决合规问题：VPN 不是合规工具，OFAC / EAR 看的是 “who” 而不是 “IP”。真实所在国和真实最终用户才是关键。
  4. “我的项目不卖美国”所以不用管 EAR：只要你有一位美国开发者、你用美国的库、你在美国 CDN 发布，你就已经在 EAR 的某个面里。
  5. 忘记 TSU 的 URL notification：很多创业公司自己写了加密库丢到 GitHub，没有发过通知。严格说是不合规的，但补发并不难——一封邮件的成本。
  6. 闭源 SDK 随便给海外客户试用：走过大方向的 ENC 豁免之前，不要向未审 region 的客户 “试用版”，否则是”未申报出口”。
  7. Git 历史里留下了含密钥 / 含政府标识的测试文件：历史不能轻易 rewrite，出口审计时容易被挑。产生前就 .gitignore 掉。
  8. 把”中国公司”与”中国员工”混淆：实体清单上是特定公司，个人只要不是代表这些实体就可以正常参与开源。反之，SDN 上的个人即便身处第三国，交易也受限。
  9. 只看 EAR 不看 OFAC：EAR 关注”物项流向”，OFAC 关注”与谁做交易”；后者违反的刑事风险更高。二者常被同时触发。
  10. 用 CLA 代替出口合规评估：CLA 主要解决版权许可 / 专利授权（见本系列第 05 篇《专利与商标》、第 18 篇），不代替 ECCN 分类与 sanction 筛查。
  11. 把”美国成分”理解成纯硬件概念：错。软件、技术、Know-How、甚至 EDA 工具使用生成的 IP 都可能算美国成分。服务于云端的 API 本身也可能算。
  12. 在公开仓库里放内部法务意见或合规报告：这类文档虽无版权风险，但可能包含客户名单、地区分布等信息，一旦公开反而缩小了未来的回旋空间。合规材料建议放私有目录。
  13. GitLab / Gitea 自建 = 完全无合规负担：错。只要你的业务涉及向制裁国 / SDN 出口，平台换成自建不改变法律评估。自建的价值在于”不因第三方合规而被断服”，不在于”绕过合规”。
  14. 把 TSU 通知当成一次性任务：错。项目 URL 变更、顶级加密算法发生重大替换（例如加入 PQC 算法）时，一般建议补通知。
  15. 以为”我的项目从没向美国卖过”就没关系：EAR 的管辖基于”物项”而非”买方”。只要包含美国 origin 成分 + 出口到制裁地区，就已经违规。
  16. 把 “mass market” 判定想当然：§740.17 ENC 下的 “mass market” 有明确条件（零售销售、终端用户可自行安装、不因用户定制而变化等）。企业 SDK 一般都不满足 mass market，常被误归。
  17. release notes 里写大段密码学细节：看起来专业，但会让审计员要求对每个算法单独分类。除必要的安全公告外，把”算法列表”维护在 EXPORT_COMPLIANCE.md 或 ECCN Matrix，release notes 保持简洁。
  18. 在公开场合承认”我们产品可能被某实体列客户使用”：即便是玩笑，也会被竞品 / 监管留档。对敏感客户保持沉默是一种合规姿态。
  19. 出国参加会议带着未发布代码的笔记本：这涉及 deemed export / 海关电子设备检查，历史上有开发者被要求检查笔记本。保险做法是只带公开代码 + 通过私有 VPN / 云 IDE 访问未发布代码。

十、决策树：我的项目需要做什么

把全文的操作压缩成一张问答表：

  1. Q：我的项目不含任何加密算法，也不在 CCL 其他条目。 A：归 EAR99，公开发布可走 §734.3(b)(3)。避免向制裁国 / SDN 出口即可。不需要走 TSU 通知。

  2. Q：我的项目含加密，源代码公开发布在 GitHub。 A：5D002 + §740.13(e) TSU。请发一封 URL 通知给 crypt@bis.doc.gov 和 enc@nsa.gov（抄送项目 Maintainer 邮件列表存档）。移站时补通知。

  3. Q：我的项目含加密，是商业闭源 SDK，向海外客户出售。 A：做 self-classification 或 CCATS 分类；走 §740.17 ENC；年度 self-classification report + 半年度 sales report；不向 E:1 / E:2、SDN、Entity List 出口；部分国家可能还需要当地加密进口备案。

  4. Q：我的项目由中国公司主导，想捐献到 Apache / CNCF。 A：可以。按基金会流程走孵化。涉及加密算法时，注册 ECCN Matrix；中国籍贡献者身份不影响 Committer / PMC 资格（前提是不属于被制裁实体）。

  5. Q：我所在公司被列入 Entity List。 A：贡献 / 使用公开发布的开源源码不受影响；使用 GitHub / AWS 等”service”部分可能受限；请咨询公司合规部门。个人身份下参与开源一般不受限（以个人而非公司身份贡献）。

  6. Q：我的项目想集成国密算法给海外客户使用。 A：国密开源实现出海后仍被美国视角归为 5D002 下的通用加密，须走 TSU 或 ENC；同时目的国可能有加密进口 / 算法认证要求（如俄罗斯 FSB、法国 ANSSI）。

  7. Q：我收到一个来自伊朗 IP 的 PR。 A：合并公开代码本身属 EAR 豁免范围；但如果该贡献者被 OFAC 单独列入 SDN，或代表被制裁实体，需拒绝并记录。单凭 IP 不能判断，建议与法务共同评估。

  8. Q：我想把服务部署到中东客户。 A：筛查客户是否在 SDN / Entity List；评估是否涉及受限最终用途；检查 SaaS 本身的 ECCN；若涉及加密商业软件，走 ENC 或许可证路径；并考虑当地数据保护法规。

  9. Q：我在海外研究所工作，想以个人身份给 OpenHarmony 这样的中国主导项目贡献代码。 A：只要项目本身的贡献者协议不把你排除在外，并且你贡献的是源代码而非具体的军用技术，就是合法的。但要注意：你所在国家可能有针对特定中国受限实体的”逆向”限制，如果 OpenHarmony 背后的某个法人被列入该国名单，理论上有风险；实际上中国主导项目对海外贡献者始终持欢迎态度。

  10. Q：我的项目在 GitHub，突然哪天 GitHub 因政策不得不限制中国大陆访问，我应该怎么办？ A：提前做好镜像（Gitee / GitCode / Codeberg / 自建 Gitea），至少保障代码、release、文档三处多点；对于 CI，把关键密钥放在你自己的 secret manager 而不是绑死在某一家 CI Provider。这个问题更多是韧性工程问题，而不是合规问题。

  11. Q：我的 AI 开源项目用的模型权重，算不算”软件”？ A：截至目前，美国对 AI 模型权重的出口管制尚在动态变化中（2024–2025 年有多轮规则制定）。一种保守姿态：把”权重”与”代码”分开 release，并在权重发布时注明训练数据与用途限制。

  12. Q：我想做一个完全不涉及加密的小工具，SaaS 化卖到全球。 A：EAR99 + 公开可用使得代码分发不受限，但 SaaS 本体仍然是 service，需要对注册用户做 OFAC 筛查；账单系统一般会捆绑这项能力（Stripe / Paddle 等会自动拒绝制裁地区信用卡）。

  13. Q：我是独立开发者，完全没时间研究这些。 A：最低成本路径——项目完全开源（选 Apache-2.0 或 MIT）发布在 GitHub；涉及加密就发一封 TSU 邮件；付费接入 Stripe / Paddle；不要自己做海外银行账户 + 现金交易。这样做完，绝大多数风险都被平台和豁免吸收掉了。

  14. Q：我以个人名义贡献过一些加密相关代码给某 US 项目，现在要入职某家被列入 Entity List 的中国公司，是否需要做什么？ A：个人历史贡献不受影响。入职后以该公司员工身份与该 US 项目的交互（例如以 @corp-email 提交、代表公司出席技术会议）则应由公司法务评估。个人继续以私人邮箱贡献通用代码通常没问题，但涉及敏感技术细节的互动需要谨慎。

本文为工程参考，不构成法律意见。涉及具体法律风险请咨询专业法律顾问。

最后，给一个”现实主义”的总结：

对于 95% 的中国开源开发者，你真正要做的事不多：

  1. 如果项目含加密且在 GitHub 公开，发一封 TSU 通知邮件；
  2. 在 README.md 或 EXPORT_COMPLIANCE.md 里声明 ECCN；
  3. 不主动向伊朗、朝鲜、古巴、叙利亚、克里米亚等综合制裁地区出口；
  4. 不主动与明确在 SDN / Entity List 的客户做商业合作；
  5. 保持镜像多点化，以防基础设施单点不可用。

剩下 5% 的场景（强加密商业 SDK、政府客户、军工相关、受限实体合作）才需要专业律师介入。把精力花在对的地方，合规就不是负担，而是出海的基础能力。

十一、参考资料

法规与官方文件

基金会与平台声明

事件与新闻报道

本系列其他文章

延伸阅读

上一篇：CLA、DCO 与贡献者协议 | 下一篇：开源战略：什么时候开源、选哪个协议、如何构建商业壁垒

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2026-04-22 · architecture / opensource

开源许可与版权工程

面向中国工程团队的开源许可、版权与合规系列。从 GPL、AGPL、Apache、木兰协议到中国真实案例、SCA/SBOM 工具链与出海合规，讲清楚开源在工程落地中的坑与方法。

By .