2026-04-22 · architecture / opensource
【开源许可与版权工程】开源许可证实操手册：从选型到发布
面向工程团队的开源许可证完整操作手册：许可证选型决策树、LICENSE/NOTICE/SPDX 文件写法、第三方依赖声明、CI 自动化检查、发布物合规标注，以及六套真实可复制的项目结构模板。
很多中国开发者把”合规”想象成一件离自己很远的事情：那是律师、外贸、大厂法务部门的工作。直到某一天：
对于做基础设施、做加密、做数据库、做云、做操作系统、做区块链的团队，出口管制（export control）几乎不可回避。本篇我们梳理 EAR（Export Administration Regulations，出口管理条例）框架、ECCN 体系、实体清单（Entity List）、OFAC（Office of Foreign Assets Control，美国海外资产控制办公室）制裁名单，以及它们如何落到”开源项目 / 开源基金会 / 个人贡献者”这一层。
本文不是法律意见，是一份工程参考。具体场合请咨询律师。
在继续之前，先给读者一个整体的心态校准：
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 不管，而是因为它为”公开可用”留了口子。
EAR 附录中的 CCL（Commerce Control
List，商业管制清单）把受控物项编号为 ECCN，格式形如
5D002：
开源开发者最熟悉的几个：
5A002：含加密功能的硬件 / 设备；5D002：含加密功能的软件；5E002：与上述相关的技术；4D001：某些高性能计算机软件；3A001：某些电子器件。几个”看似无害但其实值得留意”的条目：
3A090 / 4A090：2022 年 10
月新增的先进 AI 芯片类别，用于限制高端 GPU /
加速卡出口；开源项目如果打包了含有这些硬件 SDK
的二进制，要单独评估；4D090：与 3A090 / 4A090
配套的软件条目；5D992：mass market 加密软件，介于 EAR99 和
5D002 之间，自我分类 report 即可；5D002.c.1 vs
5D002.d.1：前者是”含加密功能”的软件，后者是”专用于设计、生产、使用
5A002 / 5D002 / 5E002
物项”的软件，后者出口比前者更敏感；EI 与 NS 两种控制原因（Reasons
for Control）：EI 是 “Encryption Items”，NS 是 “National
Security”；TSU §740.13(e) 豁免会移除这两类控制。不在 CCL 上的物项归为 EAR99——仍在 EAR
管辖内，但一般不需要许可证，除非目的国 / 最终用户 /
最终用途触发了限制。大量普通商业软件（不涉及加密、不涉及高性能计算、不涉及核材料）都落在
EAR99。
大量普通商业软件（不涉及加密、不涉及高性能计算、不涉及核材料）都落在 EAR99。
补充几个开源项目对号入座的例子：
Apache Kafka
本体是事件流平台，不实现加密，但 kafka-clients
支持 SASL / SSL。ASF 的 ECCN Matrix 把它列为
5D002（因为它配置层可启用 TLS），使用 TSU 豁免。Apache Tomcat 同理，因为内置 HTTPS
connector。Apache POI 是 Office
文档处理库，本身不加密，但由于能读写加密 OOXML，也标记为
5D002。Apache Commons Lang 一类纯工具库，归
EAR99。TensorFlow 本体是机器学习框架，落 EAR99；但
Google 的商业 AI 服务（Vertex AI 等）是另一回事。FRP（Fast Reverse Proxy）这类 Go
语言的反向代理开源工具，因为实现了自己的加密通道（AES），在严格意义上也要算
5D002。可以看出，“是否含加密”比”是否高科技”对 ECCN 的影响更大。
EAR 对开源软件有两条关键豁免：
“公开可用”这个术语本身也有精确定义。§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 管辖范围”。对开源而言：
在 CCL 上，5D002
覆盖了”为加密而设计或修改的、使用 对称密钥长度超过 56 比特 /
非对称密钥长度超过 512 比特 / 椭圆曲线超过 112 比特
的软件”。简单说：几乎所有带 TLS
1.2+、AES-128+、RSA-2048+、ECC P-256+ 的软件都会落到
5D002。
几个常见的误解：
这意味着：
implementation 'org.bouncycastle:bcprov-jdk18on'
或走 TLS 握手，链路上的组件多半都是 5D002。crypto/tls、Python 的 cryptography
都在 5D002。has_secure_password、session
cookie 加密一旦出现，也会使整体分类偏向 5D002。判断的关键词是”functionality”而不是”行数”。只要最终产物对外暴露出加密能力，就倾向归入 5D002。
但 5D002 只是分类，不等于”禁止出口”。真正决定是否需要许可证的，是”目的地 + 最终用户 + 最终用途”三要素。
如果你的项目：
那它归为 EAR99。EAR99 + 公开可用的项目，加上 §734.3(b)(3) 的豁免，实际上处于”几乎不受 EAR 管辖”的状态。但即便如此，仍然有三条红线：
这三条对开源软件意味着：GitHub 在识别到某个账户位于伊朗时会主动锁定，这不是 GitHub 愿意，是 EAR 和 OFAC 要求。
值得展开的一点是 EAR §744 的”最终用途”清单，通常包括：
这些”use-based”控制是开源项目最容易忽视的红线之一——即便软件本身是 EAR99，如果知道或应知最终用户是这类用途，仍然不得出口。典型应对：在用户协议或 README 里添加一段”prohibited use”说明，并配合 CI 扫描检测已知高风险用户模式。
§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 …
使用条件：
crypt@bis.doc.gov 和 NSA 的
enc@nsa.gov 发送一封邮件，内容是源代码的
URL（或者告知该 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>这封邮件不是”申请许可证”，是”通知”。一般不会收到批准回执，保留发信记录即可。
工程上一般走这个流程：
再补充几条”不太容易踩的”细节：
dlopen
系统自带的加密库，项目本体可能仍能归
EAR99，但要在文档中明确说明”本软件不包含加密实现”。--with-ssl / --with-crypto
编译开关，默认关闭。这种情况下主 release 可以保持
EAR99，而含加密的 release 走 5D002；两种 artifact
分开分类。下面的伪代码把判断过程写成一个函数，便于在仓库 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 决策图是对以上流程的可视化：
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 之类的商业服务，一次把十几张名单打平。
几个容易被忽略的”名单交叉”细节：
2019 年 5 月 16 日，BIS 将华为技术有限公司及其约 68 家关联子公司列入 Entity List，生效日为 5 月 16 日。随后进行了多轮补充，包括 2019 年 8 月追加 46 家、2020 年 8 月追加 38 家，以及 2020 年 5 月 / 8 月两次扩展 FDP 规则，封堵使用美国技术 / 设备在第三地生产的芯片。
对开源生态的直接震荡：
这件事的意义在于：它让整个开源社区第一次大规模地认识到”开源项目 / 开源基金会 / 开源账号”在出口管制体系下并非完全中立。
从时间线看，2019 年之后的几次重要加码：
这些都不直接涉及开源项目，但开源基础设施（特别是 AI 开源社区）的模型权重、训练集群、硬件适配层，都因此出现了”上游非美国化”的动作，比如 llama.cpp 的 CPU 推理优化、国产 GPU 厂商与 PyTorch 的后端集成。
ASF（Apache Software Foundation）在 2019 年 5 月 23 日发布声明（“Apache Software Foundation statement regarding the U.S. Department of Commerce restrictions on Huawei Technologies”），要点：
这条声明保护了大量与华为 / 中国公司有关的贡献者，也让”贡献代码给 Apache 项目”这件事没有立刻变得复杂。Apache 的 ECCN Matrix 依然把含加密的项目登记为 5D002 并以 TSU 豁免方式出口。
其中一些更细的操作值得一提：
Linux Foundation 在 2019 年 6 月发布声明，明确：
Linus Torvalds 本人的位置（芬兰 / 美国）和 kernel.org 基础设施（分布在多地）让内核项目在法律上有很强的”国际公开可用”属性。
除了”声明”这种形式，Linux Foundation 还通过几项结构性设计降低了合规单点：
CNCF（Cloud Native Computing Foundation，云原生计算基金会）作为 Linux Foundation 旗下的子基金会，同样适用 LF 的声明框架。
CNCF 的治理特色使它对”国际化合规”友好：
这种”社区治理 + 基金会法务双轨”在出现合规事件时更具韧性：日常运营不因国际政治波动而变化，合规事件由基金会法务按事件处理，不波及治理结构。
从工程视角看，实体清单事件留下的几个长期影响：
| 合规风险 | 对应架构动作 |
|---|---|
| GitHub 访问不稳 | 主 repo 推 Gitee / 自建 Gitea 双向同步 |
| Docker Hub 拉取受限 | 自建 Harbor，统一镜像路径
registry.corp.cn/library/* |
| npm / pypi 被墙 | 自建 Verdaccio / Nexus / devpi |
| 闭源组件授权被停 | 梯度替换为开源平替，提前列出候选 |
| 关键美国开源库断更 | 保留长期支持分支，内部打补丁 |
| 云厂商合作被卡 | 多云策略（AWS + 阿里云国际 + 华为云） |
| 特定地区客户下载 | CDN 前置 GeoIP 规则 |
OFAC 在美国财政部之下，执行经济 / 金融制裁。其主要名单：
对开源而言，关键在两个层面：
注意，“source code 公开可用”豁免主要来自 EAR，而 OFAC 的 sanction 在”service”（例如私有仓库管理、付费计划、支持服务）层面执行起来独立于 EAR。2019 年 GitHub 锁定伊朗账户时给出的解释就是”私人仓库、组织账户等属于 service，受 OFAC 管辖”。
一个有用的区分：
所以即使一个项目的代码完全”自由流通”，其背后的 CI / 协作工具也可能在制裁触发时不可用——这也是为什么大型中国项目越来越重视”CI 自主可控”。
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 的后续讨论中：
这次调整覆盖的面很小，据公开信息大约十几位维护者，涉及的子系统多集中在特定硬件驱动。邮件列表的回复中有人质疑”为什么不直接说是哪条制裁条款”，Greg KH 的回答大意是：具体条款细节由基金会法律部门判断，他不对外转述法律意见，这是一次”合规执行”而不是”社区价值判断”。Linus Torvalds 在补充回复中措辞更直接：作为身在美国的内核首席维护者，他”个人不喜欢这件事，但也不会去打这场官司”。
从时间线看，这件事并不是孤立的：
对关心 Linux 内核治理的开发者，这件事是一个值得长期观察的分界点。
这件事的意义：
这几个国家的开发者长期面临：
2019 年 GitHub 限制伊朗账户事件后，社区的反应：
古巴、朝鲜、叙利亚因为综合制裁更严，开发者几乎完全无法使用主流美国平台。部分人的选择：
对中国开发者的提醒：不要用”VPN + 虚假国籍”去帮制裁国同事注册服务，这在美国法律下是”帮助规避制裁”，风险远大于收益。一个折中方案：与制裁国同事的技术合作，尽量在”公开代码层”进行——PR、issue、公开邮件列表这些路径是 EAR 豁免保护的。需要私有协作（内部 Slack、私有 repo、未公开技术文档）时，先咨询法务。
一些社区（包括 Gitea、Codeberg、SourceHut）明确把自己定位为”不受美国管辖为主的平台”，希望为这些开发者保留代码托管能力。
对中国开发者的借鉴：即便今天没人主动锁你，“建立异地镜像”也是成本低、收益大的保险。常见做法是：
GitHub 在 https://docs.github.com/en/site-policy/other-site-policies/github-and-trade-controls 里详细说明了自己的合规框架：
这套模型对所有美国托管平台（GitLab.com、Bitbucket、Docker Hub、npm、PyPI 等）都适用。
开源基金会面对制裁时大致采取”分层”策略：公开代码保持全球开放；平台服务按法律要求收紧；治理权限 case by case 处理。具体展开：
代码层：
服务层：
治理层：
主流基金会的共性做法：
不同基金会的具体姿态有差异：
中国开发者参与不同基金会时，“美国成分”的暴露程度天然有差异，但基本都是：只要不在 SDN、不代表 Entity List 实体、不试图把代码或服务出口给禁运国，参与本身没有障碍。
OpenSSL 项目是加密出口管制史上最经典的案例之一。
回顾美国加密出口政策的几次大转折，对开源开发者理解今天的规则有帮助：
这段历史让”开源加密 + TSU 通知”成为今天的标准操作。反过来，一些国家（如俄罗斯、印度、越南）在自己的加密进口管制上还保留着早年的繁琐流程，出海企业依然会遇到相应成本。
值得一提的还有几个同领域项目的分类：
BoringSSL（Google fork 自 OpenSSL）：由
Google 在美国维护，直接适用 ASF 之外的 Google
内部合规框架，对外用户基本通过 Chromium / gRPC
间接使用；wolfSSL：美国爱达荷州公司维护的嵌入式 TLS
库，对商业用户采用双许可（GPLv2 / 商业），商业版本会提供
ECCN 说明；mbedTLS：原 ARM 维护，现由 Trusted Firmware
社区托管，以 Apache-2.0 发布，同样 5D002 + TSU；rustls：纯 Rust TLS 实现，ISRG（Let’s
Encrypt 母组织）托管，公开可用归 5D002 + TSU；libsodium：NaCl 的易用封装，公开可用 5D002
+ TSU；Tongsuo（铜锁）：蚂蚁开源的 OpenSSL
分支，支持国密，源头在中国，出境后按 5D002 处理。对工程上的启示：
中国国密算法（SM2 椭圆曲线签名、SM3 哈希、SM4 分组密码、SM9 基于身份的密码、ZUC 祖冲之序列密码）属于中国 OSCCA（State Cryptography Administration，国家密码管理局）管辖的商用密码。详情可见本系列姊妹文《国密算法工程实战》。
出口视角：
开发者尤其要注意：“国密的安全性符合国标”与”国密模块在海外合法分发”是两件事。后者需要做出口 + 进口双向评估。
再细化一些常见的国密 + 出海模式：
闭源商业软件如果归为 5D002，出口路径一般有三条：
无论哪条路径，“每年 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 时才会真正进入右下角。
ASF 是美国（Delaware）注册的 501(c)(3) 非营利组织，其运营适用美国法律。中国开发者贡献到 Apache 项目时：
如果你是项目外来贡献者，PR 被合并后你不会直接”触发”任何出口动作——是 ASF 以基金会身份对外分发，你只是”把代码交给基金会”。这一设计简化了个体贡献者的合规负担。相对的，Committer 和 PMC 作为基金会代理人，合规责任更大一些。
成为 Committer 之后，你获得的是对 ASF 基础设施的写权限。这不同于”贡献公开代码”：
people.apache.org
的个人页登记所在国家，以便基金会在需要时快速评估；committer-info，而不是等到基金会查出”某位
Committer 现在在制裁地区工作”才被动处理。对中国 Committer / PMC 的建议：
xxx@huawei.com）作为唯一联系方式，用个人邮箱（Gmail
/ ProtonMail /
自建）在基金会内做联络，可以在雇主变更时保持身份稳定；实操建议：
近几年一个活跃的方向是：中国公司把自家的国密增强项目捐献到国际开源基金会。例如 Tongsuo（铜锁）早期在 GitHub 开源、后续引入多家企业共同维护；Apache 的部分 Committer 在 PMC 决策中讨论过”国密支持是否进入主线”。从出口合规角度看：
这套路径既满足了”真正国际化”，也不牺牲”中国境内合规”。对想把国产基础软件推向全球的团队，值得参考。
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
模板，本身就是对项目合规姿态的最小成本表达。
阿里云 Alibaba Cloud 在法兰克福、伦敦、迪拜、吉达、利雅得、雅加达等地设有 region。出海合规的核心动作：
华为云 Huawei Cloud 由于 2019 年 Entity List 事件，更早建立了一整套多国合规体系：
非基础设施云之外，内容 / 社交类应用出海也会遇到加密合规：
这些公司本身虽不是开源基金会，但他们贡献的开源项目（OpenJDK Dragonwell、Kuasar、OceanBase、ByConity 等）在 release 时会带上对应 ECCN 说明，某种意义上也是”基金会级别”的合规姿态。
对三五个人的出海创业团队，给不起一支合规团队，可以按这个优先级处理：
这两家的经验对中小出海团队的启示：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） |
典型做法：在 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 就绕过）。
ICLA / CCLA（见本系列第 18 篇）通常要填写国家 / 地址。工程上可以：
对于涉及加密、涉及海外客户的项目，发布前对 git 仓库做一次审查：
grep -ri "aes\|rsa\|ecdsa\|sm2\|sm3\|sm4" --include='*.go' --include='*.c' .
列出加密算法出现位置；*.pem、*.key、id_rsa
等文件，确保没有把生产密钥 / 客户密钥误 commit；这是
security 与 compliance 交叉的高危点。# 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”，由合规评审兜底。
在 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，是从”靠人记忆”迈向”靠流程”的关键一步。
推荐每个出海项目在仓库根目录放一份
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>`.把类似文档放在仓库中，一次性解决用户、律师、合规审计员的大部分疑问。
对中国发起的出海开源项目，通常建议的发布拓扑：
关键原则：不把任何”唯一的关键节点”放在可能被单边切断的服务商上。同时也不把任何”唯一的关键节点”放在仅境外服务商上——中国用户的体验和全球用户的体验要同时保障。
当真正发生合规事件（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 的项目比没有的项目，在舆论和法律两端的表现都会稳得多。
数据跨境（cross-border data transfer）是另一条平行的合规线。在中国，《个人信息保护法》（PIPL）、《数据安全法》（DSL）、《关键信息基础设施安全保护条例》（CII）都有对”重要数据”出境的限制。与出口管制的关系：
中国数据跨境合规的具体做法（PIPL 标准合同、安全评估、认证机制三条路径）不在本文范围，推荐另起专题阅读。
下面是常见的”踩过才知道”的坑：
EXPORT_COMPLIANCE.md 或 ECCN Matrix，release
notes 保持简洁。把全文的操作压缩成一张问答表：
Q：我的项目不含任何加密算法，也不在 CCL 其他条目。 A：归 EAR99，公开发布可走 §734.3(b)(3)。避免向制裁国 / SDN 出口即可。不需要走 TSU 通知。
Q：我的项目含加密，源代码公开发布在
GitHub。 A：5D002 + §740.13(e) TSU。请发一封 URL
通知给 crypt@bis.doc.gov 和
enc@nsa.gov（抄送项目 Maintainer
邮件列表存档）。移站时补通知。
Q：我的项目含加密，是商业闭源 SDK，向海外客户出售。 A：做 self-classification 或 CCATS 分类；走 §740.17 ENC；年度 self-classification report + 半年度 sales report；不向 E:1 / E:2、SDN、Entity List 出口；部分国家可能还需要当地加密进口备案。
Q：我的项目由中国公司主导，想捐献到 Apache / CNCF。 A：可以。按基金会流程走孵化。涉及加密算法时，注册 ECCN Matrix；中国籍贡献者身份不影响 Committer / PMC 资格（前提是不属于被制裁实体）。
Q：我所在公司被列入 Entity List。 A：贡献 / 使用公开发布的开源源码不受影响；使用 GitHub / AWS 等”service”部分可能受限；请咨询公司合规部门。个人身份下参与开源一般不受限（以个人而非公司身份贡献）。
Q：我的项目想集成国密算法给海外客户使用。 A：国密开源实现出海后仍被美国视角归为 5D002 下的通用加密，须走 TSU 或 ENC；同时目的国可能有加密进口 / 算法认证要求（如俄罗斯 FSB、法国 ANSSI）。
Q：我收到一个来自伊朗 IP 的 PR。 A：合并公开代码本身属 EAR 豁免范围；但如果该贡献者被 OFAC 单独列入 SDN，或代表被制裁实体，需拒绝并记录。单凭 IP 不能判断，建议与法务共同评估。
Q：我想把服务部署到中东客户。 A：筛查客户是否在 SDN / Entity List；评估是否涉及受限最终用途；检查 SaaS 本身的 ECCN；若涉及加密商业软件，走 ENC 或许可证路径；并考虑当地数据保护法规。
Q：我在海外研究所工作，想以个人身份给 OpenHarmony 这样的中国主导项目贡献代码。 A：只要项目本身的贡献者协议不把你排除在外，并且你贡献的是源代码而非具体的军用技术，就是合法的。但要注意：你所在国家可能有针对特定中国受限实体的”逆向”限制，如果 OpenHarmony 背后的某个法人被列入该国名单，理论上有风险；实际上中国主导项目对海外贡献者始终持欢迎态度。
Q：我的项目在 GitHub，突然哪天 GitHub 因政策不得不限制中国大陆访问，我应该怎么办？ A：提前做好镜像（Gitee / GitCode / Codeberg / 自建 Gitea），至少保障代码、release、文档三处多点；对于 CI，把关键密钥放在你自己的 secret manager 而不是绑死在某一家 CI Provider。这个问题更多是韧性工程问题，而不是合规问题。
Q：我的 AI 开源项目用的模型权重，算不算”软件”？ A：截至目前，美国对 AI 模型权重的出口管制尚在动态变化中（2024–2025 年有多轮规则制定）。一种保守姿态：把”权重”与”代码”分开 release，并在权重发布时注明训练数据与用途限制。
Q：我想做一个完全不涉及加密的小工具，SaaS 化卖到全球。 A：EAR99 + 公开可用使得代码分发不受限，但 SaaS 本体仍然是 service，需要对注册用户做 OFAC 筛查；账单系统一般会捆绑这项能力（Stripe / Paddle 等会自动拒绝制裁地区信用卡）。
Q：我是独立开发者，完全没时间研究这些。 A：最低成本路径——项目完全开源（选 Apache-2.0 或 MIT）发布在 GitHub；涉及加密就发一封 TSU 邮件；付费接入 Stripe / Paddle；不要自己做海外银行账户 + 现金交易。这样做完，绝大多数风险都被平台和豁免吸收掉了。
Q：我以个人名义贡献过一些加密相关代码给某 US
项目，现在要入职某家被列入 Entity List
的中国公司，是否需要做什么？
A：个人历史贡献不受影响。入职后以该公司员工身份与该 US
项目的交互（例如以 @corp-email
提交、代表公司出席技术会议）则应由公司法务评估。个人继续以私人邮箱贡献通用代码通常没问题，但涉及敏感技术细节的互动需要谨慎。
本文为工程参考，不构成法律意见。涉及具体法律风险请咨询专业法律顾问。
最后，给一个”现实主义”的总结：
对于 95% 的中国开源开发者，你真正要做的事不多：
README.md 或
EXPORT_COMPLIANCE.md 里声明 ECCN；剩下 5% 的场景（强加密商业 SDK、政府客户、军工相关、受限实体合作）才需要专业律师介入。把精力花在对的地方，合规就不是负担，而是出海的基础能力。
法规与官方文件
基金会与平台声明
事件与新闻报道
本系列其他文章
延伸阅读
上一篇：CLA、DCO 与贡献者协议 | 下一篇：开源战略：什么时候开源、选哪个协议、如何构建商业壁垒
把当前热点继续串成多页阅读，而不是停在单篇消费。
2026-04-22 · architecture / opensource
面向工程团队的开源许可证完整操作手册：许可证选型决策树、LICENSE/NOTICE/SPDX 文件写法、第三方依赖声明、CI 自动化检查、发布物合规标注，以及六套真实可复制的项目结构模板。
2026-04-22 · architecture / opensource
面向中国工程团队的开源许可、版权与合规系列。从 GPL、AGPL、Apache、木兰协议到中国真实案例、SCA/SBOM 工具链与出海合规，讲清楚开源在工程落地中的坑与方法。
2026-04-22 · architecture / opensource
从 MIT 到 AGPL，从 SPDX 标识符到 OSI 认证：一篇讲清楚四类开源许可证的边界、兼容性矩阵、SSPL/BSL 的争议、Commons Clause 事件，以及工程里最常见的踩坑场景和选型建议。
2026-04-22 · architecture / opensource
深入对比 MIT、BSD 家族与 Apache 2.0 的条款差异：NOTICE 文件义务、专利授权、重新授权权利；BSD advertising clause 的历史与废除；ISC 许可证的关系；以及阿里、腾讯、字节内部为何强烈推荐 Apache 2.0 的工程原因。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。