从自由到主权
2026
1985 年 3 月，一本名叫《Dr. Dobb’s Journal》的程序员杂志刊出一篇长文。署名是 Richard Stallman，时任麻省理工学院人工智能实验室的程序员。文章的题目是《GNU Manifesto》1。
那一年 Stallman 三十二岁。他刚刚从 MIT AI Lab 辞职，理由不是他找到了更好的工作，而是他要确保自己写的代码不会被 MIT 当作专利出售。一年前，1984 年 1 月，他正式开始 GNU 项目——一个目标完全公开、完全免费、与 Unix 兼容的操作系统2。
GNU 这个缩写有它自己的笑话：它代表 GNU’s Not Unix——一个递归的名字，承认自己是 Unix 的模仿者，又强调自己不是 Unix。这个笑话不重要。重要的是它代表了一种立场。当时 Unix 已经从早期 AT&T 贝尔实验室的免费学术工具，变成了一个被严格许可、按 CPU 收费、源代码受保密协议保护的商业产品。Stallman 不接受这种转向。
《GNU Manifesto》开头的几句话已经写得很清楚：
“GNU, which stands for Gnu’s Not Unix, is the name for the complete Unix-compatible software system which I am writing so that I can give it away free to everyone who can use it.”
注意这里的“free”——Stallman 很快就开始反复强调，“free” 不是“免费”，是“自由”。在他后来的演讲与文章里，他用了几十种方式重复这个区分。一个经常被引用的句子是：“Free as in freedom, not as in beer”——不是免费啤酒的免费，是言论自由的自由3。
这个区分本身不是技术问题。这是一个政治姿态。Stallman 相信，软件用户对自己使用的软件有四项不可剥夺的权利——使用它、研究它、修改它、再分发它。专有软件违反了这四项中的至少三项。所以专有软件不只是商业模式问题，是道德问题4。
1985 年 10 月，Stallman 在波士顿成立 Free Software Foundation。这是一个 501(c)(3) 慈善机构，目标是为 GNU 项目筹款、买硬件、雇程序员。这个机构存在的前提是相信：自由软件本身是公共善，需要有组织地推动5。
整个 1980 年代后半叶到 1990 年代前半叶，FSF 与 GNU 项目都被主流软件行业视为一种边缘的乌托邦。IBM、Microsoft、Apple、Sun、Oracle 都视 Stallman 的“四项自由”为商业模式的根本威胁。当 Stallman 1989 年写出 GPL（GNU General Public License）的第一版时——一份要求“所有衍生作品也必须开放”的许可证——主流商业律师称其为“病毒”6。
GPL 的特殊性在于它的“copyleft”机制。普通的版权保护原作者；GPL 反过来保护使用者：任何使用 GPL 代码的衍生作品，必须以同样条款开放源代码。这是一种用法律工具反向使用版权制度的做法——Stallman 称之为“用主人的工具拆掉主人的房子”。
这是开源的第一种形态：自由软件。它的逻辑是道德的，立场是反企业的，姿态是对抗性的。它不试图说服任何公司——它试图建立一个不依赖任何公司的备援系统。
到了 1990 年代后半叶，事情开始变化。
1991 年，芬兰赫尔辛基大学的一个二年级学生 Linus Torvalds 在 comp.os.minix 新闻组贴出一条消息，标题大致是“我在写一个免费的操作系统（只是个爱好，不会大）”。这就是 Linux 的开始。Linus 当时没有 Stallman 的政治议程——他只是想要一个能在自己的 386 PC 上跑的、像 Unix 一样的系统7。
但他做了一个关键选择：把 Linux 用 GPL 许可。这个选择把 Linux 接入了 Stallman 已经建立的 GNU 工具链（GCC 编译器、GNU C Library、GNU Bash 等）。从此 Linux 不只是一个操作系统内核，而是与整个 GNU 生态绑定的“GNU/Linux”——这是 Stallman 一直坚持的正确名称，虽然在主流话语中“Linux”已经赢得了简称权。
到 1995 年前后，GNU/Linux 已经能跑大部分 Unix 软件。它在大学和研究机构里被广泛使用，但在企业市场仍然边缘。一年后 1996 年，Netscape 的浏览器市场份额开始被 Internet Explorer 蚕食。Netscape 公司开始考虑一个极端的反击：把自己的浏览器源代码全部开源。
1998 年 1 月 22 日，Netscape 宣布开源 Mozilla 源代码。这是当时最大的商业公司第一次主动把核心产品开源8。
这个事件让一群人意识到：他们需要一个新的名字。
1998 年 2 月 3 日，在 Palo Alto 的一次会议上，Eric Raymond、Bruce Perens、Linus Torvalds 等人聚在一起讨论。在场的 Christine Peterson（一位 nanotech 研究者）提出了一个新词：Open Source。这个词不带 Stallman 那种道德姿态。它强调的是开发模式的优越性——“多人合作、快速迭代、bazaar 而非 cathedral”。它把开源运动从一种政治立场，重新包装成一种商业可接受的方法论9。
1998 年 2 月底，Open Source Initiative 在 Palo Alto 成立。Eric Raymond 任首任 President，Bruce Perens 任副 President。初始董事包括 Brian Behlendorf（Apache 创始人之一）、Ian Murdock（Debian 创始人）、Russ Nelson、Chip Salzenberg10。
OSI 公布的“Open Source Definition”是 Bruce Perens 此前为 Debian 写的“Free Software Guidelines”的修改版。两个文件在技术层面几乎完全一致，但在哲学层面已经分裂：
Stallman 不接受这个转向。他后来反复批评 OSI 把开源运动“道德上抽空”。但更年轻的一代——包括 Bruce Perens 自己——觉得这个抽空是必要的代价。如果想让 IBM、Oracle、Sun 拥抱开源，就不能用“四项自由”这种听起来像宗教信仰的话术。
这是开源的第二种形态：Open Source。它的逻辑是务实的，立场是商业可接受的，姿态是合作性的。它愿意接受大公司的赞助、董事会席位、影响力。它相信“如果开源更好，市场就会选择它”。
接下来的十年——从 1998 到 2008——是开源在商业层面取得决定性胜利的十年。
1999 年 3 月，一群 Apache HTTP Server 的维护者成立了 Apache Software Foundation。这个基金会注册在 Delaware，是一个 501(c)(3) 慈善组织。它的存在是为了给 Apache HTTP Server 这种“靠多人邮件协作维护”的项目提供法律保护——让贡献者的代码版权能被集中管理，让公司能放心使用11。
Apache HTTP Server 那时候已经是世界上部署最广的 Web 服务器。在 2001 年 5 月，Apache License 2.0 发布。这份许可证有两个对企业极其友好的特点：它允许专有衍生作品（不像 GPL 要求开源），它明确处理专利授权（不像旧的 BSD 许可证留下灰色地带）。Apache 2.0 后来成为云时代最重要的开源许可证之一——Kubernetes、TensorFlow、PyTorch、Apache 旗下几乎所有项目都用它12。
2000 年 12 月，IBM 宣布投资 10 亿美元到 Linux 上。这是大公司第一次明确把开源当作战略平台。这笔钱不是捐款——它是 IBM 给自己工程师做 Linux 开发的工资、买服务器的钱、做营销的钱、打官司的钱。但效果一样：Linux 从此有了一个一万亿美元市值公司的全身投入13。
2007 年，Open Source Development Labs 和 Free Standards Group 合并，成立 Linux Foundation。这是一个 501(c)(6) 贸易协会，注册在加州（后来迁到 San Francisco / Delaware）。它的主要资助方是 IBM、Intel、Google、Oracle、Cisco——后来还有 Microsoft。截至 2023 年，Linux Foundation 年度营收 $1.96 亿美元，员工 298 人14。
这个数字本身就说明问题。Linux Foundation 不是一个程序员社区——它是一个具有相当规模的机构，拥有事业部、市场部、法务部、合规部。它管理着包括 Linux Kernel、Kubernetes、PyTorch、CNCF（Cloud Native Computing Foundation）、Hyperledger 在内的近一千个项目。它的存在是开源企业捕获阶段的物质化结果15。
Microsoft 的转向也发生在这个阶段。2001 年时任 CEO Steve Ballmer 公开把 Linux 称为 “cancer”（癌症）。2014 年新 CEO Satya Nadella 上任，公司话术彻底改变：“Microsoft loves Linux”。2018 年 6 月，Microsoft 用 75 亿美元收购了 GitHub——全球最大的开源代码托管平台16。
这个收购在当时引起了很多担忧。但实际效果是 Microsoft 大幅扩展了 GitHub 的免费功能，承诺继续保持中立。在很多开源运动的老兵看来，这恰恰证明了开源已经赢了——连 Microsoft 这样的“老敌人”都不得不拥抱它。但他们没意识到的是，赢下 Microsoft 同时也意味着把开源最大的协作平台交到了一家美国上市公司手里。
这是开源的第二阶段的结束：到 2018 年，开源已经完全胜利。但胜利的方式是把自己嵌入大公司的法律实体之中。Linux Foundation 在美国，Apache Foundation 在美国，Eclipse Foundation 在美国（注册地是 Delaware），后来又有了 Brussels 的欧洲子机构，CNCF 是 Linux Foundation 的子项目，Mozilla Foundation 在美国，OSI 在美国。几乎所有开源治理实体都在美国法律管辖之内。
2014 年是一个转折点。
那年 3 月，俄罗斯吞并克里米亚。美国和欧盟随即对俄罗斯实施第一波制裁——包括把一系列俄罗斯个人、公司列入 OFAC SDN（Specially Designated Nationals）list17。
OFAC（Office of Foreign Assets Control，外国资产控制办公室）是美国财政部下属机构。它维护的 SDN list 上的实体被禁止与美国人或美国注册公司进行任何交易。这个法律工具在 2014 年之前主要用于金融制裁——禁止美国银行处理 SDN list 上的账户。但它的法律适用范围在理论上覆盖一切——包括软件分发、技术服务、源代码托管。
2014 年那时候，GitHub 还是一家旧金山的中型创业公司。它注册在美国，所以理论上受 OFAC 约束。但实际执行很松散——GitHub 的工程师懒得追究每个用户的 IP 地址在哪里。
同一年 4 月，另一件事发生：OpenSSL 中的 Heartbleed 漏洞被公开18。这是当时被发现的最严重的互联网安全漏洞之一。它影响全球大约 17% 的“安全”网络服务器——大约 50 万台。漏洞的技术细节我们留到下一章详细讲。这里只需要知道两个事实。
第一，OpenSSL 是全球大部分 HTTPS 加密的基础。当时全世界的电商网站、银行网站、邮箱服务，绝大多数都依赖 OpenSSL 做 TLS 握手。
第二，在 Heartbleed 公开之前，OpenSSL 只有一个全职维护者——Stephen Henson——一个人审核了项目超过 45 万行代码的一半以上。整个 OpenSSL 项目的年度捐款总额大约是 2000 美元19。
OpenSSL Software Foundation 的主席 Steve Marquess 在 Heartbleed 公开后接受 The Register 采访时说了一句话，后来被反复引用：
“The mystery is not that a few overworked volunteers missed this bug; the mystery is why it hasn’t happened more often.”20
这句话很重要。它在 2014 年 4 月第一次公开承认了一个之前没人愿意公开承认的事实：现代互联网的关键基础设施大部分是被几个志愿者维护的。这些志愿者拿很少的钱或不拿钱，没有商业支持，没有 incident response 团队，没有 24 小时 on-call，没有专门的安全审计。但他们的代码被部署在数以千万计的服务器上。
2014 这两件事——克里米亚 + Heartbleed——是开源进入第三阶段的双重信号。克里米亚揭示了“国家可以通过制裁穿透开源协作”；Heartbleed 揭示了“如果国家想要利用关键基础设施的脆弱，那里有大量目标”。
接下来十年发生的所有事——GitHub 2019 年对伊朗的封锁、2018 年 Microsoft 收购 GitHub、2019 年 RISC-V 国际基金会迁瑞士、2020 年中国 OpenAtom 成立、2021 年 Log4Shell、2022 年 Sovereign Tech Fund 成立、2024 年 xz 后门、2024 年 Linux 删除 11 名俄籍 maintainer——都是这两个信号的延伸。
要理解为什么 2014 年成为转折点，得先看一下 2014 年之前的几个事件。
1999 年 5 月 6 日，美国第九巡回上诉法院在 Bernstein v. United States 案中做出了一个判决：源代码受第一修正案保护21。
这个判决的背景是这样的。1990 年代美国政府仍然把加密软件视为“军用品”——受 ITAR（International Traffic in Arms Regulations，国际武器贸易条例）管制。要把加密软件源代码送出美国，理论上需要申请武器出口许可证。Daniel Bernstein 当时是 UC Berkeley 的数学博士生，他写了一个加密程序叫 Snuffle，想公开发布。他向商务部申请，被告知必须先注册为武器商人。他起诉政府22。
九年的官司之后，第九巡回法院的判决说：源代码是一种“言论”。它表达想法、传递信息、可以被读者理解。所以它受第一修正案保护。政府不能强制开发者在公开源代码之前申请许可证。
这个判决从那以后成为美国对待开源软件出口管制的法律基础。在很长一段时间里，它意味着：源代码可以自由跨境流动，加密软件可以被开源、可以被讨论、可以被发表。1991 年 Phil Zimmermann 写出 PGP 之后被联邦调查的故事就发生在这个判决出来之前——Zimmermann 当时差点被起诉违反武器出口法。他的支持者们用了一个聪明的办法：把 PGP 源代码印成书，由 MIT 出版社发行23。书是受第一修正案保护的“印刷出版物”，国会不能限制它跨境流通。司法部最终撤销了对 Zimmermann 的调查。
Bernstein 案把这个“书 vs 软件”的区分彻底抹平。1999 年之后，开源软件在美国的法律地位变得相对清晰——它是受保护的言论。
但 Bernstein 案没有解决另一个问题：deemed export（视同出口）。这是 EAR（Export Administration Regulations）下的一个学说。它说：如果你在美国土壤上向一个外国人传授某些受管制的技术或源代码，这就被“视同”出口到了那个外国人的母国24。
这个学说听起来荒谬，但实际效果很强。如果一个伊朗博士生在美国大学的实验室里学习某种受 EAR 管制的加密技术，这等于把该技术“出口”到了伊朗——大学需要为此申请许可证。对绝大多数大学研究来说，这是不可承受的合规负担。所以“deemed export” 的实际效果是：受管制技术的研究只对美国公民和绿卡持有者完全开放。
在 1990 年代，这个学说主要影响军用密码学和核技术。但 2014 年之后，它开始扩展。2015 年时任商务部官员公开表示，“deemed export” 可能适用于 AI、量子计算、生物技术等“新兴技术”。这些技术里很多本身就是开源的。
这就引出了一个让 Stallman 三十年前不敢想象的问题：一份完全开源的、在 GitHub 上公开的源代码，能不能因为某些人不能“接收”它，而变得“违法”？
2019 年 7 月，GitHub 给出了第一个明确的实际回答。
2019 年 7 月底，几个 GitHub 用户突然发现他们的账号被限制了。
第一波报告来自伊朗。一个伊朗开发者在 Medium 上发了一篇愤怒的帖子：他的账号没有任何预警就被锁了，他甚至无法导出自己几年的代码25。接下来几天，叙利亚、克里米亚的开发者也开始报告类似情况。
GitHub 的 CEO Nat Friedman 公开承认了这件事。在一份声明中他说：GitHub 必须遵守美国出口管制法律，包括 OFAC 制裁。对于位于伊朗、叙利亚、克里米亚的用户，GitHub 关闭了私有 repo、付费账号、Marketplace 访问。公共 repo 仍然可读，但用户不能 push 代码26。
执行方式是基于 IP 地址和支付历史，不基于国籍或民族。一个在加州工作的伊朗裔美国公民不受影响——但一个在德黑兰工作的英国国籍工程师会被锁。这种识别方式有大量误伤：拉脱维亚的一些开发者被误识为俄罗斯地区27。一些到伊朗探亲的美国伊朗裔被临时锁定。一个住在克里米亚的乌克兰开发者——他是因为克里米亚被吞并才“变成”被制裁地区——给项目维护者写公开信，说他可能无法继续维护 GameHub 这个项目。
GitHub 后来获得了 OFAC 的一项 license，允许向伊朗个人开发者提供服务（但仍排除政府和被制裁实体）。这缓解了部分误伤，但没有改变结构性事实：一个美国注册的私营公司，必须按照美国法律决定哪些开发者可以使用它的服务28。
GitHub 不是孤立案例。SourceForge、Atlassian Bitbucket、GitLab.com、Docker Hub——所有美国注册的开源基础设施服务都面临同样的法律义务。这些公司多年来对 OFAC 的执行非常松散，但 2018 年 6 月 Microsoft 收购 GitHub 之后，作为一家大型上市公司，Microsoft 的合规要求更严。GitHub 2019 年的封锁可以理解为 Microsoft 合规压力的直接结果。
这就是开源进入第三阶段的标志性事件。开源运动几十年来相信“代码是全球公地”——它不属于任何国家、不受任何政府控制。但 2019 年 GitHub 的行动证明：当代码的协作基础设施被一家美国公司拥有时，全球公地的概念就被穿透了。一个伊朗开发者贡献给一个开源项目的代码，可能被技术上拒收——不是因为代码本身有问题，是因为开发者所在的地理位置违反了某个政府的法律。
接下来五年的事件可以理解为这个穿透过程的精细化。
2019 年 11 月，RISC-V 国际基金会（当时叫 RISC-V Foundation）宣布从 Delaware 迁到瑞士29。RISC-V 是一个开放的指令集架构——理论上不应该被任何政府管制。但 RISC-V Foundation 的董事会担心：如果美国政府决定把 RISC-V 列为“管制技术”，那么所有在美国注册的基金会成员都必须遵守。迁到瑞士可以让基金会本身免受美国法律管辖——虽然成员公司仍然受其本国法律管辖。
这是一次主权避险：基金会的所在地决定了它受谁的法律约束。
2020 年 6 月，中国成立 OpenAtom 开源基金会30。这是中国第一个真正意义上的开源软件基金会。发起方包括阿里、百度、华为、浪潮、奇虎、腾讯、招商银行。它的政治意义远超它的技术规模：它是中国对“几乎所有开源治理实体都在美国”这个现实的直接回应。
2021 年 11 月，华为把 EulerOS（一个基于 CentOS 的服务器 Linux 发行版）捐赠给 OpenAtom，更名为 openEuler31。这跟 Meta 2022 年把 PyTorch 捐赠给 Linux Foundation 在形式上类似——都是把企业项目“中立化”到基金会层面。但政治含义不同：openEuler 进入了一个中国注册的基金会，PyTorch 进入了一个美国注册的基金会32。
2021 年 12 月，Log4Shell 漏洞被公开。Log4j 是一个 Java 日志库，被全球几乎所有大型 Java 应用使用——包括 Apple iCloud、Twitter、Steam、Minecraft、亚马逊 AWS、阿里云。当时 Log4j 由三个人志愿者维护。其中之一 Ralph Goers 是 Log4j 的初始作者，但他的全职工作在另一家公司——他维护 Log4j 是用业余时间33。
这是 Heartbleed 故事七年之后的同样剧情。基础设施 critical，维护者孤独，发现漏洞靠运气。Heartbleed 之后成立的 Core Infrastructure Initiative 没能阻止 Log4Shell；Log4Shell 之后成立的 OpenSSF Alpha-Omega Project（2022 年 2 月，Microsoft + Google 投入 500 万美元）也没能阻止 xz34。
2022 年 2 月俄罗斯入侵乌克兰。新一轮制裁开始。GitHub 这次的执行比 2019 年精确——它没有对俄罗斯境内所有用户广撒网，而是针对被制裁的俄罗斯具体公司（Sberbank、Gazprom、被制裁的国防工业实体）。但效果仍然显著：俄罗斯企业开始大规模迁移到自托管 GitLab，本土 forge 平台 GitFlic 用户增长，俄罗斯政府发布 Decree 166 要求关键信息基础设施必须使用本土软件35。
2022 年 5 月，德国联邦议会拨款 350 万欧元每年成立 Sovereign Tech Fund（后改名 Sovereign Tech Agency）。这是一个直接资助关键开源项目的政府机构。它资助的项目包括 cURL、Drupal、Gnome、openSSH、systemd 等。到 2023 年底它已经支持了 40+ 个关键开源项目36。
这是一个新的现象：政府直接资助开源维护者。在 Stallman 1985 年的设想中，“自由软件”是反企业的；它没有想象过反国家。但 Sovereign Tech Fund 不是反国家——它就是国家。德国政府决定开源基础设施的稳定属于国家利益，所以它直接投钱进去。法国、荷兰、欧盟整体后来都跟进了类似项目。
到 2024 年，事情已经走到一个不可回避的地步。
2024 年 3 月 29 日，一个叫 Andres Freund 的工程师在 oss-security 邮件列表发了一封信。他在做 PostgreSQL 性能测试时，发现 SSH 登录时间从 100ms 增加到 500ms。他追踪到 liblzma——也就是 xz Utils 这个压缩库——里面有恶意代码。他报告了这件事37。
接下来几天的调查揭示了一个事实：在过去三年里，一个或多个使用 “Jia Tan” 身份的人通过精心设计的社会工程，逐步成为 xz Utils 的 co-maintainer，并在 2024 年 2 月把后门嵌入了 5.6.0 release。这个后门可以让攻击者绕过 SSH 认证直接执行代码。如果不是 Freund 因为性能测试偶然发现，它已经会被 Debian、Ubuntu、Fedora、Arch Linux 的下一个稳定版本集成到全球数十亿台 Linux 服务器上38。
xz 后门是这本书的第四章的核心案例。这里只需要知道一件事：它代表了开源进入第三阶段的最完整体现。一个国家级行为者投入了至少三年的时间、多个 sock puppet 账号、精心设计的施压和信任建立过程，目标是在一个被一位芬兰人单人维护的压缩库里植入一个能控制全球大部分 Linux 服务器的后门39。
它差点成功。它被发现是因为运气。
接下来七个月——2024 年 4 月到 10 月——这件事的余震在开源世界传遍。安全研究者重新审视了其他被单人维护的关键库；Linux Foundation 加大了对 maintainer 身份验证的考虑；CISA、NSA、各国安全机构都发布了关于 OSS 供应链威胁的警告。
2024 年 10 月 18 日，在这个余震的背景下，Linux 内核 stable 分支的负责人 Greg Kroah-Hartman 发送了一个 patch 到 LKML（Linux Kernel Mailing List）。这个 patch 从 MAINTAINERS 文件中删除了 11 个名字。Greg KH 的 commit message 只有两句话：
“Remove some entries due to various compliance requirements. They can come back in the future if sufficient documentation is provided.”40
被删除的 11 个名字几乎全部是俄籍 maintainer，多数关联到俄罗斯科技公司——Baikal Electronics、Yandex、Open Mobile Platform 等41。Baikal Electronics 是俄罗斯本土 CPU 厂商，2022 年俄乌战争后被列入 OFAC SDN list。其他几家也在 SDN list 上，或被 SDN list 上的母公司控制。
邮件列表上立即有人质疑。Geert Uytterhoeven（一位长期 Linux 开发者）问：什么是 “compliance requirements”？什么是 “sufficient documentation”？后续邮件中 James Bottomley（受雇于 IBM 的 Linux maintainer）给出了精确回答：
“如果你的公司在 U.S. OFAC SDN list 上，受 OFAC 制裁项目约束，或被 list 上的公司拥有/控制，我们与你的协作能力将受限，你不能出现在 MAINTAINERS 文件中。”
10 月 23 日，Linus Torvalds 出面表态：
“The change was done clearly, it’s not getting reverted, and multiple random anonymous accounts trying to reverse it wouldn’t change anything.”42
Linus 在同一封邮件里也表达了个人立场——他不接受俄罗斯入侵乌克兰，所以他个人也支持这个合规决定。但他强调：核心不是个人立场，是法律合规。Linux Foundation 是美国注册的非营利组织，它必须遵守 OFAC 制裁。
这件事的标志性不在于它前所未有——GitHub 2019 年的封锁早就证明了同样的逻辑。它的标志性在于它发生在 Linux 内核的 MAINTAINERS 文件里——这是开源世界最古老、最受尊重、最具象征意义的“贡献者名单”之一。当 11 个名字因为合规要求被从这份名单上删除时，开源运动用了四十年小心保持的姿态——“代码不分国界”——就在那一刻被官方否定了。
代码不分国界。但 maintainer 分国界。基金会注册地分国界。OFAC SDN list 分国界。
把 1985 年的 GNU 宣言和 2024 年的 Greg KH 邮件放在一起读，会让人不舒服。前者是一个三十二岁的程序员写的、充满道德激情的、关于自由的宣言。后者是一个 Linux 维护者写的、两句话的、技术性合规通知。
但如果只看到这两个文件之间的距离，就会错过这本书想说的东西。
这本书要说的不是“开源死了”。它没死。Stallman 仍然活着，仍然在写关于自由软件的文章。Linus Torvalds 仍然在维护 Linux。Apache Foundation 仍然在运作。CNCF 仍然在管理 Kubernetes。GitHub 上每天有几百万个 commit。世界上没有任何其他代码协作模式比开源更成功。
但 2024 年 10 月 18 日的事件揭示了一件事：开源运动相信了四十年的“代码作为全球公地”的姿态，在结构上已经无法维持。原因不是任何人的恶意。原因是开源的所有治理实体——Linux Foundation、Apache、CNCF、PyTorch Foundation、GitHub——都注册在某个国家。被注册的实体必须遵守注册地法律。当注册地的法律开始把代码协作纳入国家安全考量时，开源就不可能保持中立。
这不是美国一家的事。中国 2020 年成立 OpenAtom 是同样的逻辑：它要确保自己有不依赖美国法律实体的开源基础设施。俄罗斯 2022 年要求关键基础设施迁到本土软件是同样的逻辑。欧盟 2024 年通过 Cyber Resilience Act 是同样的逻辑。各方都意识到了：开源已经不再是中性技术，是国家能力的一部分43。
接下来这本书的十一章，会一步一步把这个图景展开。第二章讲法律层面：从 Bernstein 案的“代码是言论”到今天 AI 模型权重的不解决状态。第三章讲基础设施的脆弱：Heartbleed、Log4Shell、xz 的三次警告，每次间隔在缩短。第四章是核心：xz 后门的完整技术与社会工程过程，让一个读者真正“看懂”国家级 OSS 供应链攻击长什么样。第五章是人物：维护者的具体面孔。第六章讲制裁穿透：GitHub 2019 和 Linux 2024 的完整故事。第七到第十一章讲各国战略、关键项目、可验证供应链、平行生态、AI 模型权重。第十二章是收束。
不论哪一章，都建立在一个判断上：开源仍然是开源——你仍然能 fork、clone、读源代码。这是 1985 年 Stallman 创造的，是 1998 年 OSI 推广的，是 2014 年的 Heartbleed 之后还在维持的。这种根本属性，今天仍然让 Iran、Cuba、Crimea 的程序员能继续工作。它不是过时的乌托邦——它是这个世界上仍在运行的少数几个全球公地之一。
但它运行的全球协作秩序，正在被切割。这个切割不是一夜之间的事；它是从 2014 年开始、到 2024 年达到一个不可回避的临界点的过程。理解这个过程，才能理解 2024 年 10 月 18 日 Greg KH 邮件里那两句话——“由于多种合规要求”——为什么是 1985 年 Stallman 写《GNU 宣言》时绝对没法想象的。
The GNU Manifesto, Richard Stallman, Dr. Dobb’s Journal, March 1985. GNU Project page
Wikipedia: GNU Manifesto. Link →
Richard Stallman, “Free Software, Free Society: Selected Essays”, FSF, 2002. PDF →
Free Software Foundation, “What is Free Software?”, FSF official page. Link →
FSF History, Free Software Foundation. Link →
Wikipedia: GNU General Public License. Link →
Linus Torvalds, “Just a hobby, won’t be big and professional like gnu”, comp.os.minix, 1991-08-25. Now archived in multiple places including Linux Foundation history pages.
Wikipedia: Netscape (web browser). 1998 年 1 月 22 日 Netscape 宣布开源 Mozilla 源代码。Link →
History of the Open Source Initiative, OSI. Link →
Wikipedia: Open Source Initiative. Link →
ASF History Project Timeline. Link →
Wikipedia: Apache License. Link →
ProPublica Nonprofit Explorer: The Linux Foundation, EIN 460503801. 2023 年 Form 990 显示营收 $196,026,148。Link →
Linux Foundation Annual Report 2023. 提到“welcoming 270 new members and approaching nearly 1,000 active projects”。Link →
Microsoft 2018-06 收购 GitHub 公告。多次重申“Microsoft loves Linux”立场。
U.S. Department of the Treasury OFAC: Specially Designated Nationals And Blocked Persons List. 2014 年以后多次更新。OFAC SDN page
Wikipedia: Heartbleed. Link →
Mend.io: “How The Heartbleed Vulnerability Shaped OpenSSL as We Know It”. Link →
The Register 2014-04-11: “OpenSSL Heartbleed: Bloody nose for open-source bleeding hearts”. 包含 Steve Marquess 引述。Link →
Wikipedia: Bernstein v. United States. Link →
EFF: Bernstein v. US Department of Justice case page. Link →
Wikipedia: Phil Zimmermann. 包括 PGP 源代码作为 MIT Press 出版物的故事。Link →
Bureau of Industry and Security: “What is a deemed export?”. Link →
TechCrunch 2019-07-29: “GitHub confirms it has blocked developers in Iran, Syria and Crimea”. Link →
GitHub Docs: GitHub and Trade Controls. Link →
Tom’s Hardware: “GitHub Blocks Iran, Syria and Crimea-Based Users”. 包括拉脱维亚误伤报道。Link →
Menabytes: “GitHub blocks partial access for developers in Syria, Iran and other countries under US sanctions”. Link →
The Register 2019-11-26: “RISC-V business: Tech foundation moving to Switzerland because of geopolitical concerns”. Link →
Wikipedia: OpenAtom Foundation. 成立于 2020 年 6 月，由阿里、百度、华为、浪潮、奇虎 360、腾讯、招商银行等共同发起。Link →
Caixin Global 2021-11-10: “Huawei Donates Operating System to Chinese Tech Nonprofit”. Link →
Linux Foundation 2022-09-12: “Meta Transitions PyTorch to the Linux Foundation”. Link →
Wikipedia: Log4Shell. 包括 “The Apache Log4j project is being maintained by three people who volunteer their time” 的细节。Link →
OpenSSF Press Release 2022-02-01: “OpenSSF Announces The Alpha-Omega Project”. Microsoft + Google 投入初始 500 万美元。Link →
Wikipedia: Astra Linux. 包括 Decree 166 强制国企迁移的描述。Link →
Sovereign Tech Agency (formerly Sovereign Tech Fund). Link → 与 Wikipedia: Sovereign Tech Agency。Link →
Wikipedia: XZ Utils backdoor. Link →
Russ Cox: “Timeline of the xz open source attack”, research!rsc. Link →
Securelist: “Social engineering aspect of the XZ incident”. Link →
LWN.net: “Several Russian developers lose kernel maintainership status”. 包含 Greg KH 的 LKML 邮件原文摘录。Link →
OSTechNix: “Several Russian Maintainers Removed From Linux Kernel”. Link →
The Register 2024-10-23: “Linus Torvalds affirms expulsion of Russian maintainers”. 包括 Linus 表态原文。Link →
Jamestown Foundation: “Open-Source Technology and PRC National Strategy: Part I”. 提供中国战略层面的分析。Link →
1991 年夏天，菲律宾马尼拉一家小印刷厂收到一笔奇怪的订单——印刷一本厚约 900 页的书，封面写着 “PGP: Source Code and Internals”。这本书没有传统意义上的章节、没有可读性的散文，从第一页到最后一页几乎全部是 C 语言代码。订购它的是麻省理工学院出版社（MIT Press）。
这本书的存在是为了一个目的：让美国联邦调查局没法起诉一个叫 Phil Zimmermann 的程序员1。
Zimmermann 那时候四十二岁，是科罗拉多博尔德的一个软件工程师。同年六月，他发布了一个叫 Pretty Good Privacy（PGP）的程序——第一个让普通人能用公钥加密保护邮件的免费工具。他通过 FTP 在互联网上公开发布了 PGP，包括完整源代码2。
PGP 在几个小时内被全世界下载。这在 1991 年是不寻常的——那时候 World Wide Web 还没有正式出现，下载主要靠 FTP 和 BBS。但密码学社区对这种工具的需求高得惊人。一个能让任何人加密通信、不依赖政府或大公司的工具，被一群人当作“密码朋克”梦想的实现。
但同样在那一刻，PGP 把 Zimmermann 推向了一场长达三年的联邦刑事调查。
美国当时把强加密软件视为“武器”。具体说，它属于 ITAR——International Traffic in Arms Regulations，由国务院管理的武器贸易条例。把武器出口需要许可证。Zimmermann 没有申请许可证就把强加密软件“出口”到了全世界——通过 FTP 在公开互联网上发布的方式。技术上这违反了 ITAR3。
1993 年，美国海关开始对 Zimmermann 进行刑事调查。如果指控成立，他可能面临数年监禁。这件事在密码学社区引起轩然大波——它把抽象的“加密自由”问题变成了一个具体的人身刑罚。
Zimmermann 的辩护团队（包括 EFF 的律师们）想了一个聪明的办法：印书。
美国宪法第一修正案保护出版自由。一本印刷的书无论内容是什么，受联邦政府限制出版的能力都非常受限。如果你能证明 PGP 源代码本质上是“印刷品”——只是恰好用 C 语言而不是英语——那它就受第一修正案保护。1995 年，MIT Press 出版了《PGP: Source Code and Internals》这本厚书。任何人可以买这本书，然后用 OCR（光学字符识别）软件把它扫描回可执行的源代码。这是一个法律上的诡辩，但有效4。
司法部最终在 1996 年悄悄撤销了对 Zimmermann 的调查。他们没有公开声明理由，但当时的解读是：他们不想在法庭上输掉“代码不是言论”的论点。
撤销 Zimmermann 调查没有解决根本问题。三年后，1999 年，另一个程序员让法庭直接做出了判决。
Daniel J. Bernstein 是 UC Berkeley 的数学博士生，研究密码学。他写了一个叫 Snuffle 的加密程序，想公开发布——发到 sci.crypt 新闻组、印在学术论文里、做演讲。他向美国国务院申请确认这能不能算作“出口”。国务院的回应：可以，但你需要先注册成“武器商人”（munitions dealer），然后申请武器出口许可证5。
Bernstein 起诉国务院。这场官司从 1995 年打到 1999 年。期间出口管制的归口从国务院转给了商务部（从 ITAR 转到 EAR），但争议本质没变：政府是否可以要求程序员在公开源代码之前申请许可证。
1999 年 5 月 6 日，美国第九巡回上诉法院做出判决。法官 Betty B. Fletcher 写的多数意见里包括这样几句关键论述：
“Cryptographers use source code to express their scientific ideas in much the same way that mathematicians use equations or economists use graphs … Source code is the preferred means of communication among cryptographers because cryptography is a highly technical and mathematically based field.”
因此源代码是“言论”——是一种受美国宪法第一修正案保护的表达形式6。
法院进一步说：政府要求程序员在公开源代码之前申请许可证，等于“事前审查”（prior restraint）——这是第一修正案最严格保护的对象。法院推翻了商务部对 Bernstein 适用的出口管制规则7。
这就是著名的 Bernstein 案判决。它的意义远超一个加密软件的具体争议。它在法律上确立了“代码 = 言论”的原则。1999 年之后，美国开发者公开发布开源软件不再需要担心被起诉违反武器出口法。整个加密时代——从 OpenSSL 到 Signal、从 HTTPS 到 WhatsApp 端到端加密——能够在美国土壤上发展起来，靠的就是这个判例8。
但 Bernstein 案没有解决另一件事：它只覆盖了“美国程序员把源代码贴到公开互联网”这一种情况。它没有覆盖一个更复杂的问题——如果一个伊朗博士生在 MIT 实验室里学习美国教授写的代码，这算不算“出口”到伊朗？
这个问题有一个专门的法律术语：deemed export（视同出口）。
EAR——Export Administration Regulations——是商务部下属机构 BIS（Bureau of Industry and Security，工业与安全局）执行的出口管制法律。它管制的“出口”不只是物理物品的跨境运输，也包括“技术”和“软件”的传递9。
EAR 把“deemed export”定义为：在美国土壤上，把受 EAR 管制的“技术”或“源代码”释放给一个外国人。这个释放被“视同”出口到了那个外国人的母国10。
具体形式包括：
实际效果：如果一个美国大学实验室在做某种受 EAR 管制的研究（比如某些加密算法、某些 AI 算法、某些核技术、某些生物技术），那么实验室不能让外国学生或外国访问学者接触相关的“技术”或“源代码”——除非大学申请并获得 deemed export 许可证。
这听起来很荒谬。如果一个伊朗博士生在加州伯克利学习一种 EAR 管制的加密技术，那么伯克利等于把这项技术“出口”到了伊朗。要合法做这件事，伯克利需要向商务部申请许可证——而对伊朗的许可证几乎不可能获批。
实际中存在一个重要例外：基础研究例外（Fundamental Research Exception）。如果某项研究是公开发表、非保密的“基础研究”，那么它不受 EAR 管制。大部分大学研究都属于这一类——所以大学的研究生院仍然能正常接收外国学生11。
但这个例外有限制。“基础研究”必须真的是基础研究——意思是没有公司赞助、没有政府保密协议、研究成果完全公开发表。一旦研究被某个公司的合同绑定，或者涉及政府机密，例外就消失。
到了 2014 年之后，EAR 的范围开始扩展。商务部开始把一些“新兴技术”列入管制清单——量子计算、先进半导体制造、特定的 AI 算法、合成生物学。这意味着越来越多的大学研究开始触及 EAR 边界。一个在 UC Berkeley 实验室做大模型训练的中国博士生，理论上可能涉及 EAR 管制的“技术”——如果他在某个 GPU 集群上训练某种特定模型，并且这种模型属于 BIS 后续定义的某个管制类别12。
实际操作中，这种灰色地带让大学的合规办公室、外国学生、研究 PI 都活在持续紧张中。已经出现过几起 deemed export 调查——多数针对中国籍研究者。最著名的是 2018 年起的几起对华人科学家的调查，多数最终因证据不足撤销或被法庭否决，但调查本身对当事人造成了长期影响。
Bernstein 案和 deemed export 学说之间有一个明显的不对称。
Bernstein 案处理的是“美国人把代码贴到公开互联网”。结论：这是受保护的言论，政府不能限制。
Deemed export 处理的是“美国人在美国土壤上向外国人传授技术”。结论：这可以被监管，需要许可证。
理论上这两个情况应该一致——如果代码是言论，那么向外国人传授代码也应该是受保护的言论。但 EAR 的实际执行没有这样的逻辑一致性。
为什么？因为这两种情况影响的是不同的国家利益。把代码贴到公开互联网，政府失去了对它流向哪里的精确控制——但这种“失控”是双向的，美国软件也因此能流向全世界。在美国土壤上向外国人传授技术，政府仍然有精确控制能力——它可以决定哪些外国人能进入美国、能进入哪些机构、能接触哪些项目。
这就是开源在第三阶段面对的法律基础矛盾。Bernstein 案保护了“源代码自由公开”；deemed export 学说限制了“源代码自由协作”。1999 年那时候这两个原则看起来是平衡的——你能发布代码但不一定能跟伊朗人一起开发它。在 2014 年之前，这种平衡基本能维持，因为大部分开源开发不需要刻意区分“贡献者来自哪个国家”。
2014 年之后开始变化。GitHub 2019 年的封锁、Linux 2024 年的删除——这些不是“代码不能贴到公网”，而是“代码协作不能跨过制裁边界”。Bernstein 案保护不了这些情况，因为它处理的是出版自由，不是协作自由。
到了 2023-2024 年，一个 Bernstein 案完全没有想到的新问题出现了：AI 模型权重算不算言论？
这个问题不像它表面那样简单。
一个深度学习模型——比如 Llama 70B、DeepSeek R1、Qwen 72B——是由几十亿到几千亿个浮点数（权重）组成的。这些数字不是程序员一个一个写出来的，是训练过程从大量数据中“学”出来的。一个完整的开放权重模型包括三部分：
前两部分是传统意义上的“源代码”——人写的、可读的、可修改的。第三部分不一样。模型权重是黑箱——你不能“读懂”它，不能通过看权重判断模型在做什么。它的功能性是 emergent，从训练过程中涌现出来的13。
那么 Bernstein 案的“源代码是言论”原则适用于模型权重吗？
法律学者已经开始辩论这个问题。一种观点是：模型权重当然是言论——它是表达智能的一种形式，是人类知识的编码。另一种观点是：模型权重不像源代码，它不是“为了让人理解”的——它的存在目的是让机器执行特定任务。它更像是一个工具，不是一个表达。
到 2026 年初为止，没有任何美国法院对这个问题做出判决。但美国政府已经开始按照“模型权重可以被管制”的逻辑行动。
2024 年 2 月，BIS 提出一个新的出口管制类别：4E091——“AI 模型权重”。具体规则到 2025 年 1 月发布，叫《Framework for Artificial Intelligence Diffusion》14。
这个 framework 的核心逻辑：
这是一个有趣的承认。BIS 实际上承认了：一旦一个开放权重模型被发布，它就像 Bernstein 案里的源代码一样——已经在互联网上散布，政府没法“收回”它。所以管制只对未来未发布的、超大模型有意义。
但这个让步没有解决另一个问题。联邦承包商（federal contractors）——任何为美国政府工作的公司——能不能使用已经发布的开放权重模型？
2025 年 1 月底，中国的 DeepSeek 公司发布 R1 模型。它在数学和推理 benchmark 上达到或超过 OpenAI 的 o1，但用的是较旧的 Nvidia H800 GPU（已经被出口管制限制了），并且完全开源（MIT License）16。
DeepSeek R1 在中文与英文社区都引起轰动。它似乎证明了：美国的芯片出口管制无法阻止中国 AI 进展。但它也很快引发美国政策反应。
2025 年 2 月，参议员 Bill Cassidy（路易斯安那共和党）和 Jacky Rosen（内华达民主党）联合提出 legislation：禁止联邦承包商在与联邦合同相关的任何活动中使用 DeepSeek 或它的后续模型17。
2025 年 4 月，众议院“对中国共产党战略竞争特别委员会”发布关于 DeepSeek 的报告，建议更新 FAR（Federal Acquisition Regulations）以禁止联邦政府采购基于中国模型的 AI 系统18。
2025 年 12 月，美国政府更新 AI 采购规则：联邦承包商被禁止使用中国 AI 模型。如果你是美国国防、医疗、公共基础设施领域的承包商，Qwen 和 DeepSeek 完全不可用19。
这意味着什么？意味着 BIS 在出口管制层面承认“开放权重模型已经在公地里”，但联邦采购层面通过另一条路径——你可以下载这些模型，但你不能用它们为美国政府工作——实质上把这些模型重新“领土化”了。
这是 Bernstein 案没有想到的情况。Bernstein 案保护了出版自由，但没有保护“使用自由”。一个 1999 年的法庭可能没有预见：未来一个开发者不只要担心代码能不能跨境流动，也要担心代码能不能被用于跨主权场景。
让我们把 1991 年 Phil Zimmermann 在墨西哥城印 PGP 源代码这件事，跟 2025 年 12 月联邦承包商被禁用 DeepSeek 这件事放在一起。
1991 年的情境：政府通过 ITAR 管制源代码出口。Zimmermann 用一本印刷书绕过这个管制，因为书受第一修正案保护。
2025 年的情境：政府通过 FAR 限制承包商使用已经全球公开的开放模型。这个限制不针对模型本身（你仍然能下载 DeepSeek R1），针对的是“在某些合同场景下使用”。Bernstein 案的言论自由保护不适用——因为政府没有禁止你下载，只是禁止你为它工作时使用20。
这是一个值得停下来的细节。三十四年间，管制的形式变了。1991 年管制源代码的“边界穿越”；2025 年管制的是“使用语境”。两种管制都不直接限制内容本身——但效果都是让特定主体在特定场景下不能使用特定代码。
这种“间接管制”在法律上比 Bernstein 案的“前置审查”更难挑战。前置审查直接禁止你出版——这是宪法明确保护的领域。间接管制只是说“你可以出版/使用，但不能在某个特定语境下”——这给政府留下了大量灰色地带。
而 Bernstein 案的“代码是言论”原则只覆盖前者，不覆盖后者。
更深一层的问题是：模型权重和源代码到底是不是同一种东西？
如果它们是同一种东西，那么 Bernstein 案的判决应该自然延伸——任何开放发布的模型权重都受第一修正案保护。
如果它们不是同一种东西，那么对模型权重的管制可以采用不同标准。
支持“是同一种东西”的论点：
支持“不是同一种东西”的论点：
这场辩论现在还在进行中。美国政府的实际行动倾向于把模型权重当作“工具”——可以被出口管制覆盖。但 NTIA 在 2024 年 7 月的报告里说，已经发布的开放权重模型应该用“监控”而不是“限制”来应对21。这是一种折中——承认 Bernstein 式的“已经发布无法收回”，但保留对未来发布的管制空间。
整个事情有一个让人想停下来的细节：DeepSeek R1 是用 MIT License 发布的。MIT License 是开源世界最宽松的许可证之一，不附带任何“道德”或“政治”条款。它的全部条款是：“这个软件按 as-is 提供，没有任何保证，作者不承担任何责任，你可以做任何事情。”22
按照 MIT License 的字面文义，美国政府承包商当然可以使用 DeepSeek R1——许可证里没有任何限制。但美国政府通过 FAR 创造了一个新的限制：不是 license 层面的限制，是合同层面的限制。开源许可证说“可以用”，联邦采购规则说“不可以用”——两个法律框架同时适用，结果是“在某些场景下不可以”。
这种叠加规制让“开源”在 2025 年之后变成一个复杂的概念。Bernstein 案的“代码是言论”仍然有效；MIT License 的“任何人可以使用”仍然有效；但叠加在上面的合规层让实际的可用性大幅缩水。
把所有这些放在一起看，会发现一个 Bernstein 案从根本上没有解决的问题。
代码是言论——这个判决保护的是创造和发布自由。任何人可以写代码，任何人可以发布代码。政府不能因为代码内容而限制创造和发布。
但开源代码的整个生命周期，远超过“创造和发布”。它包括：
Bernstein 案只保护“发布”。其他四个环节都可以被各种规制覆盖：
每一个环节都不直接违反 Bernstein 案。每一个环节都不直接禁止代码本身。但叠加起来，它们能把一个完整开源项目的实际可用性切碎。
这是开源在 2024 年后面对的法律现实。Stallman 1985 年想象的那种“代码自由”——四项自由——在 Bernstein 案中得到了部分宪法保护。但他没有想象到一个状况：当代码的整个生命周期被分散到不同的法律领域，每个领域都有自己的规则，“四项自由”中的每一项都可能在某个环节被限制——而没有任何一个限制单独看起来违反宪法。
这就是 Bernstein 案的真正局限。它是一份关于“创造和发布”的判决书。开源运动的下一个十年里，最关键的问题不是“代码能不能被发布”——这个问题已经被答了。最关键的问题是“代码能不能被自由使用”——这个问题没有被任何法院明确回答23。
读到这里有人可能会问：那么开源运动应该怎么应对？
简单的回答：没有简单的答案。
事实层面，开源运动可以做几件事：
第一，结构上的“主权避险”。RISC-V International 2019 年从 Delaware 迁到瑞士就是这种逻辑。如果一个开源治理实体不愿意承担美国法律义务，它可以选择搬到一个法律框架更友好的国家。但这个选择会限制它在美国市场的影响力——美国大公司倾向于使用美国注册实体管理的项目。
第二，许可证层面的创新。Bruce Perens 在 2023 年提出 “Post-Open” 许可证的想法——它在 GPL/MIT 之外创造一种新类型，专门处理国家级使用场景。这个想法到 2026 年还没有成为成熟提案24。
第三，联邦化协作的备援。Codeberg、Gitea、Forgejo 这类去中心化的代码托管在 2022 年之后获得显著用户增长——部分是回应 GitHub 制裁的不确定性。但代码托管只是协作的一个环节——issue、CI、review 流程更难分散化。
第四，接受新的法律现实，在其中找位置。这是大多数大型开源项目实际在做的事。Linux Foundation 接受了 OFAC 合规要求——2024 年的 11 人删除是这个接受的结果。Apache Foundation 也在做同样的事。这不是投降——这是在新现实中保护项目长期生存的策略。
但每个选择都有代价。“主权避险”放弃了美国市场的便利；“许可证创新”会引起社区分裂；“备援”难以达到主流协作密度；“接受新现实”意味着开源运动失去了某种纯粹性。
到 2026 年初，没有任何一个选择已经被开源世界整体接受。各方都在自己的位置上试探。这是一个开放的局面——它的解决可能要再过五年或十年。
Bernstein 案现在已经过去 27 年。Phil Zimmermann 在 2021 年的一次 The Register 采访里说，他不后悔 1991 年的选择——但他承认现在的环境比当时复杂得多25。
1991 年，“代码自由”的争议主要是国家 vs 个人——一个程序员能不能不被政府阻止地发布加密软件。这是一个清晰的二元对立，而第一修正案给了一个清晰的答案。
2026 年，“代码自由”的争议变成了多个国家 + 多个法律领域 + 多种协作角色——一个开源 maintainer 在做出每个 commit 决定时，可能需要考虑：贡献者来自哪个国家？这个代码会被谁使用？基金会注册在哪里？训练这个模型用了多少计算？这个使用语境是不是受合规规则覆盖？
每个问题都有具体的法律答案。但合起来看，开源运动当初想象的那种“代码是全球公地”的姿态，已经无法在所有问题上都得到肯定答案。
Stallman 1985 年写的那句话——“the freedom to use, study, distribute, and modify”——四项自由——仍然是开源的根基。Bernstein 案 1999 年保护的“代码是言论”原则——仍然有效。MIT License 仍然允许任何人使用任何代码做任何事。
但围绕这些“根基”的所有具体环节——平台、协作、使用、资助——都已经被国家主权穿透。这种穿透不是 Stallman 或 Bernstein 案的失败——他们仍然保护了他们当时关心的东西。这种穿透是新一代的法律工具填补了他们当时没有覆盖到的空白。
下一章，我们会回到 2014 年。Heartbleed 那时候揭示了一个比法律层面更直接的脆弱——开源的物质基础是几十个被遗忘的志愿者。
Wikipedia: Phil Zimmermann. 包括 MIT Press 出版 PGP 源代码作为印刷品规避 ITAR 的故事。Link →
The Register 2021-06-08: “Cryptography whizz Phil Zimmermann looks back at 30 years of Pretty Good Privacy”. Link →
Wikipedia: International Traffic in Arms Regulations. ITAR 在 1980-1990 年代把强加密软件视为“munitions”。Link →
Cypherspace PGP Timeline. 记录 PGP 1991-1996 的法律历程。Link →
EFF: Bernstein v. US Department of Justice case page. Link →
Wikipedia: Bernstein v. United States. 包括 1999 年第九巡回法庭判决的主要论述。Link →
FindLaw: BERNSTEIN v. UNITED STATES DEPARTMENT OF JUSTICE 100 (1999). 判决全文。Link →
EFF: “EFF at 25: Remembering the Case that Established Code as Speech” (2015). Link →
Bureau of Industry and Security: Export Administration Regulations overview. EAR 是商务部下属机构 BIS 执行的出口管制法律。
Bureau of Industry and Security: “What is a deemed export?”. 官方定义。Link →
USF Office of Research: Deemed Exports. 包括基础研究例外的描述。Link →
UCSB Office of Research: Foreign Nationals and Deemed Exports. 提到对 AI 等新兴技术的扩展可能性。Link →
Federal Register 2024-02-26: “Dual Use Foundation Artificial Intelligence Models With Widely Available Model Weights”. NTIA 评估的官方文本。Link →
Federal Register 2025-01-15: “Framework for Artificial Intelligence Diffusion”. Link →
Sidley: “New U.S. Export Controls on Advanced Computing Items and Artificial Intelligence Model Weights” (2025-01). Link →
MIT Technology Review 2025-01-24: “How Chinese company DeepSeek released a top AI reasoning model despite US sanctions”. Link →
CyberScoop: “Senators move to quash the use of Chinese AI system by federal contractors”. Link →
Mintz: “House Select Committee Publishes Report on DeepSeek”. 2025-04-24. Link →
Inside Government Contracts: “U.S. Federal and State Governments Moving Quickly to Restrict Use of DeepSeek”. Link →
Wiley: “Chinese AI Firm DeepSeek Triggers a Wide U.S. Policy Response”. Link →
NTIA 2024-07 报告关于开放权重模型管制的评估。Brookings 引述这一评估。Brookings link →
Wikipedia: MIT License. 包括许可证全文及“非常宽松、几乎无限制”的特点描述。Link →
Wikipedia: International Traffic in Arms Regulations vs. EAR/CCL 转换历史。1990 年代加密软件从 ITAR 转到 EAR 是 Bernstein 案后果之一。
The Register 2021-06-08: Phil Zimmermann 30 周年访谈中关于“现在更复杂”的评论。Link →
2014 年 4 月 7 日下午，旧金山一家咖啡馆里，一个叫 Codenomicon 的芬兰公司的安全研究员 Antti Karjalainen 看着自己刚刚写好的报告，犹豫了几分钟。然后他把它发给了 OpenSSL Software Foundation。
Codenomicon 的同事们已经做了一个相对煽情的决定：他们要给这个漏洞起个名字、做个 logo、申请域名 heartbleed.com1。这种做法之前没有先例。漏洞通常用 CVE 编号（CVE-2014-0160）+ 技术描述就够了。但 Codenomicon 意识到这个漏洞的严重性：它影响全球约 17% 的“安全”网络服务器，大约 50 万台。它需要一种能让非技术读者也理解的传播方式。
当天晚上，OpenSSL 项目组发布了 1.0.1g 版本——一个紧急修补。Heartbleed.com 同时上线。第二天早上，主流媒体的头条几乎全是 Heartbleed。Reuters、CNN、BBC、New York Times、Washington Post——这是第一次，一个开源软件漏洞成为全球新闻周期里的头条2。
技术细节是这样的。OpenSSL 是一个 C 语言写的密码学库。全世界绝大部分 HTTPS 网站都依赖它做 TLS 握手——浏览器和服务器之间建立加密连接的那一步。在 2012 年，OpenSSL 添加了一个叫 “Heartbeat” 的 TLS 扩展，让客户端和服务器可以发送小的心跳消息保持连接。Heartbeat 扩展的实现里有一个错误：当客户端告诉服务器“我发了 X 字节，请回我 X 字节”时，服务器没有验证 X 是否真的等于客户端实际发送的字节数。攻击者可以说“我发了 1 字节，请回我 64KB”——服务器会从内存里读 64KB 数据回给攻击者。那 64KB 可能包含任何东西：其他用户的 cookies、私钥、密码、个人信息3。
这个 bug 是 2011 年由 Robin Seggelmann 引入的。Seggelmann 当时是德国明斯特应用技术大学的博士生，做 SCTP 协议研究4。他给 OpenSSL 提交了 Heartbeat 扩展的实现，因为他需要这个扩展做自己的研究。他没有发现自己写的边界检查代码有错误。OpenSSL 的核心维护者 Stephen Henson 审核了这份代码，也没发现错误。代码在 2012 年 12 月 31 日合并到 OpenSSL 主分支——一个跨年夜的 commit。
接下来一年半，这个 bug 一直在那里。被部署到了全世界绝大部分 HTTPS 服务器上。直到 2014 年 3 月，Google 的安全工程师 Neel Mehta 和 Codenomicon 的研究员独立发现了它，差不多在同一周。两边都决定要报告 OpenSSL 团队。这个时间上的同步让一些研究者后来怀疑：可能更早就有人知道这个漏洞，可能已经被某些情报机构利用了相当长时间。但没有公开证据证明这种利用5。
Heartbleed 公开后两周，4 月 24 日，Linux Foundation 联合 Amazon、Cisco、Dell、Facebook、Fujitsu、Google、IBM、Intel、Microsoft、NetApp、Qualcomm、Rackspace、VMware 等公司，宣布成立 Core Infrastructure Initiative（CII）。第一项决定是：资助两名全职 OpenSSL core developer6。
这个公告几乎所有人都没注意一个事实——在 Heartbleed 之前，OpenSSL 的“全职 core developer”数量是零。
OpenSSL Software Foundation 的主席 Steve Marquess 在 Heartbleed 公开后接受 The Register 采访时给出了具体数字。OpenSSL 团队当时有 4 个人：
整个 OpenSSL 项目的年度捐款总额——来自公司和个人——大约是 $2,000 美元7。
Marquess 接受采访时说了一句被反复引用的话：
“The mystery is not that a few overworked volunteers missed this bug; the mystery is why it hasn’t happened more often.”8
把这句话放在数字里读：4 个人维护着一个被 50 万台关键服务器使用的库。他们的年度总资源（按 Stephen Henson 的 $20,000 + 其他人业余时间估算）远低于 Facebook 一个高级工程师的年薪。这个比例不可能不出问题；问题是出在哪里、什么时候出。
这是 2014 年 4 月那一刻，整个互联网行业第一次真正注意到的事实。在那之前，开源的“许多眼睛”理论——Eric Raymond 1997 年《Cathedral and Bazaar》里提到的“足够多的眼睛让所有 bug 浅显”——被普遍接受。Heartbleed 让这个理论第一次面对一个具体的反例：眼睛是有的（OpenSSL 是公开源代码的），但有能力看的眼睛不够。审核 OpenSSL 这种密码学库需要 SSL/TLS 协议、密码学、C 语言低级内存管理三个领域的深度知识。这种人在全世界总共不超过几百个。其中愿意花业余时间审核别人代码的，更少9。
CII 在 Heartbleed 后两年里资助了 OpenSSL、NTP、OpenSSH 等几个关键项目。预算大约 $1 千万——分摊到几年里。这个数字相对于科技巨头的总营收来说微不足道。当时 Google 一年营收约 $660 亿，Facebook 约 $125 亿。$1 千万对它们来说是“四舍五入掉的钱”。
但这个数字对开源关键库的维护者来说，是从 $0 到正数的质变。CII 资助让 OpenSSL 从此有了正式的全职维护者。它让其他关键库的维护者第一次能光明正大地讨论“我们也需要钱”。
CII 2020 年合并为 Open Source Security Foundation（OpenSSF），这是 Linux Foundation 旗下专门处理 OSS 安全的子组织。Brian Behlendorf——Apache 创始人之一，前 CNCF 执行董事——出任 OpenSSF General Manager10。
但 Heartbleed 之后 7 年，下一个具体的“基础设施崩溃”就来了。
2021 年 11 月 24 日，阿里云安全团队的工程师 Chen Zhaojun 在内部安全测试中发现一个严重漏洞。它在 Apache Log4j 中——一个所有人都用的 Java 日志库。这个漏洞允许攻击者通过精心构造的字符串触发任意代码执行11。
Chen Zhaojun 按照负责任披露的规则，把这件事报告给了 Apache Software Foundation。Apache Log4j 项目组从那天起开始紧急修复。两周后，2021 年 12 月 9 日，漏洞详情在公开邮件列表泄露——一个安全研究员在 Minecraft 服务器上演示了它，演示视频迅速传开。
接下来 48 小时是互联网历史上最紧张的 48 小时之一。
Log4j 不是一个小库。它是所有大型 Java 应用默认使用的日志系统。Apple iCloud 在用、Twitter 在用、Steam 在用、Minecraft 在用、亚马逊 AWS 在用、阿里云在用、苹果 iCloud 在用、几乎所有大型企业 Java 应用都在用。CISA（美国网络安全和基础设施安全局）发布的最高级警告称：Log4Shell 影响“hundreds of millions of devices”12。
漏洞的严重程度是 CVSS 10.0——满分。能远程执行代码，不需要任何认证，几乎所有 Java 应用都受影响。如果一个应用在某处记录用户输入到日志（几乎每个 web 应用都这么做），那么用户只要输入一个特定字符串，攻击者就能远程在服务器上执行任意代码。
整个 12 月 9 日到 12 月 11 日，全球安全团队都在紧急扫描、紧急 patch、紧急部署 WAF 规则。我个人认识的几个工程师那个周末没睡觉。在所有商业基础设施中，Log4Shell 触发了一种少见的“全公司 incident”——CTO 亲自参加 sync，CEO 收到状态报告，公关团队准备危机声明。
Apache Log4j 团队的反应同样是 24/7 工作。他们在四天内发布了 2.15.0（初步修复），然后是 2.16.0（更彻底的修复），然后是 2.17.0（修复 2.16 中遗留的另一个问题）。整个修复过程靠的是 三个志愿者13。
主维护者 Ralph Goers——Log4j 的初始作者之一——在 12 月 11 日给 Bloomberg 的一份声明里说：
“The Apache Log4j project is being maintained by three people who volunteer their time.”
他还提到，他的全职工作是另一家公司的软件开发——Log4j 是他在工作之余维护的14。
读到这里有几个问题应该自然涌现：
答案不在三个人的个人选择，在结构。
Log4j 的故事开始于 2001 年。Ceki Gülcü，那时候在 IBM 苏黎世研究院工作，发布了 Log4j 的第一个版本。他后来离开 IBM 去做了一个叫 SLF4J 和 Logback 的项目，把 Log4j 移交给了 Apache Software Foundation 维护。Apache 接管之后，主要维护者轮换了几代——Stefan Bodewig、Curt Arnold、Scott Deboy、Ralph Goers、Volkan Yazici、Gary Gregory15。
每一代维护者都是志愿者。Apache Software Foundation 本身不雇佣开发者——它是一个法律保护壳，提供版权管理、基础设施、品牌保护。具体代码工作由社区贡献者完成。这是 Apache 自 1999 年成立以来一直的做法。
2013 年，Ralph Goers 给 Log4j 添加了一个新功能：JNDI lookup。JNDI 是
Java Naming and Directory Interface，一个让 Java 应用查询命名服务（如
LDAP、DNS）的标准接口。这个功能让开发者可以在 log
输出中嵌入动态查询——比如 ${jndi:ldap://example.com/} 会在
log 时去查 LDAP
服务器拿数据16。
这是个有用的功能。它解决了真实问题——在 enterprise Java 应用中，开发者经常需要在 log 中嵌入动态环境信息。Ralph Goers 在 2013 年加这个功能时没有人质疑它的安全含义。它的安全含义是：如果 log 内容来自用户输入，那么用户可以让服务器去查任意 URL。攻击者可以让服务器查一个恶意 LDAP 服务器，那个服务器返回一段 Java bytecode，服务器执行这段 bytecode——任意代码执行。
这个 bug 在 Log4j 里活了 8 年。从 2013 年到 2021 年 11 月。期间它被部署到了全球数亿台 Java 应用上。没人发现。直到 Chen Zhaojun 因为某种偶然——可能是在做内部模糊测试时——注意到这个 JNDI 嵌入17。
8 年。这是 Log4j 故事的真正深度。8 年里，Log4j 项目本身没有专门的安全审计；JNDI lookup 这个功能没有被独立安全研究者认真看过；Apache Software Foundation 没有给 Log4j 提供安全人员。一个被全球数亿应用使用的库，依赖于“如果有志愿者愿意，他们会做安全审查”——而显然没有。
Log4Shell 跟 Heartbleed 之间有一个让人不安的对称：
Log4Shell 的“在野时间”是 Heartbleed 的 5 倍。这不是偶然——它说明从 Heartbleed 到 Log4Shell 的 7 年里，关键基础设施的安全状况没有实质改善。CII 资助了 OpenSSL，但没有覆盖 Log4j。OpenSSF 在 2021 年 11 月——Chen Zhaojun 发现 Log4Shell 的同一个月——刚刚成立 Alpha-Omega 项目（要在 12 月 28 日宣布资助）。
7 年里很多事情发生了：CII 成立、OpenSSF 成立、Linux Foundation 营收翻倍、GitHub 被 Microsoft 收购、整个云原生生态成为价值数千亿美元的市场。但 Log4j 仍然由三个志愿者维护。
这种不对称的真正原因，是个简单的事：没有人觉得自己有义务。Apache 是社区基金会，它的角色是协调，不是雇佣。使用 Log4j 的公司没有合同义务给 Log4j 捐款——他们只需要遵守 Apache 2.0 license，那是个“非常友好”的许可证（你可以做任何事，包括商业使用、衍生作品、专利保护）18。维护者自己也没有义务推动企业资助——Apache 文化是“如果你想要更好的 Log4j，提交 patch”，不是“如果你想要 Log4j 更安全，付钱”。
这种“无义务结构”对 1998 年那个商业开源运动是个核心特征——它让大公司能放心使用开源代码，因为没有附带责任。它也是为什么开源在 2001-2018 年能商业上成功。但同样的特征，让关键基础设施的安全责任彻底分散——没有任何一方明确负责。
Log4Shell 之后两个月，2022 年 2 月 1 日，OpenSSF 宣布 Alpha-Omega 项目。Microsoft + Google 联合投入初始 $5 million。项目计划“alpha” 部分——直接资助约 10 个最关键开源项目的维护者；“omega” 部分——对 10,000 个广泛部署的项目做自动化安全分析19。
Brian Behlendorf——OpenSSF GM——在公告里说：
“Alpha-Omega supports this effort in an open and transparent way by directly improving the security of open source projects through proactively finding, fixing, and preventing vulnerabilities.”20
到 2024 年 Alpha-Omega 已经资助了约 30 个项目，包括 Eclipse Adoptium、Rust Foundation 安全审计、Node.js 等。每个项目获得 $50K 到 $500K 不等的资助21。
同年 5 月，德国联邦议会拨款 €3.5 million 每年成立 Sovereign Tech Fund（后改名 Sovereign Tech Agency）。第一波资助包括 curl、Drupal、Gnome、openSSH、systemd、Sequoia PGP 等。每个项目获得 €50K 到 €1M 不等22。
到 2024 年底，STF 已经支持了 60+ 个关键开源项目。德国之后，荷兰、欧盟整体、英国都跟进了类似项目。“政府资助开源关键基础设施”在 2022-2024 年从一个边缘想法变成主流政策。
Tidelift 是另一种路径。它是 2017 年成立的私营公司，自我定位为“为开源 maintainer 提供商业支持的中介”。它跟企业签合同（每年订阅费），企业获得“被支持开源项目”的承诺；它再把这些钱按比例分给项目 maintainer。2024 年 Tidelift 调查显示，19% 的开源 maintainer 从 Tidelift 获得部分收入；25% 从 GitHub Sponsors 等捐赠程序获得收入23。
把这几个数字放在一起看：
这是 2014 年 Heartbleed 之后十年的成果。它显著改善了关键开源项目的资助状况——这是真的进步。但它没有改变结构。50% 以上的 maintainer 仍然完全靠个人时间维护项目。被资助的那些项目里，资助通常只够 1-2 个全职 maintainer，远不到“专业团队”的规模。
然后 2024 年 3 月 29 日，xz-utils 后门被发现。
我们留下个章节专门讲 xz 的故事。这里只需要知道一件事：xz Utils——一个被几乎所有 Linux 发行版用于压缩的库——被一个使用 “Jia Tan” 身份的国家级行为者通过三年精心社会工程接管。后门在 2024 年 2 月被嵌入到 5.6.0 release。它差点被集成到 Debian、Ubuntu、Fedora、Arch Linux 的下一个稳定版本。被发现是因为一个 Microsoft 工程师 Andres Freund 在做 PostgreSQL 性能测试时偶然注意到 SSH 登录耗时异常24。
xz Utils 的维护者 Lasse Collin 是芬兰人，长年单人维护这个项目。Heartbleed 时 OpenSSL 是 4 人团队，Log4j 是 3 人志愿者；xz 是 1 个人。
把三个事件放在时间轴上看：
三个事件之间间隔在缩短（7 年 → 不到 3 年）。每次的维护资源更少。每次的攻击/漏洞复杂度更高。
这是这本书第三章想说的核心：开源关键基础设施的脆弱不是一次性事件，是一个持续的系统性问题。每次响应都不够。每次“我们要修这个”都改善了一点点，但下一个事件总是来得更快、更复杂。
Heartbleed 是无意 bug。Log4Shell 也是无意 bug。xz 是有意 backdoor——这是质变。从 2014 到 2024 这十年里，攻击者意识到关键基础设施是个机会。他们不再被动等待 bug 出现；他们开始主动制造它们。
读到这里有人可能会问：为什么这种 “免费搭车” 一直没解决？
简单的回答：经济激励不对齐。
详细的回答需要看几个具体角色的处境。
使用开源的大公司：它们是最大受益者。Google、Facebook、Amazon、Microsoft、Apple——每一家都把开源软件作为产品的基础。它们的整体节省（不需要自己开发 OpenSSL、Log4j、Linux kernel）每年是数十亿美元规模。它们如果决定大规模资助开源，每家拿出 $1 亿美元/年也不会影响财报。但它们不这么做，因为：
开源 maintainer：他们是最受压迫的一方。多数是个人志愿者，有全职工作。维护开源项目是 unpaid labor，但产生的压力是真实的——bug 修复、安全漏洞、用户支持、企业客户的隐性期望。Daniel Stenberg（curl 维护者）多次公开抱怨这种“全世界都依赖我但没人对我有责任”的处境25。
用户企业：它们大多数没有意识到自己依赖了多少开源。CTO 知道公司用了 Log4j，但不知道 Log4j 由 3 个志愿者维护。一旦 Log4Shell 这种事件发生，公司紧急 patch，但 patch 之后又回到“忘记开源是免费的”的默认状态。
政府：直到 2022 年 Sovereign Tech Fund 之前，政府没有把开源视为关键基础设施。SolarWinds 2020 年事件之后，美国 EO 14028 把 SBOM 提到联邦采购层面，但这是合规要求，不是资助。德国 STF 是第一个明确“政府应该直接资助开源关键基础设施”的项目。这种立场在 2024 年仍然是少数26。
每个角色都有自己的逻辑。每个角色都不愿意单独承担成本。结果就是关键基础设施长年缺钱，长年单人维护——直到下一个 Heartbleed / Log4Shell / xz 把所有人推到一个紧急状态。
2020 年 8 月，xkcd 网站上发了一幅漫画，编号 2347，标题 “Dependency”。
漫画画的是一个像积木塔的依赖图。从底层往上，每一层依赖下一层。最底层是“现代数字基础设施的所有组件”——堆得密密麻麻。在某个位置，整个塔的稳定取决于一个细细的、不起眼的小块。这个小块的注释是：“Some random person in Nebraska has been thanklessly maintaining since 2003.”
漫画的标题文字（caption）是：“Someday ImageMagick will finally break for good and we’ll have a long period of scrambling as we try to reassemble civilization from the rubble.”27
ImageMagick 是个非常具体的例子——一个 1987 年由 John Cristy 创建的图像处理库。它在大量 web 服务、内容管理系统、社交媒体平台后端使用。Cristy 长年一人维护。如果它“坏了”——比如出一个严重漏洞、或者 Cristy 不再有时间——一大段互联网会瘫痪一阵。
漫画在发布时（2020 年 8 月）是一个隐喻：互联网依赖于太多被遗忘的小项目。当时这是一种隐喻——大家觉得“哈，xkcd 又抓到了 IT 行业的痛点”，但没人觉得这是即将发生的事。
15 个月后，Log4Shell 发生了。漫画从隐喻变成了具体事件。Log4j 不是“内布拉斯加的某个人”——它是 Ralph Goers——但结构一样。一个被全球数亿应用依赖的库，由几个志愿者维护。
39 个月后，2024 年 3 月，xz Utils 后门被发现。Lasse Collin——芬兰人，长年单人维护——成了第二个“内布拉斯加的某个人”。但 xz 跟 Log4j 还有一个关键不同：xz 不是被 bug 攻击，是被有计划的国家级行为者接管。
这是 xkcd 2347 之后这些年最大的变化。漫画里那个“内布拉斯加的某个人”还是被假设是好意的、勤奋的、可信的。2024 年之后，这个假设没办法再维持。开源关键基础设施不只面对“无意 bug”——还面对“有意接管”。
把这一章的所有数字放在一起：
这些数字之间的不对称是这一章的全部内容。被使用的规模 vs 维护资源：完全不成比例。这种不成比例在 1998-2014 年的时代是默认状态——开源运动靠“志愿者文化”取得了胜利，但同样的志愿者文化让它的关键节点长期缺钱。Heartbleed 让一部分关键项目获得资助。Log4Shell 让资助扩大。但 xz Utils 暴露了一个更深的问题：有资助也不够。
Lasse Collin 不缺钱——他是欧洲的、独立的、有其他收入的开发者。他缺的是注意力。xz Utils 是一个相对小众但极其关键的库——它的维护需要的不只是钱，是有审计能力的人愿意花时间审视每个 PR。Alpha-Omega 资助的项目数量有限；STF 资助的项目数量有限；这些项目之外的几千个关键基础设施仍然完全靠志愿者注意力。
xz 之后两年，截至 2026 年 5 月，没有发生第二次大规模 supply chain 后门事件。但安全研究界几乎一致认为：这是因为还没被发现，不是因为没有发生28。
下一章我们要做的就是把 xz 后门的完整故事讲清楚。这是这本书里技术细节最厚的一章，因为只有真正看到一次国家级 OSS 供应链攻击是怎么发生的，才能理解为什么这件事让所有 incident response 机制——CII、OpenSSF、STF——都觉得自己永远跟不上。
Wikipedia: Heartbleed. 包括 Codenomicon 公开漏洞的过程。Link →
Heartbleed 技术细节：CVE-2014-0160 描述。Heartbeat extension 的边界检查缺陷。
The Register 2014-04-11: “OpenSSL Heartbleed: Bloody nose for open-source bleeding hearts”. Robin Seggelmann 的角色描述。Link →
Digital Trends: “How Did the Heartbleed OpenSSL Data Encryption Bug Happen?”. 描述 Google + Codenomicon 独立发现的过程。
Wikipedia: Core Infrastructure Initiative. Link →
Mend.io: “How The Heartbleed Vulnerability Shaped OpenSSL as We Know It”. 提供 OpenSSL 2014 维护团队规模与年度捐款数字。Link →
Eric S. Raymond, “The Cathedral and the Bazaar” (1997). “Given enough eyeballs, all bugs are shallow”——著名的 Linus’s Law 来源。Link →
Wikipedia: Log4Shell. Chen Zhaojun (阿里云安全团队) 2021-11-24 私下报告。Link →
CISA: Apache Log4j Vulnerability Guidance. Link →
Wikipedia: Log4Shell. 描述 2.15.0、2.16.0、2.17.0 紧急 release 过程。Link →
Ralph Goers 2021-12 的公开声明。“The Apache Log4j project is being maintained by three people who volunteer their time.”
CVE-2021-44228 NVD 详情。JNDI lookup 被攻击者滥用的技术机制。NVD link →
Microsoft MSRC: “Microsoft’s response to CVE-2021-44228 Apache log4j2”. Link →
Wikipedia: Apache License. Apache 2.0 license 允许商业使用、衍生作品、专利保护，不要求开源衍生作品。Link →
OpenSSF Press Release 2022-02-01: “OpenSSF Announces The Alpha-Omega Project”. $5M 初始投入。Link →
Alpha-Omega 项目 Reports 页面，记录 2022-2024 年资助项目清单。Link →
Wikipedia: Sovereign Tech Agency. 2022 年 5 月德国联邦议会拨款 €3.5M/年。Link →
Tidelift 2024 maintainer survey. 25% 从 GitHub Sponsors 等程序获得收入；19% 从 Tidelift 获得收入。Link →
Wikipedia: XZ Utils backdoor. Link →
Daniel Stenberg 多年公开 blog 包括“I will slaughter you”等。Link →
NIST: Executive Order 14028 on “Improving the Nation’s Cybersecurity”（2021 年 5 月）。SBOM 要求是合规层面，不是资助。Link →
xkcd 2347: Dependency. 2020 年 8 月发布。Link →
各种 OpenSSF / CISA / 私营 threat intel 报告都指向 “下一个 supply chain 攻击只是时间问题” 的判断。
Vice: “The Internet Was Built on the Free Labor of Open Source Developers. Is That Sustainable?”——一篇早期讨论开源维护者经济问题的深度报道。Link →
2024 年 3 月 28 日下午，Andres Freund 在 Microsoft 总部一个办公桌上做着完全平常的事——给 PostgreSQL 数据库做性能基准测试。Freund 是 Microsoft 的 principal engineer，长期是 PostgreSQL 上游核心开发者之一。他那天用的 OS 是 Debian Sid——Debian 的不稳定开发版，新代码先到这里测试。
测试结果不正常。SSH 登录耗时从他记忆中的大约 100ms 变成了大约 500ms。这种延迟在 SSH 这种系统级守护进程里是很奇怪的——SSH 应该几乎瞬间响应；500ms 几乎是网络延迟级别的。
如果是 99% 的程序员，他们会注意一下，重启一下机器，发现还是 500ms，然后耸耸肩，继续做正事。Freund 不是这种人。他长期做 PostgreSQL 性能工程，对“为什么这个东西比预期慢”有职业病般的好奇1。
他开始用 perf 工具看 SSH 进程的 CPU
占用。看到了一些让他困惑的 stack trace——大部分时间花在
liblzma 库里。这不正常。liblzma 是 xz Utils
这个压缩库的一部分，它的功能很基础：解压 .xz 格式文件。SSH
这种程序为什么会在 SSH 握手时花大量 CPU 在 liblzma 里？
Freund 又跑了一遍 Valgrind——一个内存调试工具。Valgrind 在 SSH 启动时报错，指向 liblzma 的某些内部函数。
到这里他开始觉得不对劲了。他花了“几周时间”（他后来在 Mastodon
发的复盘帖里说的）——一边正常工作，一边在业余时间挖这个 liblzma
异常2。最后他追踪到一个具体的事实：xz
Utils 5.6.0 和 5.6.1 的 release tarball 里，有一段在 GitHub 源代码
repository 里看不到的恶意代码——它通过
build-to-host.m4 这个 autotools
配置脚本，在编译时把自己注入到 liblzma
二进制中3。
3 月 27 日（周三），Freund 联系了 Debian 安全团队（security@debian.org）。 3 月 28 日，他给 Linux distros 安全列表发了私下警报。 3 月 29 日上午，他在 oss-security 公开邮件列表发布完整报告。
接下来 24 小时是 Linux 世界的另一个 Log4Shell 时刻。Debian、Ubuntu、Fedora、Arch Linux 紧急回退 xz Utils 到 5.4.x 旧版本。Red Hat 发布紧急通告。CISA 发布最高级警报4。
但 xz 跟 Log4Shell 有一个关键不同。Log4Shell 是一个无意的 bug——Ralph Goers 2013 年加 JNDI lookup 功能时没意识到安全含义。xz 不是 bug。xz 是一个国家级行为者经过约三年的精心社会工程，逐步获得 xz Utils maintainer 权限，然后在 2024 年 2 月把后门嵌入到 5.6.0 release 的有意攻击。
要看清楚这件事的全部含义，我们需要从 2021 年 10 月那个不起眼的 commit 开始倒回去看。
2021 年 10 月 29 日，xz Utils GitHub 仓库收到一个 pull request，签名是 “Jia Tan” (GitHub username: JiaT75)5。
PR 内容是一个 .editorconfig
文件——一个非常无害的小改动，告诉编辑器用什么样的缩进风格、换行模式等。这种
PR 完全没有可疑性。任何开源项目都会收到大量这种小贡献。
xz Utils 当时的主维护者 Lasse Collin 看了一眼，合并。Jia Tan 第一次贡献。
接下来几个月，Jia Tan 陆续提交一些小改进——build reproducibility 的修复、文档更正、测试代码完善。这些都是真实有用的贡献，符合一个新贡献者“逐步进入项目”的正常模式。
任何成熟的开源项目都依赖这种渐进式信任建立。一个新贡献者通过一系列小贡献证明自己是可靠的、技术上能干的、对项目有兴趣的。维护者通过审核这些贡献逐步建立对此人的信任。这是开源协作模式的核心机制。
Jia Tan 完美地走了这个模式。在 2021 年底到 2022 年初的几个月里，他做的事都完全在正常贡献范围内。
但与此同时，邮件列表上开始出现一些奇怪的账号。
2022 年 4 月 22 日，一个叫 “Jigar Kumar” 的人在 xz-devel 邮件列表发了一封邮件。内容是抱怨：Jia Tan 之前提交的某个 patch 还没被合并6。
5 月 27 日，Jigar Kumar 又发了一封：“Over 1 month and no closer to being merged.”
6 月 7 日，Jigar Kumar 在另一个邮件主题下写道：
“Progress will not happen until there is new maintainer. XZ for C has sparse commit log too. Dennis you are better off waiting until new maintainer happens or fork yourself. Submitting patches here has no purpose these days. The current maintainer lost interest or doesn’t care to maintain anymore. It is sad to see for a repo like this.”7
6 月 14 日，Jigar Kumar 又一封：
“With your current rate, I very doubt to see 5.4.0 release this year. The only progress since april has been small changes to test code. You ignore the many patches bit rotting away on this mailing list. Right now you choke your repo. Why wait until 5.4.0 to change maintainer? Why delay what your repo needs?”
读这些邮件，注意几个细节：
后续调查发现，Jigar Kumar、Dennis Ens、krygorin4545、misoeater91 都是 sock puppet 账号——使用一次性邮箱、2021 年后才创建、活动模式高度相似的虚假账号。Securelist、ReversingLabs 等独立的 threat intel 团队后续做的分析得出一致结论：这是一个有协调的 social engineering 行动，不是巧合8。
2022 年 6 月 29 日，在这些施压邮件下，Lasse Collin 回复了：
“my ability to care has been fairly limited mostly due to longterm mental health issues, but also due to some other things. Recently I’ve worked off-list a bit with Jia Tan on XZ Utils and perhaps he will have a bigger role in the future, we’ll see.”9
这是一段值得停下来读的话。
Lasse Collin 是芬兰人，长年单人维护 xz Utils。他在公开邮件中承认两件事——他承认自己的 mental health 状态影响了维护精力；他承认 Jia Tan 已经在 off-list 帮助他，未来可能给 Jia Tan 更大角色。
后来的复盘里，安全研究者们看着这段话很沉重。Jia Tan 的 social engineering 选了一个完美的目标：一个公开承认了 mental health 困难的、单人维护关键基础设施的维护者。Jigar Kumar 等 sock puppet 的施压不是无差别的——它精准地利用了 Collin 已经在挣扎的状态10。
读 Collin 那封邮件，没办法把它解读成“他疏于职守”。他做的所有事都是合理回应：当多人施压时他承认压力；当一个志愿者愿意帮助时他接受帮助；当 mental health 影响精力时他诚实说出来。这件事最让人毛骨悚然的地方不是技术细节，是 social engineering 的精确度——它针对的是任何一个长期维护开源项目的人都可能有的情绪状态。
2022 年 10 月，Jia Tan 被加入 Tukaani 组织（xz Utils 在 GitHub 上的 organization）。 2022 年 11 月，Jia Tan 成为正式 co-maintainer。 2022 年 12 月，Jia Tan 第一次直接 commit 到 master 分支。 2023 年 1 月，Jia Tan 与 Collin 共同负责 v5.4.1 release。 2023 年 3 月，Jia Tan 独立发布 v5.4.2。同月，Google oss-fuzz（开源自动模糊测试服务）中 xz 项目的主要联系邮箱从 Collin 改为 Jia Tan11。
到这里 Jia Tan 已经在 xz Utils 项目里有完全的 trust 和 access。如果他从此停在这里——继续做正常 maintainer——没有人会怀疑他。但他还有下一步。
2023 年 6 月 22 日，一个叫 Hans Jansen 的账号出现，提交了一对 patch。内容是用 GNU ifunc（indirect function）特性优化 xz 的 CRC32 校验函数。这个优化看起来完全合理——ifunc 是 glibc 提供的运行时函数选择机制，允许程序在启动时根据 CPU 特性选最快的实现12。
Hans Jansen 不是 xz Utils 的常规贡献者——这是他对项目唯一的实质贡献。他在做完这个 patch 后就消失了。但他做的这个 ifunc 优化提供了攻击所需的关键基础设施：
ifunc 机制允许在程序启动时改变函数表指针。这正是后门后来用来劫持 OpenSSH 认证函数的机制。
但 2023 年 6 月那时候，没人知道这个 ifunc 优化的真正目的。它看起来是一个性能改进。Collin 审核了它，合并了它。Jia Tan 也参与了讨论。
回头看，Hans Jansen 这个账号被 ReversingLabs 等安全团队识别为第二个 sock puppet——跟 Jigar Kumar 那一组不同，他不参与施压，只贡献一段为后续 backdoor 服务的“合法看起来的”代码13。
整个 2023 年下半年到 2024 年初，Jia Tan 继续作为正式 co-maintainer 工作，正常处理 issue、合并 PR、发布更新。
2024 年 1 月，Jia Tan 把 xz Utils 项目的官方网站从 tukaani.org 迁到 GitHub Pages。这是一个看起来无害的运维改动——很多项目都用 GitHub Pages 托管文档。但效果是 Jia Tan 现在也控制了项目的“对外信息渠道”14。
2024 年 2 月 23 日，几个隐藏的二进制 blob 被合并到 xz Utils 的 test fixture 文件中。test fixture——测试用的输入数据——是一个不被严格 code review 关注的区域。维护者审核 commit 时主要看代码逻辑，不会逐字节查看测试数据文件。Jia Tan 把后门 payload 编码到了这些 fixture 中。
2024 年 2 月 24 日，xz Utils 5.6.0 发布。
关键点：后门不在 git 源代码 repository 里。
git repo 里只有看起来正常的代码 + 那些 test fixture
文件。后门的关键部分通过 build-to-host.m4 这个 autotools
配置脚本注入：在做 release tarball 时（也就是把 git repo 打包成
.tar.gz 给发行版用的步骤），m4 脚本会运行，把 test fixture
中的 payload 解码、组装、注入到 build 过程，最终编译进 liblzma
二进制15。
而且后门有非常精细的激活条件：
./configure && make）时不会激活这意味着如果你是个普通 xz 开发者，用 git 检出代码 build，你看不到后门。后门只在最终用户实际用的 Linux 发行版二进制里出现。这种“看 git repo 没问题但 release tarball 有问题”的攻击在历史上前所未有16。
后门的功能：劫持 OpenSSH 的认证函数。具体说，liblzma 的 ifunc resolver（Hans Jansen 2023 年加的那段代码）被改成在加载时改写 OpenSSH 的认证函数指针。当攻击者向 sshd 发送一个特定签名的认证请求时——签名用攻击者持有的 Ed448 私钥生成——sshd 会绕过常规认证流程，直接执行 payload。
这是一个完美的 backdoor：
如果未被发现，这会让攻击者在持有私钥的前提下，远程控制运行 xz 5.6.0/5.6.1 的任何 Linux 服务器。
但为什么 OpenSSH 会调用 liblzma？OpenSSH 自己不依赖 xz，它的源代码里没有 xz Utils。
答案是 systemd。
systemd 是 Linux 主流发行版的 init 系统（启动管理）。它管理着所有系统级守护进程——包括 sshd。systemd 自己依赖 liblzma（用于压缩 systemd journal 日志）。当 systemd 启动 sshd 时，sshd 进程会共享 systemd 的某些动态链接库——包括 liblzma。
这就是这次攻击的精确技术路径：
xz Utils 后门 → liblzma → systemd 加载 → sshd 进程间接得到 liblzma → 后门在 sshd 进程空间生效这是一条间接但通用的路径。它不需要 sshd 自己知道 liblzma 存在。它依赖于 systemd 默认链接 liblzma 这个事实——而 systemd 是几乎所有主流 Linux 发行版的默认 init17。
更有意思的是：在 xz 后门嵌入的同一时段，systemd 项目正在评估一个 PR——移除 liblzma 依赖18。如果这个 PR 在 2024 年早些时候合并，xz 后门就会失去最关键的入口。Russ Cox 在他的复盘里推测，攻击者可能正是因为意识到这个 PR 而加快了行动——他们要赶在 systemd 改动之前完成后门部署。
回到 2024 年 3 月 9 日。
那天，Jia Tan 发布了 xz Utils 5.6.1——一个小的更新版本。commit message 里有一句话：
“constant seed was used to recreate these files.”
这看起来是个无关紧要的技术说明。但实际上是为了修复一些 Valgrind 已经能检测到的异常——5.6.0 中的后门有一些边缘情况会让 memory checker 报告 invalid read，攻击者要修复这些让发现更难。
2024 年 3 月底，开始有迹象表明攻击者在加快推进 xz 5.6.x 进入主流发行版。Hans Jansen 重新出现——3 月 27-28 日，他在 Debian 和 Ubuntu 的 bug tracker 上提交了 issue，催促这些发行版尽快采用 xz 5.6.1。这是 Hans Jansen 这个账号在 xz Utils 项目本身之外的唯一活动。它的目的明显：尽快把后门版本推进到稳定分支19。
如果 Hans Jansen 的催促成功，xz 5.6.x 会进入 Debian stable、Ubuntu LTS、Fedora 的下一个稳定 release。等到那时——预计 2024 年 4-6 月——后门会扩散到全球数千万到数亿台生产 Linux 服务器。
但 2024 年 3 月 28 日，Andres Freund 在 PostgreSQL 性能测试里注意到了 SSH 的 500ms 异常。
把这个故事的所有关键节点放在一起，会看到一个让人不安的对称。
Phase 1：建立信任（2021 年 10 月 - 2022 年初） - Jia Tan 提交几个无害的小贡献 - 通过正常 OSS 渐进信任机制进入项目
Phase 2：制造维护压力（2022 年 4-6 月） - Jigar Kumar、Dennis Ens 等 sock puppet 在邮件列表施压 - 措辞精准地利用 Collin 已知的 mental health 困境 - 形式上完全在“合理批评”的边界以内
Phase 3：权限升级（2022 年 10 月 - 2023 年 3 月） - 加入 Tukaani 组织 - 成为 co-maintainer - 独立发布版本 - 接管 oss-fuzz 联系邮箱
Phase 4：技术准备（2023 年 6 月） - Hans Jansen 这个新 sock puppet 提交 ifunc 优化 - 这是后门后来利用的技术机制 - Hans Jansen 完成任务后消失
Phase 5：嵌入后门（2024 年 2 月） - 把 payload 编码到 test fixture - 通过 m4 配置脚本在 build 时注入 - 后门只在发行版打包时激活，开发者 build 看不到
Phase 6：推进部署（2024 年 3 月） - Hans Jansen 重新出现，催促 Debian、Ubuntu 采用 5.6.x - 目标是在 systemd 改动之前进入稳定分支
整个攻击从开始到几乎成功，约 2.5 年。期间动用了至少 5 个不同身份（Jia Tan、Jigar Kumar、Dennis Ens、Hans Jansen、krygorin4545 / misoeater91 等）。每个身份都精心设计：写作风格、邮件时区、活动模式都尽量分散。技术上极其精巧：通过 m4 hook + test fixture + ifunc + systemd 的复合机制，最终劫持 OpenSSH 认证20。
只有国家级行为者能负担这种行动的成本。一个或几个研究员需要全职投入近 3 年时间，做出能逃过开源社区代码审查的复杂技术，同时演出合理的 social engineering 戏码。算下来人力成本至少几百万美元，更不用说技术研发成本。
归因这件事必须谨慎。
到 2026 年 5 月为止，没有任何政府机构正式归因这次攻击给具体国家或组织。
公开材料中可分析的线索：
美国 CISA、Mandiant、Kaspersky、ReversingLabs、Elastic Security 等独立 threat intel 团队在公开报告里一致使用了类似措辞：“This attack pattern is highly consistent with known nation-state actor TTPs, but attribution cannot be definitively established.”21
这种判断是诚实的。从技术能力、时间投入、心理操纵的精度看，xz 攻击只可能来自国家级行为者或同等规模的资源。但具体是哪一个国家，公开材料不允许定论。Russ Cox 在他的 timeline 复盘里也明确：归因不能成立22。
媒体和社交网络上有大量推测——指向俄罗斯 SVR、朝鲜 Lazarus、中国 MSS、以色列 Unit 8200、甚至美国 NSA 内部“红队”。所有这些推测都没有可证据基础。这本书的立场跟 Russ Cox 一致：嫌疑指向国家级行为者，但具体归因不能成立。
不能归因不意味着我们不能学到什么。
xz 攻击让安全研究界第一次直接看清了一种攻击模式的完整面貌：
1. Target selection（目标选择）
按这个标准，全球开源生态里还有几百个类似项目。xkcd 2347 的“内布拉斯加的某个人”——他们每一个都是潜在 target。
2. Long-term investment（长期投入）
这种规模的投入只有国家或国家支持的行为者能负担。普通网络犯罪不会等 3 年看回报。
3. Multi-layer technical complexity（多层技术复杂度）
每一层都需要专门知识。整体设计需要对 Linux build system、动态链接器、systemd 架构、OpenSSH 内部、密码学的深入理解。
4. Operational security（行动安全）
整个行动几乎没有可被识别的“个人特征”。即使在事后复盘，研究者也只能描述行动模式，不能识别个人。
xz 后门跟历史上的两次“国家级供应链攻击”做对比：
SolarWinds（2020）：俄罗斯 SVR 在 SolarWinds Orion（一个商业网管软件）的 build 过程中注入了 SUNBURST 后门。攻击影响约 18,000 个 SolarWinds 客户，包括美国国务院、财政部、Microsoft、Intel 等。这是 闭源 供应链攻击：攻击者通过侵入 SolarWinds 公司内部，在私有 build 系统里注入代码23。
3CX（2023）：朝鲜 Lazarus Group 通过攻击 Trading Technologies 公司的软件，然后通过这个软件感染 3CX（一个 VoIP 软件），最终影响 3CX 的 60 万企业客户。这是 双层闭源 供应链攻击24。
xz Utils（2024）：来源未归因的国家级行为者，通过 social engineering 接管一个开源项目的 maintainer 权限，然后注入后门。
三个事件的关键不同：
| 维度 | SolarWinds | 3CX | xz Utils |
|---|---|---|---|
| 目标软件类型 | 闭源商业 | 闭源商业 | 开源 |
| 入侵方式 | 入侵公司内网 | 双层供应链入侵 | Social engineering 维护者权限 |
| 攻击预备时间 | 数月 | 数月 | 2-3 年 |
| 被发现方式 | FireEye 内部红队 | 用户报告异常 | 个人工程师偶然 |
| 修复方式 | SolarWinds 紧急 patch | 3CX 紧急 patch | 回退 xz 版本 |
| 归因 | 美国正式归因俄罗斯 SVR | 美国正式归因朝鲜 Lazarus | 未归因 |
闭源供应链攻击让人警惕——它证明了“专有软件 + 公司内部 build 系统”不是安全保证。但开源供应链攻击让人更不安——它证明了“公开代码 + 社区审查”也不是安全保证。
xz 唯一被发现是因为运气。在那 2.5 年里，没有任何安全审计、自动化扫描、社区代码审查发现了 Jia Tan 的真正身份或意图。即使 ifunc 优化、test fixture、m4 hook 都在公开 git history 里，没有人在嵌入时识别出它们的真正含义。
只有 Andres Freund 在 2024 年 3 月做 PostgreSQL benchmark 时——一个跟 xz Utils 完全无关的工作场景——偶然发现 SSH 慢了 400ms。如果他那天没注意到，或者他像 99% 的工程师那样忽略了，xz 后门会进入下一个月的 Debian stable。然后 6 个月内进入全球大部分 Linux 服务器。
xz 暴露的最深的问题不是 OpenSSL 的“单人维护”，是社区审查在国家级行为者面前的失效。
回到 Eric Raymond 1997 年 Cathedral 和 Bazaar 那篇文章里的著名命题——“Given enough eyeballs, all bugs are shallow”25。这个命题假设：开源代码的公开性让足够多的眼睛看到代码，所以 bug 都会浅显。
Heartbleed 在 2014 年第一次质疑了这个命题——一个 bug 在公开代码里活了 17 个月，最后被两个独立团队几乎同时发现。Log4Shell 在 2021 年继续质疑——一个 bug 在公开代码里活了 8 年。
但 Heartbleed 和 Log4Shell 都是无意 bug。它们没主动隐藏自己。“足够多的眼睛”的失败是因为代码太复杂、审查者太少、激励不对齐——但理论上眼睛足够多就能发现。
xz Utils 是主动隐藏的后门。Jia Tan 不只是没主动暴露自己的真意——他在整个 2.5 年里精心避免任何能让审查者发现真意的痕迹。他做的所有真实贡献都对项目有益。他的所有施压邮件都通过 sock puppet 发出，他自己的 commit 全部技术中性。他的 commit message 都写得完美。
在这种“对手主动隐藏”的情境下，“足够多的眼睛”不再有用——因为眼睛看到的是被精心设计的合理表象。要发现 xz 后门，需要的不只是审查眼睛，是对维护者身份的可验证性、对 build 过程的可验证性、对供应链 provenance 的可验证性。
这正是 SLSA、Sigstore、Reproducible Builds 这些新一代供应链安全工具要解决的问题。但它们也有限度——下一章我们会讲这些工具的设计和它们没解决的部分。
最后回到那个 500ms 异常。
Andres Freund 在 Mastodon 上写过一段复盘：他强调自己不是安全研究员，他是一个性能工程师。他注意到 SSH 慢了不是因为他特别警觉——是因为他每天都在看 PostgreSQL 的性能曲线，对“什么东西比预期慢”有职业习惯26。
如果换一个非性能背景的工程师在那台 Debian Sid 上——比如一个 web 开发者，一个机器学习研究员——他们大概率不会注意到 SSH 慢了 400ms。SSH 100ms vs 500ms 在日常使用中几乎感受不到差别。是 Freund 的具体职业偏见（“为什么这个比预期慢”）救了所有人。
这件事在 OSS 安全圈引起了一种特殊情绪。一方面是庆幸——后门被发现了，损失被避免了。另一方面是恐惧——这不是制度的胜利，是偶然的胜利。如果换一个人，结果就是另一个故事。
xz 之后两年——从 2024 年 4 月到 2026 年 5 月——没有发生第二次类似的、被识别的国家级 OSS 后门事件。但几乎所有公开发言的安全研究者都指出同一件事：这不是因为没有第二次，是因为还没被发现。
如果一次行动需要 2.5 年才能成熟，那么 2024 年 3 月之后开始的下一次行动，可能要 2026 年下半年或 2027 年才会被尝试。当我们在 2026 年 5 月写这本书时，第二次可能正在 mid-flight——正在某个我们不知道的 xkcd 2347 项目里，某个被 social engineering 的维护者旁边，某个新的 Jia Tan 正在合并某个看起来无害的 patch。
下一章我们要看的是这个故事的另一面——维护者本人的处境。Lasse Collin、Daniel Stenberg、Ralph Goers、Andres Freund，他们不是案例，是有血有肉的人。他们的具体处境决定了 xz 这种攻击为什么是可能的——以及为什么不可能简单消除。
Wikipedia: XZ Utils backdoor. 包括 Andres Freund 的发现过程基础描述。Link →
Andres Freund 在 Mastodon 与 oss-security 邮件列表的 2024-03-29 复盘。Elastic Security Labs 的 “500ms to midnight” 提供详细记录。Link →
Akamai: “XZ Utils Backdoor — Everything You Need to Know”. 关于 build-to-host.m4 注入机制的技术描述。Link →
Red Hat: “Understanding Red Hat’s response to the XZ security incident”. 2024-03-29 紧急响应记录。Link →
research!rsc: “Timeline of the xz open source attack” by Russ Cox. 包括 2021-10-29 第一次 Jia Tan commit 的详细记录。Link →
Jigar Kumar 2022-06-07 邮件原文，从 xz-devel mailing list 归档。Russ Cox 与 Securelist 都引述了这段。
Securelist: “Social engineering aspect of the XZ incident”. 包括 sock puppet 协调分析。Link →
Lasse Collin 2022-06-29 邮件回复原文。从 xz-devel mailing list 归档；Russ Cox 完整引述。
ReversingLabs: “XZ Trojan highlights software supply chain risk posed by ‘sock puppets’”. 关于 social engineering 精确度的分析。Link →
Checkmarx: “Backdoor Discovered in xz”. build-to-host.m4 与 release tarball vs git repo 的关键区分。Link →
arxiv: “On the critical path to implant backdoors and the effectiveness of potential mitigation techniques: Early learnings from XZ”. 技术深度分析。Link →
Evan Boehs: “Everything I Know About the XZ Backdoor”. 关于 Hans Jansen 2024-03 重新出现催促 Debian / Ubuntu 的细节。Link →
daily.dev: “XZ Backdoor: The full story in one place”. 综合时间线。Link →
CISA、Mandiant、Kaspersky、ReversingLabs、Elastic Security 等团队 2024-04 至 2024-12 的 xz 系列分析报告。全部使用“高度匹配国家行为者 TTP 但归因不能成立”的措辞。
Wikipedia: 2020 United States federal government data breach (SolarWinds). Link →
Krebs on Security: “3CX Breach Was a Double Supply Chain Compromise”. Link →
Eric S. Raymond, “The Cathedral and the Bazaar” (1997). “Linus’s Law” 的来源。Link →
Andres Freund 2024-04 Mastodon 复盘。“I am not a security researcher”——强调发现 is luck。Elastic Security Labs 全文引述。
SoftwareSeni: “The XZ Utils Backdoor CVE-2024-3094 and the Multi-Year Social Engineering Campaign Behind It”. 综合性中文向分析。Link →
Rapid7: “Backdoored XZ Utils (CVE-2024-3094)”. Link →
JFrog: “XZ Backdoor Attack CVE-2024-3094: All You Need To Know”. 包括技术深度分析。
2021 年 2 月 19 日，瑞典斯德哥尔摩郊外的一个家里，Daniel Stenberg 打开自己的 inbox。这天他收到一封邮件，主题是 “I will slaughter you”——我要屠杀你。
发件人不知名。邮件内容直接、具体、带威胁。
Stenberg 那时候已经维护 curl 25 年。curl 是一个命令行 HTTP 客户端——它是几乎所有现代设备里都有的小工具，被估计部署在 200 亿到 100 亿台设备上：每台 Mac、每台 Linux 服务器、每台 Android 手机、每个 Tesla、每个汽车娱乐系统、每个家用路由器，几乎所有内嵌 Linux 的设备1。
Stenberg 1996 年开始写 curl。当时他没想到这个小工具会被部署到这种规模。他在不同时期受雇于不同公司，但 curl 一直是他的个人项目。2019 年他加入 wolfSSL——一家做嵌入式 TLS 库的小公司——作为 curl 项目的“正式” maintainer。wolfSSL 支付他部分薪水维护 curl，作为商业服务的一部分。
但他仍然是 curl 唯一的全职 maintainer。所有 release、所有重大决定、所有重大安全响应——都是他一个人。
那天的 “I will slaughter you” 邮件不是第一封。Stenberg 在他的个人 blog 里维护着一个 “Emails” 归档页——记录他多年来收到的有趣或有威胁的邮件。归档里有各种东西：来自非英语母语国家的奇怪英语 bug report，来自青少年的“我的电脑被黑了请帮帮我”求救信，来自高级用户的精彩技术讨论。但也有：来自陌生人的死亡威胁、来自自称政府机构的伪造邮件、来自被骗者的“为什么你的 curl 让 hackers 偷了我的钱”指责2。
那天的邮件不一样在于它的直接性。Stenberg 当天写了一篇 blog post，标题就是 “I will slaughter you”。他公开了邮件大部分内容（隐去发件人）。他没有报警——他说他选择把这件事公开，是因为他想让外界知道开源 maintainer 长期暴露在什么样的环境里3。
读那篇 blog 让人想起一个简单的事实：Daniel Stenberg 是世界上几个 most under-appreciated 工程师之一。他维护的代码每天在几十亿台设备上运行；他的工作让 https 在每个家用设备上工作；他没有从这种规模中得到任何匹配的金钱回报。然后他在自己家里收到死亡威胁邮件——也没有匹配的支持系统。
2025 年 5 月，Stenberg 开始尝试一个新政策：对所有 AI 生成的 bug bounty 提交立即封禁4。
背景是 2024-2025 年开源世界面对的一个新现象：AI slop——AI 生成的、看起来专业但完全错误的 bug 报告。
事情是这样的。HackerOne 等 bug bounty 平台让安全研究员可以为发现漏洞获得奖金。curl 有一个 bug bounty 项目，2019 年成立，6 年里累计支付了大约 $86,000——主要给少数几位真正有发现的研究员。这是一个相对成功的项目。
2024 年下半年，提交量开始急剧上升。Stenberg 注意到提交的“质量分布”在变化：大量看起来技术性很强、引用具体代码片段、使用专业术语的报告——但仔细看每一份都是错的。它们描述的“漏洞”在代码里根本不存在。
研究后发现：有人在用 ChatGPT、Claude、Gemini 等大模型批量生成 bug 报告，然后用脚本提交到 HackerOne。生成报告几乎不需要时间。如果碰巧蒙对了一个，就能赚到几千美元。蒙错了也没成本。
到 2025 年 7 月，curl 项目的提交量已经是正常的 8 倍。Stenberg 估计大约 20% 是 AI slop——技术看起来对，但里面没有真东西5。
5 月那次尝试——“对 AI 提交立即封禁”——没解决问题。因为没办法可靠地识别 AI 生成的内容。Stenberg 试着用各种 heuristic（“这个用了 LLM 的典型句式”“这个引用了不存在的代码行”），但工作量本身就压垮了他。
2026 年 1 月 21 日，Stenberg 在 blog 上发了一篇标题为 “End of curl bug bounty” 的文章。他宣布：经过 6 年和 $86,000 总支出，curl 的 bug bounty 程序到此终止6。
他写道：
“We need to make moves to ensure our survival and intact mental health.”
这是 2026 年这个时刻一个值得停下来读的句子。
curl 没有失败——它仍然是地球上部署最广的 HTTP 客户端。Stenberg 没有放弃维护——他仍然每天工作。但他被迫关闭一个对 curl 安全有帮助的项目——bug bounty 本来的目的是让外部研究员有动力发现 curl 的真实漏洞——只为了保护团队的心理健康。
curl 团队的应对不是“扩张”——他们没有招更多人。他们也没有“接受现状”——继续被淹没。他们选择撤退——关掉一个已经无法承载的协作渠道。
这是 2024 年后开源维护者的新常态。在 xz 后门那种“被国家级 social engineering 攻击”的极端之外，还有一种更普遍的状况：被 AI 工业化骚扰淹没。前者一年发生一次或几次，后者每天发生。
Lasse Collin 是另一种处境。
Collin 是芬兰人，长年生活在芬兰某个城市（公开材料里他自己不强调具体位置）。他是 xz Utils 的主创和长期单人维护者。在 xz 后门事件之前，外界对他知之甚少——他不写 blog，不上电视，不参加大会，他的 GitHub profile 没有头像。
但通过 xz 后门事件，他成了一个不情愿的公众人物。
我们在第 4 章已经看到了 Collin 2022 年 6 月 29 日那封关键邮件：
“my ability to care has been fairly limited mostly due to longterm mental health issues, but also due to some other things.”7
这是事件发生 2 年前 Collin 自己写的话。它在事后被 Russ Cox、Securelist 等团队反复引用——作为 Jia Tan 之所以能成功 social engineering 的关键节点。
但读这段话不是为了责备 Collin。读它是为了理解一个事实：Collin 做的所有事都是合理的。
他承认自己 mental health 状态——这是诚实，不是疏忽。 他在多方施压下接受帮助——这是开放，不是软弱。 他对 Jia Tan 的“真实贡献”做出 reasonable 的信任评估——这是正常的开源协作。 他作为单人维护者承担过劳——这不是他的问题，是结构的问题。
Russ Cox 在他的 timeline 复盘里有一段非常清楚的话：他不是疏忽的维护者。他做的所有事都符合开源协作的最佳实践。问题是当对手是国家级行为者时，“最佳实践”不够8。
xz 后门事件之后，Collin 发了一份简短的公开声明，承认 Jia Tan 利用了他的 mental health 状态。他没有自我责备，但也没有把全部责任推给攻击者。他说：
“I have not been involved with the work of Jia Tan beyond reviewing some commits.”
然后他继续做自己的工作。Tukaani 组织恢复了正常运作，社区成员（不是 Collin 个人）做了清理和补救。xz Utils 项目至今仍在维护。Collin 仍然是名义上的 maintainer，但承担较少日常事务。
Collin 没有从这件事中获得任何金钱回报。他没有出书。他没有接 media 采访。他没有“事件后转型为安全专家”。他做了他的代码工作——这是他过去 20 年一直在做的事——只是这次他成了世界上“国家级 social engineering 受害者”的最知名案例。
如果 Stenberg 是“被骚扰但坚持工作”的版本，Collin 是“被利用但坚持工作”的版本。两种处境的共同点是：他们没办法保护自己——开源生态没有给他们提供任何系统性的保护机制。
Andres Freund 在 xz 后门事件中扮演的角色完全不同。他不是受害者——他是发现者。
Freund 在 Microsoft 工作。具体岗位是 PostgreSQL 上游核心开发者——这意味着他被 Microsoft 雇佣的工作之一就是维护开源 PostgreSQL。这是 Microsoft 跟很多大公司一样的开源参与模式：付员工的薪水让他们贡献给特定开源项目，作为公司基础设施投资的一部分。
但 Freund 不是安全研究员。他是性能工程师。他研究 PostgreSQL 在不同硬件上的性能特征，写复杂的 benchmark，找瓶颈。这是一个相当 niche 的专业方向9。
3 月 28 日那天他不在做 xz 研究——他在做 PostgreSQL benchmark。SSH 慢 400ms 是个完全意外的发现。
Freund 在 Mastodon 后续复盘里有几段重要的话。一段是说他“运气”——如果他不是性能工程师，他大概率不会注意到这个延迟；如果他在做其他任务，他大概率不会停下来追究10。另一段是说他不是安全研究员，发现是偶然的，制度上没有任何机制能保证下一个 xz 类型的攻击也会被发现。
这是 Freund 在媒体光环下保持的清醒。xz 事件后，他成了全球安全圈的英雄人物。但他自己反复强调：他做的事任何注意细节的工程师都能做；问题是大多数工程师在大多数时间没有停下来注意。
Freund 在 Microsoft 的工作并不要求他做这种“全开源生态扫描”。Microsoft 雇他维护 PostgreSQL，不是当 xz 守卫者。他做的额外工作——周末和工作日晚上花时间挖那 400ms 异常——是他个人选择。Microsoft 后续给了他认可（不是金钱奖励，是声誉），但没有任何制度机制说“以后类似情况会有专人做”。
这点也很重要。如果 Freund 是被 Microsoft 雇来做 OSS 供应链安全的——比如 OpenSSF Alpha-Omega 项目下的全职安全工程师——那么 xz 发现是工作产物。但他不是。他是性能工程师。他发现 xz 是偶然。
下一个 xz 是不是会被发现——取决于又有没有一个 Freund 类型的人，恰好碰上一个让他停下来挖的异常。这种“偶然依赖”是当前 OSS 安全模式的根本脆弱性。
Ralph Goers 是另一种状态。
Goers 是 Log4j 的初始作者之一，2001 年开始写代码。他的全职工作是另一家公司的软件开发——他在那家公司做的工作跟 Log4j 没关系。Log4j 是他工作之余的志愿者贡献11。
2021 年 11 月 24 日，Chen Zhaojun 向 Apache 报告 Log4Shell 漏洞。接下来三周，Goers 和另外两个志愿者维护者（Volkan Yazici、Gary Gregory）在自己的业余时间内紧急修复漏洞。三个人，三周，全球紧急 patch 几亿设备。
12 月 11 日他发了那个被反复引用的声明：“The Apache Log4j project is being maintained by three people who volunteer their time.”12
这句话的言外之意是：我们没有承担义务。Apache Log4j 是 Apache 2.0 license——你可以拿去做任何事，没有保证。Goers 等三人维护这个项目是 unpaid 个人选择。当 Log4Shell 出现时，他们当然会修复——但他们没有义务在 24/7 待命，没有义务向企业承担 SLA。
讽刺的是，他们实际上做了那种 24/7 紧急响应。三人志愿者团队在 Log4Shell 之后两周里基本没睡觉。他们发布了 2.15.0、2.16.0、2.17.0——三个相继的紧急 release，因为每个 release 都被发现仍然有边缘案例需要修补。
Log4Shell 之后，Apache 软件基金会公开呼吁企业回馈。一些公司响应了——Comcast、Amazon、Microsoft 等捐了款。OpenSSF Alpha-Omega 在 2022 年成立时直接以 Log4Shell 为契机，把 Log4j 列入第一批资助项目。但效果有限。三年后的 2024 年，Log4j 仍然由很少几个志愿者维护——只是其中一些人现在有部分 Tidelift 或 Alpha-Omega 的资助。
Goers 自己 2022 年后接受过一些采访，他表达的态度是相对平和的。他不抱怨——他维护 Log4j 是因为他相信这件事重要。他也不要求大公司必须捐钱——他相信开源的根本是自愿。但他确实承认：单人或小团队维护关键基础设施是不可持续的。最让他担心的不是被攻击，是 burnout——某天他自己累到不想再做了，下一代维护者没有自然接手13。
把这四个人放在一起看，会注意到一些共同的事，也会注意到一些不同的事。
共同点：
不同点：
四种处境，四种不同的“应对方式”。但都不是扩张——都是某种形式的撤退或维持现状。
这跟主流叙事里“开源运动一直在扩张、在胜利”很不一样。从总体看（投入金额、Star 数量、企业采用），开源确实在扩张。但从个体维护者层面看，多数人在撤退——关闭功能、减少工作量、转向自动化、寻求其他工作。
为什么？因为扩张和撤退是不同的视角。企业资助和大公司贡献者数量在增长，但同时小项目维护者的工作复杂度在剧烈上升——AI slop、合规压力、安全期望、用户增长。两条曲线都在升，但单个志愿者承受不住第二条曲线。
D. Richard Hipp 代表了一种异类策略。
Hipp 是 SQLite 的创建者和长期维护者。SQLite 是世界上部署最广的数据库引擎——估计在 1 万亿个实例。每台 iPhone、每台 Android、每台 Mac、每个浏览器、每个机顶盒、每个航空电子系统都有 SQLite。它的部署密度可能是地球上任何软件之首。
但 SQLite 不是由 SQLite Foundation 维护，也不是由 Apache Foundation 维护。它由 Hipp 自己的公司 Hwaci（Hipp, Wyrick & Company, Inc.）维护。Hwaci 是一家小公司——大概 5-7 个员工——所有员工都全职维护 SQLite 和提供商业支持。
Hipp 拒绝传统开源基金会模式。他不接受外部捐款（接受了也不知道怎么算），不发 GitHub Sponsors，不申请 Sovereign Tech Fund。Hwaci 的收入来源是商业 SQLite 支持合同——大公司付钱给 Hwaci，获得专业支持、合规帮助、定制开发。这个收入模式让 Hwaci 持续维护 SQLite 而不需要任何捐赠14。
2018 年 10 月，Hipp 做了一件让开源世界震惊的事。当外部压力（主要来自一些企业客户）要求 SQLite 采用一份正式的 Code of Conduct 时，Hipp 选了一份非常特殊的文档作为 SQLite 的 “Code of Ethics”：圣本笃修道院规则中“善行的工具”那一章——一份 6 世纪基督教修道院传统的伦理准则15。
文档要求开发者“不要杀、不要奸淫、不要诅咒、不要骄傲、要爱上帝”。
这件事在开源社区引起强烈反应。多数 maintainer 觉得这违反了开源的多元包容。Hipp 自己解释：他不要求用户信仰基督教，但他相信现代 Code of Conduct 文档（Contributor Covenant 等）的措辞太“vapid”（空洞）；圣本笃规则有一种“直接性”是他需要的16。
8 天后，SQLite 项目下了 “Code of Ethics”，改为采用 Mozilla 社区参与指南。但 Hipp 保留了原文档作为可选阅读。
这件事的意义不只是宗教信仰争议。它代表了一种 Hipp 与众不同的姿态：他不愿被现代企业开源文化吸收。他自己开公司、自己定规则、自己决定 SQLite 的方向。当外部期望（基金会化、专业化、合规化）跟他的偏好冲突时，他选择自己的方向。
这种姿态有代价——SQLite 不获得 Linux Foundation 那种企业网络效应；它不被列入 OpenSSF 的“关键项目”清单（虽然按部署规模它显然是最关键的之一）。但 Hwaci 模式保证了 Hipp 个人和 SQLite 项目的独立性。他不被任何公司或基金会的政治影响。
Hwaci 是当代开源世界一个独特的存在——一个小公司，做最关键的项目之一，自给自足，避开所有大型机构政治。这种模式不可能 scale——不可能每个 maintainer 都开一家公司——但它存在本身证明了：还有其他可能性17。
到 2024 年，Tidelift 做了一份相对系统的 maintainer 调查。覆盖 400+ 活跃 maintainer。一些关键发现：
这些数字看起来不算特别糟糕——25% + 19% 有部分资助听起来还可以。但要看分布：得到资助的多数是少数最知名项目（curl、PostgreSQL、Drupal、Linux 内核子系统等）。长尾的小项目——那些“内布拉斯加的某个人”项目——基本没有覆盖。
Tidelift 的研究还有一个让人想停下来的发现：maintainer 平均年龄在缓慢上升。Open Source maintainer cohort 在 2010 年代多数是 30-40 岁的工程师；2024 年这批人仍然在维护——意味着他们现在是 40-50 岁。新一代 25-35 岁的工程师没有以同等比例进入维护角色19。
为什么？多种因素：
如果这个趋势继续，10-15 年后，主流开源项目的 maintainer cohort 会出现自然衰减。Linux 内核现在有约 3000 个活跃 maintainer——其中相当一部分是 50+ 岁。Apache 各项目的 PMC 成员也类似。
这是开源运动面对的一个非常长期但非常重要的问题：它的物质基础是一代特定的工程师。这代人有特定的成长背景（90s 末-00s 初的互联网开源浪潮）。当他们退休或转行，没有自动机制保证下一代填补空缺。
现在把所有这些放在 xz 后门和 GitHub 2019 制裁的背景下看。
xz 攻击者选了 Lasse Collin 作为 target，不是因为 Collin 是“弱”——是因为 xz Utils 在“被全球依赖”和“个人维护”之间不平衡。这种不平衡不是 Collin 的错——它是开源生态的结构性特征。
GitHub 2019 锁伊朗账号也类似。被锁的伊朗开发者不是错的——他们用 GitHub 是自然选择。但他们暴露在“全球协作平台 + 美国制裁法律”的张力中。这种暴露不是个人选择——它是制度结构强加的。
把这两个东西放在一起，是这本书想说的核心：开源运动用 40 年时间建立了一个全球协作生态。这个生态依赖的是一群具体的人——维护者。但这群人现在同时面对几种压力——AI slop、国家级攻击、合规、骚扰——而支撑他们的基础设施远远不够。
如果维护者撤退，开源会怎样？
它不会一夜消失。Linux 仍然会被维护，Apache 仍然会运作，curl 仍然会工作。但长尾会消失——那些不知名的小项目、被广泛依赖的小库、被遗忘的关键组件——会一个个失去维护。当 xkcd 2347 的“内布拉斯加的某个人”决定不再维护时，被依赖的更大系统会缓慢侵蚀。
这个过程已经开始了。2024 年的 curl bug bounty 关闭只是一个早期信号。更多类似撤退会在 2026-2030 年发生。每次撤退本身不大——只是一个项目关一个功能、缩小一部分范围。但累计起来，会重塑开源的实际可用性20。
读到这里有人可能会问：那么开源运动应该怎么应对？
简单的回答还是：没有简单答案。
事实层面有几个方向被尝试中：
1. 政府资助。德国 Sovereign Tech Fund 是最明确的范例。它不是“补贴”——它是政府承认开源关键基础设施是公共物品，需要公共资助。这个模式 2022 年起在德国、荷兰、法国都在推。规模仍然小——总加起来每年几千万欧元——但方向是对的21。
2. 企业责任规范化。一些大公司（Microsoft、Google、AWS）通过 Alpha-Omega 等机制承担“关键基础设施贡献”责任。问题是这种贡献不是合同义务——是企业 PR 决定。如果哪天财务紧张，预算就会被砍。
3. 商业模式。Hwaci（SQLite）、wolfSSL（curl 部分）、Tidelift（中介）等代表不同的“开源 + 商业”组合。每个都解决一部分问题，但都不可 scale 到覆盖所有 maintainer。
4. 协作工具改进。Sigstore、SLSA、Reproducible Builds 让供应链更可验证——这能减轻 maintainer 的安全审计负担。GitHub Copilot、Cursor 等 AI 工具能让 review 速度提升。但同样的 AI 工具也是 AI slop 的来源——双刃剑。
5. 接受新现实。最现实的方向是：开源运动接受自己不再是“全球公地”，而是几个不同主权领地下的多个协作生态。Linux Foundation 在美国法律下运作，OpenAtom 在中国法律下运作，俄罗斯有自己的本土 forge，欧盟有 STF 的资助。每个生态有自己的规则，跨生态协作更困难。
这是这本书在第二卷想呈现的图景——具体的人，具体的处境，没有简单的英雄或反派。Stenberg 在他家里继续维护 curl。Collin 在芬兰继续做减少了的工作。Freund 在 Microsoft 继续做 PostgreSQL benchmark。Goers 在他全职公司继续工作，业余时间维护 Log4j。
他们都不在 Microsoft 总部签战略会议。他们不在国会作证。他们不在白宫的 OSS 圆桌讨论。但他们仍然是这个生态实际运转的人。
下一章我们要看的是这些维护者面对的另一个力量——不是 social engineering，不是 AI slop——是 国家制裁穿透代码。这是 GitHub 2019 和 Linux 2024 的故事。
curl 项目 stats 与部署规模估计。curl 官方页面声明 “the curl project… is used in billions of installations”。
Daniel Stenberg 的 Emails 归档页：https://daniel.haxx.se/email/toc.html
Daniel Stenberg blog 2021-02-19: “I will slaughter you”. Link →
Open Source Security Podcast 2025-05: “Curl vs AI with Daniel Stenberg”. Link →
Daniel Stenberg blog 2026-01-21: curl bug bounty 终止公告。包括“We need to make moves to ensure our survival and intact mental health” 引述。
Lasse Collin 2022-06-29 邮件原文。从 xz-devel mailing list 归档；Russ Cox 的 timeline 完整引述。Link →
Russ Cox: “Timeline of the xz open source attack”. 关于 Collin 不是疏忽的明确表态。
Microsoft Engineering blog: Andres Freund 个人简介（PostgreSQL upstream core developer）。
Andres Freund 在 Mastodon 与 oss-security 的 2024-04 复盘。强调“I am not a security researcher”和“luck”的细节。
Wikipedia: Log4Shell. 包括 Ralph Goers 全职工作在另一家公司的描述。Link →
The Register 2024-09-18: “Open source maintainers underpaid and going gray”. 包括 Goers 等人对 burnout 的关注。Link →
SQLite About 页面与 Hwaci 公司介绍。Hwaci = Hipp, Wyrick & Company, Inc. SQLite 是 public domain，但商业支持服务付费。
The Register 2018-10-22: “SQLite creator crucified after code of conduct warns devs to love God”. Link →
Christianity Today 2018-10: “Eat, Pray, Code: Rule of St. Benedict Becomes Tech Developer’s Community Guidelines”. 包括 Hipp 关于“vapid”的评价。
Packt Pub: “SQLite adopts the rule of St. Benedict… drops it to adopt Mozilla’s community participation guidelines, in a week”. 关于 SQLite Code of Ethics 的退让过程。
Tidelift 2024 maintainer survey. 详细数据：25% 从 GitHub Sponsors 等程序获得收入；19% 从 Tidelift 获得收入。Link →
The Register 2024-09-18: 同 ref-13。包括“open source maintainers going gray”的人口学观察。
2025-2026 多个开源项目缩减或关闭功能的案例：curl bug bounty 关闭、Drupal 限制非赞助贡献者 access、多个 npm 包公开“放弃维护”声明。
Sovereign Tech Agency 官方页面。包括 2022-2024 资助项目清单（curl、Drupal、Gnome、openSSH、systemd 等）。Link →
Vice: “The Internet Was Built on the Free Labor of Open Source Developers. Is That Sustainable?” 早期记录开源 maintainer 经济问题的深度报道。Link →
Rust Foundation 2021-11 moderation team resignation. 包括开源 governance 危机的另一面。Link →
InfoWorld: “How do we fund open source?” 综合分析多种资助模式。Link →
2019 年 7 月的一个星期，伊朗德黑兰的一个开发者打开 GitHub，发现自己几年来积累的私有 repo 全部不可访问。他在 Medium 上发了一篇愤怒的帖子，详细描述这种感受——“没有任何预警，没有数据导出选项，多年的工作变成不可读的乱码”1。
这篇帖子在几小时内被传遍英文 Hacker News、Reddit、Twitter。GitHub 的 CEO Nat Friedman 当天回应：是的，GitHub 必须遵守美国出口管制法律。位于伊朗、叙利亚、克里米亚的用户的私有 repo 已被锁定2。
那个星期是开源运动一个微妙的分水岭。
在那之前，“开源是全球公地”这种话术虽然有点理想化，但还能维持。GitHub 是个全球平台——任何人都能注册、贡献、协作。整个开源生态默认这种全球性。
那个星期之后，开源生态第一次直接面对一个事实：它最大的协作基础设施是一家美国公司。美国公司必须遵守美国法律。美国法律里有制裁条款。制裁条款会被执行。开源生态的“全球性”是有边界的——边界由美国财政部的 OFAC SDN list 决定。
这件事不是 2019 年突然出现的。它的法律基础在 2014 年克里米亚事件之后就建立了。GitHub 在 2014-2018 年期间对这种法律义务执行得比较松散——基本是“假装看不见”。但 2018 年 6 月 Microsoft 用 $75 亿美元买下了 GitHub，作为一家大型上市公司，Microsoft 的合规要求严格得多3。
2018 到 2019 年那段时间，Microsoft 应该是做了内部合规审查，决定 GitHub 必须开始执行 OFAC。具体哪个律师做的决定，公开材料里没有。但效果在 2019 年 7 月显化：伊朗、叙利亚、克里米亚账号被批量锁定。
具体被锁定的内容是这些：
没有被锁定的：
这种“读得了但贡献不了”的状态本身是个怪异的设计选择。它表面上保留了“信息可访问”，实际上让伊朗、叙利亚、克里米亚的开发者无法参与全球开源协作——他们能看代码，但不能修改、不能发 PR、不能 fork4。
执行方式不是按国籍——按 IP 地址 + 支付历史。这造成了大量误伤：
GitHub 后续获得了 OFAC 的一项 license，允许向伊朗个人开发者提供云服务（仍排除政府和被制裁实体）。这缓解了部分误伤，但没有改变结构事实7。
为什么 GitHub 在 2019 年开始这么做？为什么不是 2014 年或 2017 年？
答案有几层。
第一层是法律。OFAC SDN list 的执行理论上一直是强制性的。一家美国注册公司向 SDN list 上的实体提供服务在法律上违反 IEEPA（International Emergency Economic Powers Act）。但执行这个法律的强度取决于：（a）公司的合规态度；（b）OFAC 的监督资源；（c）政治环境。
2014-2018 年间，OFAC 主要执行金融制裁——禁止美国银行处理 SDN 账户。它对“软件服务”层面的执行较松散。但 2018-2019 年情况变了。Trump 政府对伊朗加码制裁（退出伊核协议、加强制裁体系），OFAC 资源向“科技服务”层面延伸。同时几个其他案例发生：
GitHub 在 2019 年才执行类似政策，已经是相对晚的——它当时仍然是 Microsoft 收购完成不到一年时的状态。Microsoft 内部合规团队应该是在 2018-2019 年期间完成审查，决定 GitHub 必须跟上其他 Microsoft 业务的 OFAC 标准8。
第二层是商业。Microsoft 在 2018 年 6 月以 $75 亿美元买 GitHub。这笔买入的核心价值是 GitHub 在企业市场的地位——它是全球最大的代码托管平台，财富 500 强公司多数都在用。任何 OFAC 违规事件如果发生，会被监管者用来挑战 Microsoft 的整体合规——这种风险对一家年营收 $1100 亿美元的公司来说不可接受。
第三层是政治。2018-2019 年正是美国政府对中国、伊朗、俄罗斯加码科技封锁的时期。OFAC 对软件服务的执行被纳入这个更大的政治议程。如果 GitHub 不主动合规，可能面临监管部门施压。
把这三层放在一起，2019 年 7 月的封锁就不是 GitHub 单独决定——是美国合规生态的整体演化结果。
让我们停下来看一个具体的人物——那位克里米亚的 GameHub 维护者。
GameHub 是一个 Linux 游戏管理器——给 Linux 用户提供一个统一界面管理 Steam、GOG、Epic Games 等不同游戏平台的库。它有几十万用户，主要是 Linux 桌面 enthusiasts。维护者一个人——一位住在克里米亚的乌克兰开发者。他在 GitHub 上维护项目，靠社区贡献 + 一点 Patreon 收入9。
2014 年俄罗斯吞并克里米亚之前，他是普通的乌克兰开发者。2014 年之后他“自动变成”克里米亚地区开发者——克里米亚被美国制裁体系视为俄罗斯吞并的领土，落入制裁范围。
5 年后，2019 年 7 月，他突然失去了 GitHub 私有 repo 访问。他可以读公共 repo，但无法 push、无法处理 PR、无法管理 issue。他在 GameHub 的 README 里发布了一份公开声明：他可能无法继续维护这个项目，因为他不能再用 GitHub 协作。
这件事没引起主流媒体多少关注。它是一个小项目，一个小开发者，一个不为人知的边缘地理。但它精确呈现了“制裁穿透代码”的一种典型方式：
这是开源运动在 2014 年之前没有正面回答过的一种状况：代码可以被任何人写，但平台不一定接受任何人贡献。GameHub 维护者仍然能在本地写代码——但他失去了把代码连接到全球协作流程的能力。
他后来怎么办？公开材料显示他尝试用 VPN（违反 GitHub TOS）、尝试自托管 Gitea（迁移工作量太大）、尝试请其他维护者代为发布（找不到稳定接手者）。GameHub 项目的活跃度从 2019 年起逐步下降。到 2026 年这个项目基本停滞——没有正式宣布“放弃”，但已经几个月没有 commit。这是制裁的具体代价：一个有用的开源项目缓慢死亡，因为它的唯一维护者失去了协作平台10。
GitHub 2019 之后五年，2022 年 2 月，俄罗斯入侵乌克兰。
这一次 GitHub 的反应比 2019 年精细。它没有像 2019 年那样按地理位置对俄罗斯境内所有用户广撒网。相反，它针对具体被制裁的俄罗斯实体：Sberbank（俄罗斯储蓄银行）、Gazprom（俄气）、被列入 SDN list 的国防工业实体、Yandex 的部分子公司等11。
这种精确化反映了几件事：
所以 GitHub 在 2022 之后采用了双轨：俄罗斯个人开发者基本不受影响；俄罗斯被制裁实体及其员工被精确封锁。这种精确化让“误伤减少”，但本质没变——美国法律决定了一家美国公司能服务哪些客户。
对俄罗斯生态的实际影响：
俄罗斯不是 2014 年的 GameHub 维护者那种小尺度——它是一个大国，有自己的科技生态。它对 GitHub 制裁的响应不是“个人放弃”，是“国家级迁移”。这种迁移本身证明了 GitHub 制裁的双向效应：当一个全球平台被国家化执行时，另一些国家会建立自己的备援。
把 GitHub 2019 和 GitHub 2022 看完之后，我们到 2024 年 10 月。
那个月最让开源社区震惊的不是 GitHub 的事——是 Linux 内核的事。
2024 年 10 月 18 日，Linux 内核 stable 分支负责人 Greg Kroah-Hartman 发送了一个 patch 到 LKML（Linux Kernel Mailing List）。这个 patch 修改 MAINTAINERS 文件——从中删除了 11 个名字。Greg KH 的 commit message 只有两句话：
“Remove some entries due to various compliance requirements. They can come back in the future if sufficient documentation is provided.”13
被删除的 11 个名字几乎全部是俄籍 maintainer。具体名字在不同来源报道里有差异（11、12、“more than a dozen”），但几乎所有使用 .ru 邮箱地址——多数关联到俄罗斯科技公司：Baikal Electronics（俄罗斯本土 CPU 厂商）、Yandex（部分子公司）、Open Mobile Platform、Linaro Russia 等14。
Baikal Electronics 在 2022 年被美国加入 OFAC SDN list。其他几家公司也在 list 上或被 list 上的母公司控制。
LKML 上立即有人质疑这个删除。Geert Uytterhoeven 是一位长期 Linux 开发者（受雇于 Sony），他在邮件中问：
Greg KH 没有详细回复。但后续邮件中，James Bottomley（受雇于 IBM 的 Linux maintainer，长期参与法律合规讨论）给出了精确回答：
“如果你的公司在 U.S. OFAC SDN list 上，受 OFAC 制裁项目约束，或被 list 上的公司拥有/控制，我们与你的协作能力将受限，你不能出现在 MAINTAINERS 文件中。”15
10 月 23 日，Linus Torvalds 出面表态。这是 Linus 第一次在这件事上公开说话：
“The change was done clearly, it’s not getting reverted, and multiple random anonymous accounts trying to reverse it wouldn’t change anything.”16
Linus 同时表达了个人立场——他明确反对俄罗斯入侵乌克兰，所以他个人也支持这个合规决定。但他强调核心不是个人立场，是法律合规：Linux Foundation 是美国注册的非营利组织，必须遵守 OFAC。
要看清楚 2024 年 10 月这件事，需要看 Linux Foundation 的法律身份。
Linux Foundation 是个 501(c)(6) 贸易协会，注册在加州（后来迁到 San Francisco / Delaware）。它的会员是公司（Google、IBM、Microsoft、Huawei 等），不是个人 maintainer。它的角色是：
注意这个角色清单的最后一项。Linux Foundation 是法律实体，它必须遵守注册地法律——美国法律。这就给了 OFAC 一个直接的杠杆点：如果 LF 不遵守 SDN list 约束，OFAC 可以起诉 LF；如果 LF 被起诉，整个 Linux 项目的法律基础设施会被冻结。
Greg KH 作为 LF Fellows，他的工资从 LF 来。他执行 OFAC 合规不是因为他个人有政治立场——是因为他作为 LF 员工有合同义务遵守 LF 的合规决定。LF 的合规决定必然是“我们不能让 SDN list 上的实体的员工保持 maintainer 状态”。
这就是 2024 年 10 月那个决定的真正逻辑。它不是某个人的选择——它是法律实体身份的必然结果。
读懂这一点，几个 derivative 结论变得明显：
每个项目的“对 OFAC 暴露程度”取决于：（a）注册地是不是在美国；（b）有没有 maintainer 在被制裁实体工作；（c）项目治理结构是否允许中央化合规决定。Linux 在三个维度上都“高暴露”。所以 2024 年 10 月发生在 Linux 上，不是偶然。
被删除的 11 名俄籍 maintainer 是谁？
公开材料中，一些名字被报道过（LWN.net 的文章包含部分名单），但本书不重复点名——保护他们的隐私是基本伦理。可以说的是这些人的共同特征：
Bruce Momjian——PostgreSQL Core Team 创始成员之一——在 2022 年俄乌战争后接受 Percona Community 播客采访时谈过类似情况（PostgreSQL 中的俄籍贡献者）。他的核心观察：
“We have a lot of contributors from Russia. Many of them have been with us for many, many years. Most of them, when this war started, were privately devastated. Some of them, we even know personally that they oppose the war. But they can’t say it publicly because they live in Russia.”18
把这段话放到 Linux 11 人事件上读：被删除的 maintainer 中，有相当一部分人个人是反战的——但他们在俄罗斯生活和工作，公开表达反战立场会让他们失去工作甚至个人安全。结果是他们处在一个不可解的困境：他们没法证明自己个人立场，但他们的雇主关联让他们被列为合规风险。
LF 处理这件事时的“留口子”机制——“They can come back in the future if sufficient documentation is provided”——理论上让被删除的人可以通过证明“我的雇主不在 SDN list 上”来回归。但实际上：
到 2026 年 5 月（事件 19 个月后），没有任何公开记录显示有任何一名被删除的 maintainer 已经回归19。“门是开着的”在实操中是“门关上了”。
把 GitHub 2019 + Linux 2024 放在一起看，会发现一个清晰的轨迹。
国家级（2019）：广撒网。所有伊朗、叙利亚、克里米亚 IP 都被锁。误伤率很高。 实体级（2022 俄罗斯）：精确化。只针对 SDN list 上的具体公司及其员工。误伤减少。 Maintainer 级（2024 Linux）：高度精确。具体到 MAINTAINERS 文件里的 11 个名字。完全没有误伤——但也没有任何缓冲。
每一步都让制裁的执行更精确、更深入。从“基础设施访问”到“协作能力”到“贡献者身份”。
这种深入有政治含义。早期“国家级”封锁可以被解读为“美国针对几个特定国家”——这种叙事虽然让被影响的人不开心，但至少能被理解为“标准的国际政治”。
到“maintainer 级”封锁，叙事变了。它不再是“美国 vs 几个国家”——是“美国法律穿透了开源协作的具体结构”。一个 Linux 内核某子系统的 maintainer，因为他/她个人雇主关联，被从 MAINTAINERS 文件删除。这件事在 Stallman 1985 年写 GNU Manifesto 时是完全不可想象的——它把“代码协作”和“国家合规”之间的距离压到了零。
这种“距离压到零”的状态有一个不容忽视的反向效果：它在加速反向主权化。
中国 2020 年成立 OpenAtom Foundation，明确目标是建立“不依赖美国法律实体”的开源基础设施。openEuler、OpenHarmony 等项目都迁到这个基金会。这个决定在 2020 年看起来是“中国主权战略”——但从 2024 年 Linux 11 人事件的角度看，它是预见性的。OpenAtom 让中国开源项目不再暴露在 OFAC 风险下——至少不直接暴露20。
俄罗斯 2022 年 Decree 166 强制国企迁移本土软件——同样的逻辑。它不是“反美主义”——是承认“如果继续依赖美国法律实体的开源平台，会被穿透”。
欧盟 2022 年成立 Sovereign Tech Fund——同样的逻辑的温和版本。德国政府意识到“开源关键基础设施”需要“主权资助”——不能完全依赖美国公司的善意。
每一个反向主权化措施都被 2019 → 2022 → 2024 的精确化轨迹加速。当美国制裁穿透开源协作越深，其他国家越有动力建立平行生态。
到 2026 年初，这种“reactive sovereignty”已经是开源世界的实际地图。Linux 仍然是全球项目——任何人都可以贡献——但 Linux Foundation 在美国，OFAC 风险是底层事实。OpenEuler 是中国项目——它在中国合规框架下运作，避开 OFAC，但也避不开中国的网信办备案。Astra Linux 是俄罗斯军用项目——它处理俄罗斯国防部 + 国资委的需求，在西方制裁环境下完全自给。
每一个生态都不“全球”——每一个都被某个国家主权框架定义。但它们之间仍然存在协作——比如 Linux kernel 仍然 accept 来自世界各地的贡献（只是不能让 SDN list 上的人当 maintainer）。这是一种新的、复杂的、不舒服的状态：开源仍然是开源，但它运行在分裂的主权地图上21。
最后回到那个 2024 年 10 月 18 日的 Greg KH 邮件。
那两句话——“Remove some entries due to various compliance requirements. They can come back in the future if sufficient documentation is provided.”——表面上是无情的官僚语言。但读懂它的具体含义，会理解 Greg KH 在那个时刻的真实处境。
Greg KH 不是政治推动者。他是 Linux stable 分支的技术 maintainer，从 2000 年代就开始做这件事。他个人对俄罗斯入侵乌克兰的态度跟很多西方工程师一样——反对，但不是 activist。他做这个删除不是因为他想做——是因为他作为 LF Fellows 有合规义务22。
那两句话的官僚语调，其实是一个长期 maintainer 在做一件他知道会引起争议的事时的自我保护。他没有为决定辩护——因为没法辩护成“合理的”。他也没有谴责俄罗斯——因为这不是他的角色。他只是冷静地宣布：合规要求让这 11 个名字必须移除；如果有人能证明自己不在合规风险里，可以回来。
这种语调有一种荒诞感。它把一个深刻的事件——开源运动结束“代码不分国界”姿态的官方时刻——降到了行政语言层面。它不为大事件做大宣言；它只为合规决定做合规说明。
但这种降级本身就是 2024 年的现实。开源运动没有一个集中的领导能给出“我们要怎么应对这种穿透”的回答。Linus Torvalds 也好，Greg KH 也好，Stallman 也好，Bruce Behlendorf 也好——没有一个人有权威给一个统一答案。每个项目、每个基金会、每个 maintainer 自己处理自己的合规问题。
整个开源生态因此正在分散响应——而分散响应的总和，就是我们在 2024 年 10 月看到的：Linux Foundation 执行 OFAC，OpenAtom 建立中国基础设施，俄罗斯迁移本土，Sovereign Tech Fund 资助欧洲项目，每个区域生态有自己的规则。没有一个统一的“开源运动”立场——只有几个并行的应对策略。
下一章我们要看的是这些应对策略的具体形态——各国的 OSS 国家战略。中国信创、俄罗斯 Astra、欧洲 STF、印度 India Stack——这些不是“反对开源”，是开源在主权穿透下的具体化。
TechCrunch 2019-07-29: “GitHub confirms it has blocked developers in Iran, Syria and Crimea”. 引述伊朗开发者 Medium 帖。Link →
GitHub Docs: GitHub and Trade Controls. 详细描述 sanctioned regions 的具体限制。Link →
Tom’s Hardware: “GitHub Blocks Iran, Syria and Crimea-Based Users”. 包括拉脱维亚误伤的描述。Link →
GameHub 项目 README 中 2019 年的公开声明，由维护者发布。Tom’s Hardware 等媒体引述。
GitHub Trade Controls page 包括 OFAC license 描述。2021 年 GitHub 获得 license 向伊朗个人开发者提供服务。
DevPro Journal: “GitHub Restricts Accounts Based on U.S. Export Control and Sanctions Laws”. Link →
关于 GitHub 2022 俄罗斯精确化制裁的报道。多家媒体（TechCrunch、Bloomberg、Wired）报道相关具体案例。
Wikipedia: Astra Linux. 包括俄罗斯 Decree 166（2022-03-30）的描述。Link →
Greg KH 2024-10-18 LKML patch 原文。LWN.net 完整引述。Link →
The Record from Recorded Future: “Linux creator approves de-listing of several kernel maintainers associated with Russia”. Link →
The Register 2024-10-23: “Linus Torvalds affirms expulsion of Russian maintainers”. 包括 Linus 表态原文。Link →
Linux Foundation Annual Report 2023. 描述 LF 的法律角色和会员结构。Link →
Percona Community Podcast 68: Bruce Momjian “Impact of the War in Ukraine on the PostgreSQL Community”. Link →
LWN.net 与其他 Linux 跟踪报道。截至 2026-05 没有公开记录显示被删除 maintainer 已回归。
Wikipedia: OpenAtom Foundation. 2020-06 成立，中国第一个开源软件基金会。Link →
Jamestown Foundation: “Open-Source Technology and PRC National Strategy: Part I”. 包括 OpenAtom 战略意义分析。Link →
Digital Watch Observatory: “Linux creator supports removing Russian kernel maintainers”. 综合性报道。Link →
FreeBSD Forums: “Linus Torvalds affirms expulsion of Russian maintainers”. 开源社区不同立场的讨论。Link →
OSTechNix: “Several Russian Maintainers Removed From Linux Kernel”. Link →
Linuxharbour: “Linux Creator Supports Removing Russian Kernel Maintainers”. 中立性梳理。Link →
U.S. Department of the Treasury OFAC: Specially Designated Nationals And Blocked Persons List. SDN list 是核心法律工具。
2020 年 6 月，北京举行了一次没有引起西方科技媒体多少注意的发布会。中国工业和信息化部支持成立了一个叫做“开放原子开源基金会”（OpenAtom Foundation）的机构。发起方包括阿里巴巴、百度、华为、浪潮、奇虎 360、腾讯、招商银行——中国互联网与金融业的几乎所有主要玩家1。
OpenAtom 的定位明确：中国第一个开源软件基金会。它的注册地在北京，它的治理结构受中国法律管辖，它的会员主要是中国公司。表面上，它和 Linux Foundation、Apache Software Foundation 是同一种东西——给开源项目提供法律保护和治理框架的非营利机构。但它的战略意义完全不同。
如果你是 2020 年的中国大公司，你想做一个开源项目，你以前的选择是什么？基本只有：把代码放到 GitHub（美国公司），让 Linux Foundation 或 Apache Software Foundation（都在美国）做托管。这意味着你的项目的法律保护、商标、治理决定都受美国法律管辖。
2014-2018 年间这种安排还行——大家假装“代码协作”和“国家法律”是两件无关的事。但 2019 年 GitHub 锁伊朗账号、2018 年华为被列入实体清单、2020 年 TikTok 在美国面对的强制剥离威胁——这些事件让中国大公司同时认识到一件事：如果一个项目的法律基础设施在美国，那么它在美国 vs 中国冲突升级时是不可靠的2。
OpenAtom 是对这个认识的体制化回应。它让中国公司可以做一种新的选择：把项目放到中国注册的基金会。法律基础设施在中国，受中国法律保护，不暴露在 OFAC 风险下。
OpenAtom 在 2021 年开始接收第一批旗舰项目。
openEuler 是 OpenAtom 的第一个标志性项目。它的前身是华为 EulerOS——一个基于 CentOS 的服务器 Linux 发行版，华为内部用了多年。2020 年 1 月华为在 Gitee 上开源 EulerOS，更名为 openEuler3。2021 年 11 月 9 日，华为正式把 openEuler 捐赠给 OpenAtom——所有权从华为公司转给基金会4。
这跟 Meta 2022 年 9 月把 PyTorch 捐赠给 Linux Foundation 形式上一样——都是企业项目“中立化”到基金会层面。但政治含义不同：openEuler 进入了一个中国注册基金会，PyTorch 进入了一个美国注册基金会。每个都对应不同的法律保护与不同的政治风险5。
openEuler 的发展速度在 2021-2024 年很快。CentOS 在 2020 年 12 月宣布停止维护 CentOS 8 稳定分支，转向 CentOS Stream 滚动发布——这是 Red Hat（IBM 子公司）的商业决定。但它造成了一个大空缺：依赖 CentOS 稳定分支的企业（包括大量中国企业）需要找替代。openEuler 抓住了这个机会。到 2024 年，OpenAtom 公开声明 openEuler 在中国服务器市场份额超过传统 CentOS 衍生品6。
OpenHarmony 是另一个 OpenAtom 旗舰。它的前身是华为 HarmonyOS（鸿蒙）的开源部分。HarmonyOS 是华为 2019 年发布的跨设备操作系统——手机、电视、IoT、汽车都能跑。它的开源部分（OpenHarmony）覆盖较核心的内核与基础组件。
OpenHarmony 的战略意义是：在 Android 之外建立 mobile OS 备援。Android 虽然是开源的（AOSP）但实际部署严重依赖 Google Mobile Services（GMS）——闭源的 Google API 层。华为被美国制裁后失去 GMS 访问，2020-2021 年这成为华为手机销量崩溃的直接原因。OpenHarmony 是一个尝试——能不能建立一个不依赖 GMS 的、真正自给自足的 mobile OS 生态7。
到 2026 年初，OpenHarmony 在国内市场已经覆盖一部分手机（华为、荣耀部分机型）、IoT 设备、车机。但它在国际市场仍然非常有限——海外几乎没有应用生态。这是它跟 Android 的根本不同：Android 有真正全球化的开发者生态，OpenHarmony 暂时还没有。
OpenAtom 之外，中国 OSS 国家战略最重要的部分是 “信创”。
信创 = 信息技术应用创新。这个术语在 2018-2019 年成为中国政策语言。背景是 2018 年中兴被制裁、2019 年华为被列入实体清单——这两个事件让中国官方意识到核心 IT 基础设施被美国制裁的脆弱性。
信创政策的核心是：关键信息基础设施单位必须使用国产软硬件。具体执行包括：
具体的国产替代品：
这些产品大部分是基于开源软件的衍生版——麒麟 OS 基于 Linux + Ubuntu，统信 UOS 基于 Debian，达梦数据库内核有 PostgreSQL 影响。但它们都做了大量定制和适配——满足中国合规要求、加上自己的认证体系、绑定特定硬件等。
信创政策给了这些产品一个强制需求市场。在政府强制比例的支持下，这些产品不需要在自由市场跟微软 / Oracle / RedHat 竞争——它们已经被预设是关键基础设施的合规选择。到 2023 年起，信创进入“全面应用”阶段，预计覆盖到全国所有关键基础设施9。
“安全可控”是中国 OSS 政策的另一个关键概念。
这个术语出现在《网络安全法》（2017）和《关键信息基础设施安全保护条例》（2021）。它的字面意思是“安全 + 可控”——但实际执行有具体含义：
对开源软件的影响：上游 OSS（Linux 内核、Apache 项目、各种工具）本身受影响较小——它们的源代码是公开的，可被审查。但实际部署时需要通过“可信渠道”获得——意思是从中国维护的镜像或经过中国认证的 distributor 获取。
这是中国 OSS 政策一个微妙但重要的特点：它不禁止开源软件——大多数中国关键基础设施仍然在用 Linux 内核（事实上 openEuler、麒麟 OS 都是 Linux）。它只是要求开源软件通过国家可控的渠道进入关键场景。这跟美国 EO 14028 要求 SBOM 是同样的逻辑——不禁止使用，但要求可追溯10。
RISC-V 是中国 OSS 战略最有意思的一块。
RISC-V 是一个开放的指令集架构（ISA）——由 UC Berkeley 在 2010 年开始的学术项目，2015 年成立 RISC-V Foundation，2019 年从 Delaware 迁到瑞士（避免美国出口管制）。它的核心特点是开放标准 + 任何人可实现——不像 ARM 需要付授权费，也不像 x86 只有 Intel 和 AMD 能做。
中国对 RISC-V 的投入从 2018 年起急剧增加。阿里巴巴成立平头哥半导体（T-Head），主推 RISC-V 芯片设计。阿里达摩院的玄铁系列 RISC-V 处理器——C906（消费级）、C910（服务器级）、C930（高性能计算）——是中国 RISC-V 战略最直接的体现11。
2025 年 2 月，阿里发布玄铁 C930——首款国产 RISC-V 服务器级处理器，针对数据中心服务器和自动驾驶等高性能计算应用12。同年，中国政府发布 RISC-V 推广指南——这是世界上首个明确把 RISC-V 列为关键战略技术的国家政策13。
中国对 RISC-V 投入的战略逻辑很清楚：
但这个逻辑面对一个 backstop。美国商务部 2024 年 4 月开始对中国使用 RISC-V 进行调查——担心 RISC-V 国际基金会（虽然在瑞士）可能被某种形式纳入管制14。一些美国国会议员公开呼吁对 RISC-V 引入“开放但有审查”的机制——比如禁止美国工程师参与某些被中国主导的 RISC-V 工作组。
这是开源运动对“主权穿透”的一个有趣测试。RISC-V Foundation 2019 年迁瑞士本来就是为了避免被任何单一国家管辖。但如果美国国会立法禁止美国工程师参与 RISC-V 工作组，效果跟“管辖瑞士基金会”差不多——它在美国领土上限制美国公民对 RISC-V 的贡献。这种“间接管制”是 Bernstein 案没有覆盖的领域15。
俄罗斯的 OSS 国家战略跟中国不同。它没有 OpenAtom 这种统一基金会——但它有 Astra Linux 这种军用 OS 项目。
Astra Linux 是俄罗斯 RusBITech 公司从 2008 年起开发的 Linux 发行版。它最初是为俄罗斯军队和情报机构定制的——满足俄罗斯军方信息分级要求、防泄密、防西方监控。到 2018 年俄罗斯军方正式宣布将全面用 Astra Linux 替代 Windows16。
2022 年俄乌战争后，Astra Linux 的应用扩展超出军方。Microsoft 在 2022 年宣布退出俄罗斯市场——所有 Windows 和 Office 服务停止；2022 年 3 月 30 日俄罗斯总统签 Decree 166——禁止国家机关和处理关键信息的设施使用外国软件，要求 2025 年前完成迁移17。Astra Linux 成为最大的国产替代候选。
到 2026 年 Astra Linux 已经被部署到俄罗斯多数政府机构、国企、国防工业。Astra Linux 自己 2022 年 7 月宣布要在莫斯科证券交易所上市。这跟中国信创类似——一个有强制采购支持的国产 OS 项目。
ALT Linux 和 ROSA 是俄罗斯另外两个本土 Linux 发行版。ALT 主要用于教育系统（学校）和俄罗斯本土 CPU Elbrus 的支持；ROSA 是个相对小众的桌面 Linux。这些项目跟 Astra 一起构成俄罗斯 Linux 生态的本土版图18。
俄罗斯没有 OpenAtom 那种统一基金会——这反映了俄罗斯 IT 生态的特点：项目分散，公司之间合作较少，国家驱动更明显。每个项目（Astra、ALT、ROSA）都有自己的公司主体，靠国家合同生存。
欧盟 OSS 战略走了完全不同的路径。
欧盟不像中国那样建立“国产替代”项目（欧洲没有“欧产 Linux”），也不像俄罗斯那样军方主导。欧盟主要做两件事：资助 和 监管。
资助 的旗舰是 Sovereign Tech Fund (后改名 Sovereign Tech Agency)。德国联邦议会 2022 年拨款 €3.5 million 每年，资助关键开源项目——cURL、Drupal、Gnome、openSSH、systemd、Sequoia PGP 等。每个项目获得 €50K 到 €1M 不等。到 2024 年底 STF 已经支持了 60+ 个项目19。
STF 的逻辑很清楚：欧洲承认开源关键基础设施是公共物品，应该用公共资金维护。它不试图建立“欧洲版 Linux”——它直接资助已经存在的全球关键项目的德国 / 欧洲维护者。这是个相对务实的方法：你不需要重新发明轮子，你只需要确保维护轮子的人能继续工作。
德国之后，荷兰（2023 启动 Open Source Sustainability Programme）、法国（2024 启动）、欧盟整体（2024 年开始考虑欧盟级 sovereign tech fund）都跟进了类似项目。规模仍然小——总加起来每年几千万欧元——但方向明确20。
监管 的旗舰是 Cyber Resilience Act (CRA)，2024 年 10 月通过，2026-2027 全面生效。我们在第 9 章会详细谈 CRA 的具体规则。这里只需要知道：CRA 是欧盟试图把“产品安全”原则扩展到软件——包括开源软件。它的“open source steward” 概念专门针对 Eclipse Foundation、Linux Foundation Europe 等基金会，给它们正式的 cybersecurity 责任21。
欧盟的双轨——资助 + 监管——是一种 distinctly European 的方法。它承认开源是公共物品（需要资助），但也要求开源遵守消费者保护标准（需要监管）。两者一起，是欧盟对“美国主导 + 中国国家主导”的 OSS 世界的第三种回应。
印度的 OSS 战略与上面三个都不同。
印度没有 OpenAtom 那种基金会，没有 STF 那种资助计划，没有 Astra Linux 那种本土 OS。印度做的事是用开源构建国家数字基础设施——一种叫做 India Stack 的开放数字公共物品体系22。
India Stack 包括：
这些系统的关键特点：它们都是 开源 + 政府开发 + 国家级标准。印度政府不让 Google、Amazon、阿里 builds 这些系统——印度政府自己开发，开放源代码，提供免费 API。所有印度银行、电商、电信公司都必须接入这些 API。
India Stack 的战略意义：它把开源从“代码”扩展到“基础设施”。一个国家的数字身份、支付系统、健康记录系统、教育系统都建在开源协议上。这种模式不只是技术选择——它是主权战略。如果支付系统是 Visa（美国公司）控制的，那么美国制裁可以瘫痪印度金融；如果支付系统是 UPI（印度开源），印度可以完全自主25。
到 2026 年 2 月，印度已经与 23 个国家签署协议——共享 India Stack 的数字基础设施模型。这是开源战略的国际化输出。东南亚、非洲、拉美一些国家在采纳 UPI 类似设计、DigiLocker 类似框架。印度正在把“开源国家基础设施”作为软实力26。
四种国家战略放在一起对比：
| 国家 | 主要工具 | 核心逻辑 |
|---|---|---|
| 中国 | OpenAtom + 信创 + 安全可控 + RISC-V | 国产替代 + 国家可控 |
| 俄罗斯 | Astra Linux + Decree 166 | 军方驱动 + 强制迁移 |
| 欧盟 | Sovereign Tech Fund + CRA | 资助 + 监管 |
| 印度 | India Stack | 开源公共基础设施 + 软实力输出 |
每种战略反映了该国对开源的特定理解：
注意一个共同点：这四种战略都不是“反对开源”。每个国家都在用开源，都在投资开源，都把开源视为对自己有利的东西。区别只在于如何使用、如何监管、如何安置。
这跟简单的“开源 vs 反开源”叙事完全不同。2014 年之前，开源运动的内部冲突是“开源 vs 专有”——Stallman 反对专有软件，OSI 推广开源对 IBM 的吸引力。2024 年后，主要冲突变成“美国主导的开源 vs 其他主权下的开源”——大家都用开源，只是不同的国家想用不同方式控制它27。
读到这里有人可能会问：被切断者（伊朗、朝鲜、古巴、缅甸）怎么办？
这是 OSS 战略的另一个极端——那些没有大国资源、没有 OpenAtom、没有 STF 的国家如何应对全球开源被穿透的现实。
伊朗 的具体应对：
朝鲜 的应对：
古巴：
缅甸：
这些“被切断者”的处境精确反映了 OSS 全球化的代价。他们没有大国资源建立平行生态——他们只能依赖 VPN、流亡开发者、私人镜像等 ad hoc 方法。他们的开发者继续工作（很多在做高质量贡献），但他们对全球协作的接入是脆弱的、可被随时切断的29。
读这些案例让人想停下来。一个在德黑兰的工程师写代码贡献到一个 Apache 项目——他在做技术工作，跟任何政治议程没关系。但他能不能 push 他的 commit 到 GitHub，取决于美国对伊朗的制裁是松还是紧、取决于 GitHub 合规算法的精确度、取决于他的 IP 地址是否被检测出来。
这种“技术工作的可达性依赖外国政治”在 2014 年之前是不存在的。它是 2014-2024 这十年的产物——开源运动从“全球公地”过渡到“主权领地”过程中的副产品。
把所有这些国家战略放在一起，能看到一个新的世界地图：
美国生态：Linux Foundation、Apache、CNCF、PyTorch Foundation、Mozilla、OpenSSF。注册在美国，受 OFAC 约束。主导全球大型开源项目。但暴露在美国法律对维护者权限的限制下。
中国生态：OpenAtom（openEuler、OpenHarmony）+ 信创替代 + Gitee。注册在中国，受网信办约束。主要服务国内市场，对国际化有限。
俄罗斯生态：Astra Linux + ALT Linux + GitFlic + 自托管 GitLab。受俄罗斯法律和西方制裁双重约束。基本只服务国内。
欧盟生态：Sovereign Tech Fund 资助 + CRA 监管。不试图建立“欧产 Linux”，而是资助全球项目的欧洲维护者 + 把开源纳入消费者保护框架。
印度生态：India Stack。开源国家基础设施，开放给国际伙伴。软实力输出方向。
瑞士中立点：RISC-V International。注册瑞士避险，但其成员公司仍受各自国家法律约束。
每个生态各有规则、各有强项、各有弱点。它们之间仍然有协作——任何人都可以 fork Linux、任何人都可以贡献 PostgreSQL、任何人都可以下载 PyTorch。但协作的法律边界已经被国家主权切割。
2024 年 10 月 Linus 删除 11 名俄籍 maintainer 是这个新地图最清晰的边界标识。它说：你可以贡献代码，但如果你的雇主在 SDN list 上，你不能进入正式 maintainer 名单。
到 2026 年，这种“协作但有边界”已经是常态。下一章我们要看的是这些边界如何穿透到具体的项目——Linux、NGINX、ClickHouse、PyTorch、Apache 中国主导项目、Tor、RISC-V——每个项目都有自己的地缘政治面孔。
Wikipedia: OpenAtom Foundation. 2020-06 成立，工信部支持，由阿里、百度、华为、浪潮、奇虎 360、腾讯、招商银行等共同发起。Link →
Jamestown Foundation: “Open-Source Technology and PRC National Strategy: Part I”. 提供中国开源战略的政治背景分析。Link →
Wikipedia: EulerOS. 包括华为 EulerOS 2020 年 1 月在 Gitee 上开源为 openEuler。Link →
Caixin Global 2021-11-10: “Huawei Donates Operating System to Chinese Tech Nonprofit”. Link →
Linux Foundation 2022-09-12: “Meta Transitions PyTorch to the Linux Foundation”. Link →
Huawei Central: “Open Source HarmonyOS and Euler are growing faster: OpenAtom Foundation”. Link →
Huawei: openEuler-LTS 2020-03 announcement. Link →
《中华人民共和国网络安全法》（2017）、《关键信息基础设施安全保护条例》（2021）。“安全可控”在多个政策文件中作为核心术语。
South China Morning Post: “Alibaba’s chip unit T-Head steps up RISC-V development as China pushes the open-source architecture in face of US sanctions”. Link →
HPCwire 2025-02-28: “Alibaba Launches C930 RISC-V Chip Amid Shift from Western Tech”. Link →
Tom’s Hardware: “Alibaba claims it will launch a server-grade RISC-V processor this year”. 包括中国 2025 推广指南。Link →
The Register 2024-04-24: “US government reportedly probes China’s use of RISC-V”. Link →
CSIS: “Sustaining Standards Leadership: The United States Cannot Disengage from RISC-V”. Link →
Wikipedia: Astra Linux. 2018 年俄罗斯军方决定迁移到 Astra。Link →
Wikipedia: RusBITech. 关于俄罗斯本土 Linux 公司的描述。Link →
Sovereign Tech Agency 项目页面。Wikipedia: Sovereign Tech Agency。Link →
Interoperable Europe Portal: “Funding open source: case study on the Sovereign Tech Fund”. 包括 STF 模式扩散到其他欧洲国家的描述。Link →
Wikipedia: Cyber Resilience Act. Link →
Wikipedia: India Stack. Link →
Wikipedia: Unified Payments Interface. 包括 UPI 2026 年 1 月统计数据。Link →
BHASHINI 官方页面与 GitHub organization (https://github.com/bhashini-dibd)。Bhashini 2022 年 7 月由总理启动。
India Stack 官方页面。Link →
BusinessToday: “Here’s how India’s Digital Public Infrastructure is going global”. 包括 23 国合作协议数据。Link →
Liontrust Asset Management: “India’s tech stack: public rails, private ingenuity”. Link →
Communications of the ACM: “Anti-Sanctions: New Operating System for Mobile Devices”. 关于伊朗等被切断国家应对的描述。Link →
Tom’s Hardware: “Alibaba’s new RISC-V chip hits the mark for China’s tech self-sufficiency drive”. Link →
eeDesignIt: “Can China’s RISC-V Revolution Reshape the Global Chip Industry?”. Link →
2019 年 3 月 11 日，F5 Networks——一家美国西雅图的网络设备公司——宣布以 6.7 亿美元收购 NGINX 公司。NGINX 的两位创始人 Igor Sysoev 和 Maxim Konovalov，以及当时的 CEO Gus Robertson，正式加入 F51。
要理解这笔收购的政治含义，需要回溯 NGINX 的来历。
Igor Sysoev 是俄罗斯人。1990 年代后期，他在莫斯科为 Rambler——当时俄罗斯最大的搜索引擎——做系统管理员。Rambler 在 2002 年遇到一个问题：他们的 Apache HTTP Server 在高并发场景下性能不够。Sysoev 决定自己写一个新的 Web 服务器，专门为高并发场景优化。这就是 NGINX 的开端2。
2004 年，Sysoev 发布 NGINX 0.1.0。它的核心创新是 event-driven 架构——一个进程能处理上万个并发连接，而当时的 Apache 是 thread-per-connection 模型，几千个连接就会让服务器崩溃。NGINX 立即在高流量网站中获得采用——Yandex（俄罗斯版 Google）、VKontakte（俄罗斯版 Facebook）、Mail.ru 都是早期用户。
NGINX 一直是 Sysoev 个人维护的开源项目。它用 BSD 风格的许可证，意味着任何人可以自由使用、修改、衍生作品。到 2011 年，NGINX 在全球高流量网站市场份额已经超过 Apache。Sysoev 决定围绕开源 NGINX 创建一家商业公司——NGINX Inc. 在莫斯科成立，提供企业级支持和商业版（NGINX Plus）3。
公司发展顺利。到 2018 年，NGINX 是全球部署最广的 web 服务器之一——估计在 4 亿+ 网站4。但 2018-2019 年发生了几件事改变了它的命运：
F5 收购 NGINX 完成于 2019 年 5 月。这个收购在表面上是普通商业交易——一家美国公司买了一家俄罗斯创业公司。但它的实际意义是把 NGINX 的法律实体从俄罗斯迁到美国。Sysoev 和 Konovalov 后续也离开了 F5——分别在 2022 年和 2023 年。他们没有公开抱怨，但实际效果是：NGINX 的开源项目仍然存在，但它的法律和管理已经完全美国化。
2022 年 俄乌战争开始后，NGINX 的位置变得清楚：它是个“逃离俄罗斯”的开源项目，避免了 Astra Linux、ALT Linux 那种“被制裁”的命运。但 Igor Sysoev——一个在俄罗斯长大的工程师，写了世界部署最广的 web 服务器之一——他不能再在俄罗斯做这个项目了。
ClickHouse 是另一个“逃离俄罗斯”的故事。
ClickHouse 是一个 column-oriented 分析数据库——为大数据 OLAP 工作负载优化。它的创建者 Alexey Milovidov 2009 年在 Yandex 写下第一行代码。当时 Yandex 需要一个能快速分析点击流的数据库——传统 MySQL/Oracle 不行，开源 Hadoop 太慢。Milovidov 和他的团队写了 ClickHouse，作为 Yandex 内部工具6。
2016 年 Yandex 把 ClickHouse 开源（Apache 2.0 license）。开源后几年，它迅速被全球数据团队采用——Cloudflare、Uber、Bloomberg、阿里、字节跳动都成为重要用户。到 2020 年它已经是全球部署最广的开源分析数据库之一。
但 ClickHouse 仍然由 Yandex 控制。Milovidov 和团队是 Yandex 员工，所有开发资源由 Yandex 提供。2021 年这种状态开始改变。
2021 年 9 月 20 日，Yandex 宣布把 ClickHouse 剥离成独立公司。ClickHouse, Inc. 在 Delaware 注册——美国公司。Milovidov 和团队从 Yandex 离职，换 RSU 为新公司的早期股权，搬到阿姆斯特丹7。
公司联合创始人除了 Milovidov 之外是 Yury Izrailevsky（前 Netflix VP）和 Aaron Katz（前 Elastic 业务）。Milovidov 任 CTO，Izrailevsky 管产品和工程，Katz 任 CEO。Series A 融资 5000 万美元，由 Index Ventures 和 Benchmark 主导，Yandex N.V. 等参与8。
注意时间。这个剥离 2021 年 9 月完成——俄乌战争前 5 个月。Milovidov 和团队搬到阿姆斯特丹——俄乌战争前几个月。这不是事后诸葛——这是一次相当精确的“主权风险预见”。
2022 年 3 月，俄乌战争升级后，ClickHouse 公司发布了一份公开声明 “We Stand With Ukraine”——表达对乌克兰的支持，谴责俄罗斯入侵9。这种立场对一个起源于 Yandex 的项目来说是个明确的“切割”——ClickHouse Inc. 跟俄罗斯 Yandex 的关联从此被法律和声誉两个维度都最大化分离。
Yandex 本身后来面临制裁——美国在 2022 年对部分 Yandex 子公司施加制裁，欧盟也跟进。但 ClickHouse Inc.（Delaware 美国公司）完全不受影响。它的法律实体已经“美国化”。
这是一个值得记住的范本。如果你是 2020 年俄罗斯科技公司的高管，你预见到俄罗斯被美国制裁加深的风险，你想保护一个具体的开源项目——ClickHouse 给出了一个清晰的策略：剥离 → 美国注册 → 关键人物迁出俄罗斯。这个策略在 2021 年看起来相对昂贵（涉及融资、移民、股权置换），但在 2022 年后被证明是必需的。
NGINX 和 ClickHouse 的故事告诉我们：当国家间冲突升级时，开源项目的法律实体位置成为决定性因素。
如果你的项目的法律实体在被制裁的国家，整个项目可能被切断。如果你的项目的法律实体在中立的国家（或者敌对方），你能继续运作。
但还有一种情况：项目根本没有强法律实体。这是 PostgreSQL 的情况。
PostgreSQL 是世界上最重要的关系数据库之一——估计在数百万部署。它的开发由 PostgreSQL Global Development Group (PGDG) 协调——一个非正式的协调机构，没有正式的法律注册。PGDG 包括来自 EnterpriseDB（美国）、Crunchy Data（美国）、2ndQuadrant（已被 EDB 收购）、Postgres Pro（俄罗斯）、NTT（日本）、富士通（日本）等公司的开发者10。
PostgreSQL 项目本身没有一个“母公司”。它没有 Linux Foundation 那种集中治理。它的决策通过 mailing list 共识达成。代码版权分散——每个 commit 由作者持有。
这种治理结构有一个有趣的副作用：它让 OFAC 等制裁工具难以适用。OFAC 没法“起诉 PostgreSQL”——因为 PostgreSQL 不是法人。OFAC 可以制裁 Postgres Pro（俄罗斯公司），但不能强制 PostgreSQL 项目本身切断与 Postgres Pro 的关系。
2022 年俄乌战争后，PostgreSQL 社区面对了一种独特的处境。Postgres Pro 是俄罗斯最大的 PostgreSQL 服务商，在莫斯科。它的公司材料在 2014 年和 2022 年都公开支持俄罗斯立场——“反对腐烂的西方产品”、“赞美原生俄罗斯 DBMS”。它给 Gazprom、State Treasury、Russian Ministry of Defense 等签合同11。
如果 PostgreSQL 像 Linux 那样有美国注册基金会，那么 2024 年大概率会进行类似的“删除俄籍 maintainer”事件。但 PostgreSQL 没有。所以发生的是社区压力，而不是法律驱动的清理。
2024 年 PGDay UK 在英国举办，邀请了 Postgres Pro 的演讲者。一位社区成员在 Change.org 发起请愿，要求取消邀请——理由是 Postgres Pro 与俄罗斯军方的合同关系12。请愿获得相当数量签名。最终演讲被取消。Postgres Pro 演讲者没有出现在会议上。
这不是法律驱动——这是社区压力。它的效果跟 Linux 删除 11 人有些相似（具体俄罗斯关联开发者被排除），但机制完全不同。Linux 是基金会强制；PostgreSQL 是社区自决。
Bruce Momjian——PostgreSQL Core Team 创始成员之一——在 2022 年 Percona Community 播客采访中谈过这种张力：
“We have a lot of contributors from Russia. Many of them have been with us for many, many years. Most of them, when this war started, were privately devastated. Some of them, we even know personally that they oppose the war. But they can’t say it publicly because they live in Russia.”13
Momjian 的态度反映了 PostgreSQL 社区的主流——区分公司与个人，区分立场与处境，避免一刀切。这种“软约束”在 2024 年没有发生像 Linux 那样的硬清理——但隐性边缘化仍然存在。俄籍 contributor 在 mailing list 上的影响力明显下降；部分新功能开发由非俄籍 committers 接手。
PostgreSQL 没有美国注册基金会的好处：它不受 OFAC 直接约束。但它的代价：它失去了 Linux Foundation 那种集中协调能力。当一个跨国冲突升级时，它能做的只是社区压力——慢、不一致、有争议。
PyTorch 走了完全相反的路径——从企业项目主动迁到基金会。
PyTorch 起源于 Facebook AI Research (FAIR) 2016 年的内部项目。它在 2017 年开源，迅速成为机器学习社区的主流深度学习框架——与 Google 的 TensorFlow 平分天下。到 2022 年，PyTorch 在学术界已经压倒性占优——绝大多数 AI 论文使用 PyTorch14。
但 PyTorch 仍然是 Meta 的项目。所有 PyTorch 核心开发者基本是 Meta 员工。PyTorch 的方向决定权在 Meta。PyTorch 的法律实体是 Meta。
2022 年 9 月 12 日，Meta 宣布把 PyTorch 转给 Linux Foundation——成立新的 PyTorch Foundation，由 Linux Foundation 旗下运作。创始成员包括 AMD、AWS、Google Cloud、Meta、Microsoft Azure、NVIDIA——基本是所有主要云厂商15。
Meta 在公告里给的理由是 “neutral home”——中立家园。PyTorch 已经太大了，不能继续被一家公司控制；它需要中立治理。Linux Foundation 是这种中立治理的标准框架16。
但 Meta 的转移决定有更深的逻辑。在 2022 年这个时刻：
读到这里要承认：这是我对 Meta 决策的合理推测，不是从内部材料证实的。Meta 公开的理由是“中立治理”。但时间点（2022 年 9 月，俄乌战争 7 个月后，美中 AI 竞争升级中）让“主权风险管理”这个解读相当 plausible。
Linux Foundation 接手 PyTorch 之后，治理变得更复杂。Linux Foundation 是美国 501(c)(6)——它必须遵守 OFAC。所以 PyTorch 仍然在美国法律框架下。但多家成员公司共同治理比单一公司决定有更多缓冲——如果美国想强制限制中国使用 PyTorch，必须穿过 Linux Foundation + 多家成员的集体决策17。
到 2026 年初，PyTorch 仍然是全球最重要的 AI 框架。中国 AI 公司——百度、阿里、字节跳动、DeepSeek——都在大规模使用。这种“全球性”在 PyTorch 还是 Meta 私有时较脆弱；现在 PyTorch 是 Linux Foundation 基金会项目，相对更有结构性保护。
Apache Software Foundation 是另一种地缘画像——它在某种意义上是“最国际化”的开源基金会，但它的核心法律实体仍然在美国。
Apache 1999 年成立。它在 Delaware 注册为 501(c)(3) 慈善机构。它的旗舰项目最初是 Apache HTTP Server，后来扩展到几百个项目——Hadoop、Kafka、Spark、Cassandra、Tomcat 等。多数这些项目跟全球大数据 + 云计算 + 企业 IT 紧密关联18。
到 2020 年代，Apache 的中国主导项目数量显著增加。几个突出的：
这种“中国项目在美国基金会下毕业”是个独特现象。它跟 OpenAtom 路径形成对比——同样是中国创建的开源项目，可以选 OpenAtom（中国基金会）或 Apache（美国基金会）。两种选择各有利弊：
到 2026 年，两种选择都在继续。一些中国公司选 Apache（追求国际化），一些选 OpenAtom（追求国内主导）。少数选两边都做（同一公司不同项目走不同路径）。
Apache 没有像 Linux Foundation 那样进行俄籍/中籍 maintainer 的合规清理。原因是：Apache 项目的中国/俄罗斯主导项目较少有与 SDN list 实体的强关联——例如 Doris、SeaTunnel 等的主要 contributors 多数是大学或非制裁公司的工程师。如果将来有强关联的中国/俄罗斯 contributor 进入核心 PMC，Apache 是否会跟 Linux 一样进行清理——这是个 open question。Apache 当然受 OFAC 约束（它是美国 501(c)(3)），但它至今没有触发 trigger 条件20。
Tor Project 是这个章节里政治讽刺最深的项目。
Tor（The Onion Router）是匿名通信工具——它通过多层加密 + 多跳路由让用户的网络流量难以被追踪。它被全球异见人士、记者、活动家、安全研究员广泛使用。它是 surveillance state 的天然对立面21。
但 Tor Project（管理 Tor 软件的非营利机构）的资助结构有一个让人不舒服的事实：美国政府是它最大的资助者。
具体数字：2023-2024 财年，Tor Project 总营收 $7.28 million。其中：
OTF 本身是美国国会拨款资助的项目——目标是“促进互联网自由”。它资助 Tor、Signal、Tails 等隐私技术。从美国政府的角度，资助 Tor 是为了让美国对外宣传“互联网自由”的工具能继续运作——尤其是用于绕开中国、伊朗、俄罗斯等国家的网络封锁。
讽刺的部分：这些被资助的工具最大用户群正在成为反美国监控的群体。Tor 被全球反 NSA 监控的活动家使用。它被记者用来保护源。它在 Snowden 之后的全球加密运动中是核心工具。美国政府一方面发起 PRISM 项目监控全球；另一方面又资助让人能逃避 PRISM 的工具23。
这种矛盾不是 bug——是 feature。美国国务院和 NSA 在不同部门有不同议程。国务院想推广“互联网自由”作为软实力工具；NSA 想做全球 SIGINT。这两个议程经常冲突，但都是美国国家利益的一部分。Tor 在两者之间。
Tor Project 自己长期试图减少对美国政府的依赖。它的目标是把美国政府资助比例降到 50% 以下（已经做到——35% 在 2023-2024）。它从各国基金会、个人捐款、其他政府（瑞典、德国等）获得越来越多资助24。但完全去美国化对 Tor 来说仍然是个长期任务。
Tor 的存在本身证明了开源运动的一个张力：一个旨在反对国家监控的项目，可能在结构上仍然受国家资助。这种张力没有简单解。Tor 拒绝美国资助就会衰弱；Tor 接受美国资助就有隐性影响力风险。它选择了“接受 + 透明 + 多元化”的策略——所有资助公开，努力多元化资助源。
RISC-V International 走了“中立避险”路线。
我们在第 1 章已经提过它 2019 年 11 月从 Delaware 迁到瑞士的决定。这里需要细看这个决定的具体含义。
RISC-V 是开放指令集架构（ISA）。它的设计目标是让任何人都能实现遵循 RISC-V 标准的 CPU——不需要付授权费给任何公司。这跟 ARM（英国公司，但有美国技术依赖）和 x86（Intel + AMD 双头垄断）形成对比25。
RISC-V Foundation 2015 年在 Delaware 成立。Delaware 注册是美国法律实体——这意味着它受美国出口管制约束。2019 年的时候这个状态变成问题：中国公司大规模采用 RISC-V（看到它作为绕开美国半导体管制的路径），美国国会有声音要求把 RISC-V 列入管制清单。
RISC-V Foundation 的董事会做了一个相对快速的决定：迁瑞士。2019 年 11 月，基金会改名 RISC-V International，重新注册为瑞士非营利26。
这个决定的逻辑：
但这个避险不是完美的。RISC-V Foundation 自己迁到瑞士，但它的成员公司（包括 Intel、Google、Western Digital 等美国公司）仍然受各自国家法律管辖。如果美国想要限制 RISC-V 在中国的使用，它可以通过限制美国成员的参与来达到效果——而不必直接管辖瑞士基金会。
这正是 2024 年开始发生的事。美国商务部对中国使用 RISC-V 展开调查（2024-04），一些美国国会议员提议限制美国公司在 RISC-V 工作组中与中国实体合作。如果这种立法通过，RISC-V Foundation 在瑞士的中立性会被部分穿透——通过限制美国成员的活动来达到管辖效果27。
把这些项目放在一起，能看到几种典型的“地缘画像”：
| 项目 | 法律实体 | 主要风险 | 应对策略 |
|---|---|---|---|
| Linux | 美国 LF | OFAC 穿透 | 接受合规清理 |
| NGINX | 美国 F5（前俄罗斯） | 俄罗斯司法穿透 | 主权迁移 |
| ClickHouse | 美国 Delaware（前俄罗斯 Yandex） | 同上 | 主权迁移 + 公开切割 |
| PostgreSQL | 无强法律实体（PGDG） | 社区压力 | 软约束、隐性边缘化 |
| PyTorch | 美国 LF（前 Meta） | 美国施压 Meta | 中立化到基金会 |
| Apache 项目 | 美国 ASF | 受 OFAC（未触发） | 等待 trigger |
| OpenAtom 项目 | 中国 OpenAtom | 中国合规 + 国际化弱 | 国内市场 |
| Astra Linux | 俄罗斯 RusBITech | 西方制裁 | 国内 + 国防 |
| Tor | 美国非营利 | 资助来源单一 | 多元化资助 |
| RISC-V | 瑞士非营利 | 美国成员被限制 | 中立避险 |
每个项目的位置决定了它的可达性、可用性、可贡献性。一个伊朗开发者可以贡献到 Apache 项目（暂时未触发 OFAC trigger），但不能贡献到 Linux maintainers 名单（被 OFAC 穿透）。一个中国开发者可以使用 PyTorch（暂时未限制），但可能在未来某天面对“中国 AI 公司不能使用 PyTorch”的要求。
这种“项目级别的地缘画像”在 2014 年之前不存在。当时开源项目主要按技术 stack 划分——web 服务器、数据库、操作系统等。今天它们额外按法律实体地理位置、暴露风险、主权策略划分。
读到这里有人可能会问：为什么有些项目主动迁移（ClickHouse、RISC-V），有些被迫迁移（NGINX），有些没法迁移（PostgreSQL）？
简单的回答是：取决于项目的资本结构和创建者意愿。
ClickHouse 有 Yandex 作为资源后盾——Yandex 能支持把核心团队迁到阿姆斯特丹、做股权重组、找美国 VC 投资。这是一次昂贵但可执行的操作。
NGINX 没有 Yandex 那种资源后盾——Sysoev 个人创业。但 F5 的收购给了它“被迁移”的路径。F5 付钱，问题解决——只是 Sysoev 个人失去了对项目的控制。
PostgreSQL 是真正去中心化的——没有单一实体能“决定迁移”。所有 contributor 都是独立的，分散在不同公司。没有人能代表 PostgreSQL 做迁移决定。
RISC-V 是个标准化组织——它的决定由董事会做，需要成员国共识。瑞士迁移是个集体决定，对所有成员都有利。
这给了开源治理一个新的维度：项目的治理结构决定它的主权应对能力。
读懂这个，能看到开源未来主权博弈的可能形态。如果你创立一个新的开源项目，你的治理选择不只是“技术决定”——它也是“主权暴露选择”。
最后回到 Igor Sysoev。
他是世界上让 web scale 的核心工程师之一。他写的 NGINX 让全球几亿网站能高效运行。他在莫斯科起家，1996-2018 期间用俄罗斯本土资源建立了一个全球性开源项目。但 2019 年之后，他在 F5 工作了几年，然后离开。他没有公开抱怨。但他个人不再是 NGINX 项目的领导者——这个项目从此由 F5（一家美国公司）管理。
Sysoev 现在在做什么——公开材料里没说。他不写 blog，不上 LinkedIn，不接受采访。一个被全球依赖的项目的创始人，从主舞台上消失。这件事的具体细节我们不知道；只能猜测——可能是他对项目美国化的态度，可能是他想做新项目，可能是各种私人原因。
但他这个角色的“消失”本身是个故事。
20 年前，开源运动的关键人物——Stallman、Linus、Behlendorf——都在主舞台上。他们参加大会，写博客，做演讲。他们公开自己的观点。开源是个有面孔的运动。
今天，多数关键 maintainer 不在主舞台上。Lasse Collin 不接受采访。Andres Freund 强调自己只是性能工程师。Daniel Stenberg 关掉 bug bounty 以保护心理健康。Igor Sysoev 从公众视野消失。这些人都是开源生态实际运转的人——但他们都在退到幕后。
为什么？因为主舞台变得不友好。当开源项目卷入国家间冲突时，公众角色变成负担。每一次公开发言可能被解读为政治站队。每一个 commit 可能被审视寻找隐藏含义。每一个 maintainer 可能被国家级行为者 target。
这是 2024 年后开源世界的一个少被注意的变化：它的核心人物在“去公众化”。他们仍然写代码，仍然维护项目，但他们越来越少出现在媒体、大会、公共讨论中。开源运动失去了它的“明星制”——剩下的是一群在幕后默默工作的工程师，承担越来越多的压力。
下一章我们要看的是这种压力如何被“标准化”——SBOM、SLSA、Sigstore、CRA、Reproducible Builds——这些试图让开源供应链可验证的工具和法律。它们试图把“可信任性”从个人转移到流程，但它们也制造了新的合规分裂。
F5 Networks press release 2019-03: F5 Acquires NGINX. Link →
HackMag: “The Origins of Nginx: Igor Sysoev on Building the Iconic High-Performance Web Server”. Link →
The Register 2019-12: 关于莫斯科 NGINX 办公室被搜查的报道。Rambler 起诉细节。Link →
Wikipedia: ClickHouse. 包括 Alexey Milovidov 2009 起源描述。Link →
Yandex press release 2021-09-20: “Yandex Spins Off ClickHouse into Standalone Company”. Link →
BigDATAwire: “Speedy Column-Store ClickHouse Spins Out from Yandex, Raises $50M”. Link →
ClickHouse blog 2022-03: “We Stand With Ukraine”. Link →
Percona Community Podcast 68: 关于 Postgres Pro 2014 和 2022 立场的描述。Link →
Change.org petition: “Request for the Removal of Postgres Professional from PGDAY UK 2024 - Poland”. Link →
Linux Foundation press 2022-09-12: “Meta Transitions PyTorch to the Linux Foundation”. Link →
Meta blog 2022-09: “Announcing the PyTorch Foundation”. Link →
PyTorch Foundation: The First Six Months（2023 年中报告）。Link →
多个 Apache TLP 公告：Apache SeaTunnel 2023-05、Apache DolphinScheduler 2021-04 等。SeaTunnel link → DolphinScheduler link →
Apache 治理与法律合规相关讨论。Apache 至 2026-05 没有进行类似 Linux 的 maintainer 清理。
Wikipedia: The Tor Project. Link →
Tor Project blog: “Transparency, Openness, and Our 2023-2024 Financials”. Link →
Wikipedia: Open Technology Fund. 美国国会拨款资助项目的历史。Link →
CyberInsider: “Tor Project received $2.5M from the US government to bolster privacy”. 包括 Tor 努力多元化资助的描述。Link →
The Register 2019-11-26: “RISC-V business: Tech foundation moving to Switzerland because of geopolitical concerns”. Link →
The Register 2024-04-24: “US government reportedly probes China’s use of RISC-V”. Link →
Center for Security and Emerging Technology (CSET): “RISC-V: What it is and Why it Matters”. Link →
EnterpriseDB: “Postgres Rising in Russia”. 关于 PostgreSQL 在俄罗斯的应用增长。Link →
Index Ventures: “The Fast and the Furious: How ClickHouse, the World’s Fastest Open Source Database”. 关于 ClickHouse 商业化的资本视角。Link →
1984 年 8 月，Ken Thompson 在他获得 Turing Award 时的演讲里，讲了一个让现场观众不舒服的故事1。
Thompson 是 Unix 共同发明者。他描述了一个理论上的攻击：他修改了 C
编译器，让它在编译 Unix 的 login
程序时，自动加入一个后门——一个只有他知道的密码可以让任何账户登入。然后他让这个被修改的编译器能识别自己——当它在编译
C 编译器源代码时，它会自动把那段“加 login 后门”的代码加回去。
效果：
Thompson 的核心论点是：你不能信任不是你自己从零写出来的代码。即使你看遍每一行源代码，如果你用的编译器有问题，你的程序也有问题。如果你的编译器是用另一个编译器编译的，那个编译器是用又另一个编译器编译的——信任链不可终结。
这篇演讲题目是 “Reflections on Trusting Trust”。它发表后立刻成为计算机安全经典，但很长一段时间被当作理论思考——一个聪明的智力游戏，但实际上没人这么做。
40 年后，xz Utils 后门发生。Lasse Collin 的源代码 repo 完全干净。问题是 release tarball——通过 m4 配置脚本注入的 build-time hook。打包后的二进制文件在用户机器上运行时执行后门，而源代码看起来无害。
这跟 Thompson 1984 年描述的攻击不完全一样——但信任链的脆弱性是同一种。即使你看遍 xz 源代码，你也发现不了后门——因为后门只在特定的 build 环境下被注入2。
xz 让 Thompson 演讲从理论问题变成具体威胁。开源运动 40 年依赖一个隐藏假设——“如果源代码公开，问题就能被发现”。Thompson 1984 年就告诉过我们这个假设有限度；2024 年 xz 让所有人面对这个限度。
要解决“Reflections on Trusting Trust”的问题，理论上需要几样东西：
这三个要素在 1984 年完全是理论。Thompson 当时没有提出怎么实现——他只是描述了问题。直到 2010 年代，开源社区才开始系统性应对。
Reproducible Builds 运动是最早的尝试。它的核心想法很简单：如果两个独立方用相同源代码 + 相同 build 配置，做出 bit-for-bit 一致的二进制，那么 build 没被污染。如果它们结果不同——某一方的 build 工具被污染了3。
实现这个目标需要消除 build 过程中的非确定性——时间戳、文件 ordering、临时路径、随机数等。Debian 项目从 2014 年开始系统性“reproducible-build 化”自己的所有包，到 2023 年已经实现 95%+ 的包可复现。NixOS、Bootstrappable、Guix 等“功能式 Linux 发行版”几乎 100% reproducible4。
但 Reproducible Builds 有个根本限制：它只能检测“工具污染”——如果 build 系统、编译器、链接器被污染，reproducible 检查能发现。它不能检测“源代码污染”——如果源代码本身是恶意的（像 xz），reproducible build 仍然会产生一致的恶意二进制。两个独立方 build 同一个 xz 5.6.0 源代码会得到 bit-for-bit 一致的——都是有后门的——二进制。
Reproducible Builds 解决了 Ken Thompson 的部分问题——能验证 build 工具不是被污染的。但它没解决 Lasse Collin 的全部问题——它不能告诉你这个源代码本身是否值得信任。
SBOM（Software Bill of Materials）是一个不同的角度。它的核心想法：给每个软件产品附一份“配料表”——说明这个产品由哪些 components 组成、每个 component 来自哪里、版本是什么。
SBOM 概念在 2017 年左右开始被推广，但真正起飞是 SolarWinds 2020 年事件之后。SolarWinds 让美国政府意识到：“如果我们不知道我们的关键软件依赖什么，我们就没法应对供应链攻击”5。
2021 年 5 月 12 日，Biden 政府发布 EO 14028——“Improving the Nation’s Cybersecurity”。这份行政命令的多个部分中，关于 SBOM 的部分（Section 10(j)）是核心6。EO 14028 要求：
NIST 在 2022 年发布 SBOM 相关指南。商务部 NTIA 也参与。可接受的 SBOM 标准格式有三种：SPDX（Linux Foundation 主导）、CycloneDX（OWASP 主导）、SWID tags（ISO 标准）7。
SBOM 的逻辑：你提交一份准确的 SBOM 给联邦机构。机构能审查你的依赖。如果某个依赖被发现有漏洞，机构知道自己受影响。
到 2024 年，SBOM 已经成为大型联邦软件采购的标准要求。多数大公司（Microsoft、Google、Oracle、IBM 等）都给自己产品生成 SBOM。OpenSSF 的工具（特别是 sigstore + slsa）让生成 SBOM 越来越自动化8。
但 EO 14028 在 2026 年初被 Trump 政府撤回部分要求9。具体说，OMB（管理与预算办公室）在 2026 年 1 月发布备忘录，把“必须提供 SBOM”改为“基于风险评估”。这是个软化——不再硬性要求 SBOM，而是让采购方决定哪些项目需要。但 SBOM 实践已经在行业内深度推广，行业不会因为 OMB 备忘录就反向回退。
SLSA（Supply-chain Levels for Software Artifacts）是 Google 2021 年提出，后转给 OpenSSF 维护的框架。它是一个 4 级成熟度阶梯10：
SLSA 的设计意图：让组织能选择自己需要的安全程度。一个小型开源工具可能只需要 SLSA 1；关键基础设施应该到 SLSA 4。
SLSA 已经被 GitHub Actions、GitLab CI、Google Cloud Build 等原生支持。开发者可以在 CI/CD pipeline 中自动生成 SLSA provenance attestation——一个 cryptographically signed 的文档说明“这个 artifact 是用这些源代码 + 这些工具 + 这些步骤 build 出来的”11。
Sigstore 是 SLSA 的 cryptographic 同伴。Sigstore 由 Google、Red Hat、Purdue University 在 2021 年合作启动，现在是 Linux Foundation 项目。它的核心创新：keyless signing——开发者不需要管理自己的 GPG 私钥，而是用 OIDC 短期证书（绑定到 Google、GitHub、Microsoft 等 identity provider）来签名 artifact12。
工具链：
Sigstore 解决了一个长期开源痛点——GPG 私钥管理。让每个开源 maintainer 安全持有 GPG 私钥几乎是不可能的——丢失、泄露、忘记密码都是常见问题。Sigstore 的“短期证书 + 透明日志”模式让签名变得对普通 maintainer 也可达13。
到 2024 年，多数主流开源项目已经在 release 时附加 SLSA provenance + Sigstore 签名。Linux 发行版（Debian、Ubuntu、Fedora）开始集成 Sigstore 验证到 package manager 中。这是过去三年开源供应链安全的最大进步。
但这些工具能阻止下一个 xz 吗？
答案是：部分能。
xz 攻击通过四个层面：
SLSA / Sigstore 主要在第 2 和第 4 层有效：
但 SLSA / Sigstore 不能阻止 第 1 层：如果 Jia Tan 已经是合法的 maintainer，他对源代码的提交本来就是合法的。第 3 层：如果攻击者通过其他渠道催促 distribution 采用新版本（如 Hans Jansen 提 Debian / Ubuntu bug），SLSA 不会自动阻止。
xz 攻击的关键创新是它绕开了所有现有 verifiability 机制——通过 maintainer 权限本身做攻击，而不是攻击 build 系统。SLSA 4 + Sigstore 能让攻击的“操作复杂度”提高（攻击者需要绕开双人审核），但不能从根本上排除攻击14。
这是 xz 给整个 supply chain 安全社区的一个严峻信息：verifiability 工具是必要的，但不充分。如果对手有耐心、有资源、能完成 social engineering，那么 verifiability 工具只能让攻击稍难，不能让攻击不可能。
让事情更复杂的是：verifiability 工具本身在被法律分裂。
美国 EO 14028 推动 SBOM。但具体 SBOM 格式有三种（SPDX、CycloneDX、SWID），它们语义略有不同——一个生成 SPDX 的工具不能直接生成 CycloneDX，反之亦然。
欧盟 CRA（Cyber Resilience Act）也要求 SBOM——但具体规范跟美国 EO 14028 不完全一致。CRA 定义了“open source steward”概念，专门给开源基金会一些责任：开源 steward 必须有 cybersecurity policy、必须做 vulnerability response、必须有 incident reporting15。
中国《网络安全法》和《关键信息基础设施安全保护条例》有自己的“安全可控”要求——一种另外的供应链验证方式。它要求关键基础设施用的软件必须通过可信渠道获得（这跟 SBOM 的“知道你用了什么”不完全相同——它要求“知道供应商可信”）16。
这就是 supply chain 工具的“三方监管夹击”。一个想全球分发的开源项目要 同时 满足：
三种规则没有完全冲突——但也不完全兼容。要做全部合规需要额外工作。这给了“只服务本国市场”的项目相对优势——它们只要满足一种规则。
整个事情有一个让人想停下来的细节。SBOM、SLSA、Sigstore 都是为“提高 supply chain 透明度”设计的。但它们的实际效果包括：让开源项目的国际化变难。一个跨国开源项目要同时遵守三个法域的规则，比“一国合规”困难。这造成了一种逆向的“主权化压力”——技术上你可以国际化，但合规上你被推向区域化17。
EU CRA（Cyber Resilience Act）是这一章最长的内容，因为它最复杂，对开源运动影响最深。
CRA 的全称是 Regulation (EU) 2024/2847。它在 2024 年 10 月通过，2024 年 12 月 10 日正式生效，部分条款 2026 年 9 月开始适用，全面适用 2027 年 12 月18。
CRA 的适用对象是“带数字元素的产品”（products with digital elements）。这包括几乎所有联网软件和硬件。CRA 定义了几个角色：
最后一个角色是 CRA 关于开源的核心争议点。
CRA 把 “open source steward” 定义为：
“a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products.”19
这个定义覆盖了 Eclipse Foundation、Linux Foundation、Apache Software Foundation 等大型开源基金会。它不覆盖：
Open source steward 的责任：
这相对个人开发者已经轻——但对开源基金会来说是真实负担。Eclipse、Apache、Linux Foundation 等都需要建立 incident response 团队、CVE 协调流程、定期 security audit。
CRA 推出过程中开源社区进行了激烈 push back。
2023 年 4 月，13 个开源组织（Eclipse Foundation、OSI、Document Foundation、Apache、Linux Foundation Europe 等）联合发表公开信，要求欧盟重新考虑 CRA 对开源的影响20。
公开信的核心担忧：
EFF（Electronic Frontier Foundation）也发表声明支持，担心 CRA 会损害开源运动21。
欧盟立法者听到了反弹。2024 年最终版本对纯开源 maintainer 做了豁免（“open source stewards” 责任不传递给个体 maintainer），并且给商业开发与非商业开发做了区分。Pure open source development without commercial intent 基本免于 CRA 大部分要求22。
但 Debian 等小型基金会仍然批评最终版本对中小再分发者不友好。OpenSSF 在 2025 年 6 月发了一份指南，专门帮助 OSS 项目判断自己是 “manufacturer” 还是 “steward” 还是纯个人 maintainer23。
到 2026 年初，CRA 的实际执行还在准备阶段——多数条款 2026 年 9 月才开始生效。但已经有项目宣布“不向欧盟用户提供”——以规避未来合规风险。这是 CRA 设计者没预见的副作用：他们想保护欧盟消费者，但部分小型开源项目宁可放弃欧盟市场也不愿合规24。
把美国 EO 14028、欧盟 CRA、中国《网络安全法》放在一起，能看到清晰的 pattern：
| 法域 | 主要要求 | 主要工具 | 对开源的处理 |
|---|---|---|---|
| 美国 | SBOM、安全开发 | SPDX、CycloneDX | 联邦采购通道 |
| 欧盟 | CE 标识、漏洞响应 | open source steward | Steward 责任 |
| 中国 | 安全可控、可信渠道 | 国家认证 | 国家可控接入 |
每个法域都不直接禁止开源——但每个法域都要求开源在某种合规框架下使用。这跟 2014 年之前的状态形成对比——那时候开源是“自由地、随意地、跨国地”使用的，没有任何政府要求合规25。
最让人头疼的是这三种合规要求不完全兼容。一个国际化的开源基金会要 同时 满足三种：
每种合规都需要专门人力。Eclipse、Apache、Linux Foundation 都已经在为此招聘“合规官”角色——这在 2014 年开源基金会几乎不存在。10 年前 Linux Foundation 的全职员工是工程师和市场，2024 年它有专门的法律 + 合规团队。
读到这里有人可能会问：为什么不让开源运动自己制定一个统一的合规框架？
答案：没有这个可能。
国家合规要求来自国家——它们反映国家利益。美国 EO 14028 反映美国的 supply chain 焦虑，欧盟 CRA 反映欧盟的消费者保护理念，中国“安全可控”反映中国的科技主权诉求。这些利益不是开源运动能“协调”的——它们是开源运动必须应对的外部约束。
开源运动能做的只是适应。具体形式包括：
每一种适应都有代价。大型基金会的合规成本会扩大——这意味着小项目相对更难毕业到大基金会。中间层的协调能力有限——它们能写指南，但不能强制各方接受。中立法域的选择本身需要资源——多数项目没有能力做这种主权迁移26。
到 2026 年，开源世界已经默认“分裂合规”是新常态。一个项目要全球化，它必须接受同时被多种法律约束的现实。这跟 2014 年之前“一个项目，一个全球”的状态完全不同。
Trojan Source 是另一个 verifiability 工具不能解决的问题。
2021 年 11 月，Cambridge 大学的 Nicholas Boucher 和 Ross Anderson 发表论文 “Trojan Source: Invisible Vulnerabilities”。他们描述了一种新的 supply chain 攻击向量：用 Unicode 双向（bidi）字符让源代码“看起来一样，但执行不一样”27。
Unicode 包括一些控制字符——用于支持阿拉伯语、希伯来语等右到左语言。这些字符在源代码中可以改变文本的渲染顺序，让 review 时看到的代码顺序和编译器解析的顺序不同。
具体例子：一段 Java 代码在 GitHub 上看起来是“如果用户是管理员，允许操作”，但编译器实际解析的是“如果用户不是管理员，允许操作”。差异通过 Unicode 控制字符引起，review 工具默认不显示这些字符28。
Trojan Source 影响几乎所有编程语言——C、C++、C#、JavaScript、Java、Rust、Go、Python 都受影响。Red Hat 在 2021 年 11 月发布安全公告 RHSB-2021-007 来应对29。
修复方式：编译器、IDE、code review 工具都加上对 Unicode 控制字符的警告或拒绝。但旧版本的工具不会自动升级，存在大量软件仍可能受影响。
Trojan Source 不是国家级 social engineering，但它代表了另一种“看似公开但隐藏意图”的 supply chain 攻击向量。它跟 xz 后门一起证明：verifiability 工具是个移动的目标。SBOM、SLSA、Sigstore 解决了一些验证问题，但新的攻击向量（如 Trojan Source、build-time hook、social engineering）会绕开这些工具30。
把这一章的所有东西放在一起，会看到一个让人有点沮丧的图景：
Verifiability 工具方面：
但 verifiability 工具不能解决的：
法律工具方面：
但法律工具引发的：
加起来，到 2026 年初，开源 supply chain 安全是个“做了大量工作但仍然脆弱”的状态。每次新的攻击（xz、Trojan Source）暴露新的弱点。每次新的法律（CRA、SBOM EO）增加新的合规成本。整个系统在变得更“成熟”——同时也在变得更“复杂”。
读懂这点能解释为什么很多关于“OSS 安全”的辩论让人感到无解。如果我们只看 verifiability 工具，事情在变好。如果我们只看法律框架，事情也在变好（按各方各自的标准）。但综合起来——既要工具又要合规又要避免国家间冲突的 supply chain 责任——状况是脆弱的、矛盾的、永远不够好的。
下一章我们要看的是这些 supply chain 压力催生的最直接副产品：平行 forge 生态。Gitee、Codeberg、GitFlic——这些非 GitHub 替代品的实际状况，以及“假如 GitHub 不可用”这个 thought experiment 在多大程度上能被现实测试。
Ken Thompson, “Reflections on Trusting Trust”, Communications of the ACM, August 1984. Text at aeb.win.tue.nl →
Research!rsc: “Running the ‘Reflections on Trusting Trust’ Compiler”. Russ Cox 实际复现 Thompson 攻击。Link →
Reproducible Builds project. [https://reproducible-builds.org/]
Debian Reproducible Builds project status reports. 2023 年达到 95%+ 覆盖率。
NIST: Executive Order 14028, Improving the Nation’s Cybersecurity (2021-05-12). Link →
NIST: Software Security in Supply Chains: SBOM. 列出 SPDX、CycloneDX、SWID 三种可接受格式。Link →
Anchore: “Executive Order 14028: Updates for SBOMs & FedRAMP”. Link →
Wiley: “OMB Rescinds Secure Software Development Mandate in Favor of a Risk-Based Approach” (2026). Link →
SLSA spec FAQ. Link →
SLSA Provenance specification. Link →
Sigstore project at Linux Foundation. 包括 Cosign、Fulcio、Rekor 工具描述。
AquilaX: “Software Supply Chain Security Beyond SBOMs: Sigstore, SLSA, and Build Provenance”. Link →
Wikipedia: Cyber Resilience Act. open source steward 角色描述。Link →
OpenSSF: “OSS and the CRA: am I a Manufacturer or a Steward?”. 详细描述合规分类问题。Link →
CRA Article 13(8) 定义 open source steward。Eclipse Foundation 的解读。Eclipse blog link →
TechCrunch 2023-04-18: “In letter to EU, open source bodies say Cyber Resilience Act could have ‘chilling effect’ on software development”. Link →
EFF 2023-05: “EU’s Proposed Cyber Resilience Act Raises Concerns for Open Source and Cybersecurity”. Link →
OSI: “The European regulators listened to the Open Source communities!”. Link →
Linux Foundation: “Understanding the Cyber Resilience Act: What Everyone involved in Open Source Development Should Know”. Link →
Open Regulatory Compliance Working Group (ORCWG). 试图协调 CRA 应对。Link →
Wikipedia: Trojan Source. Link →
Krebs on Security: “Trojan Source Bug Threatens the Security of All Code”. Link →
Red Hat: RHSB-2021-007 Trojan source attacks (CVE-2021-42574, CVE-2021-42694). Link →
The Record: “New Trojan Source attack impacts compilers for most programming languages”. Link →
BCLP Law: “The EU Cyber Resilience Act’s obligations: What does it mean for open source software?”. Link →
JFrog: “What is the SLSA Framework?”. Link →
2013 年 5 月，中国深圳一家叫“开源中国社区”（OSChina）的小公司发布了一个新产品——Gitee。它是一个仿 GitHub 的代码托管平台。当时中国开发者多数仍然用 GitHub；Gitee 是个相对小众的本土替代。
11 年后的 2024 年，Gitee 已经成为中国开发者生态的重要组成。它声称突破 1000 万开发者用户，托管多个国家级开源项目——包括 openEuler、OpenHarmony 的主仓1。
但 Gitee 跟 GitHub 之间的关系不是简单的“中国版 GitHub”。它的实际地位更复杂：
到 2026 年初，绝大多数中国开发者仍然把 GitHub 作为主要协作平台。Gitee 是补充，不是替代。但 Gitee 的存在本身改变了博弈——如果哪一天 GitHub 不可用，中国生态有一个不完美但可用的备援2。
Gitee 的具体功能跟 GitHub 大同小异：repo 托管、issue tracker、Pull Request、wiki、CI、organization 管理。但有几个关键差异：
审查机制：Gitee 比 GitHub 有更明显的内容审查。某些政治敏感内容会被自动隐藏或要求 take down。这种审查不是 Gitee 单独的事——它是中国 ICP 备案制度的延伸。任何中国注册的互联网平台都必须执行类似审查。
实名制：Gitee 要求中国大陆用户实名注册——身份证 + 手机号绑定。这跟 GitHub 完全匿名注册不同。实名制让“用户身份可追溯”成为默认。
国际化弱：Gitee 的 UI 主要是中文（虽然有英文版）。它的功能更新通常先服务中国市场，英文社区滞后。这造成了一种自我强化——非中文开发者很少用 Gitee，所以 Gitee 没有动力做强国际化。
法律合规：Gitee 作为中国公司，必须遵守中国法律——包括《网络安全法》、《数据安全法》、《个人信息保护法》。这跟 GitHub 受美国 OFAC 约束在结构上对称，但具体规则不同3。
读懂这些差异，能理解 Gitee 的真实定位：它是“在中国法律框架下运作的代码托管”——既不是“中国版 GitHub”，也不是 GitHub 的简单替代。它的用户基础是接受中国合规框架的开发者。
俄罗斯的 forge 故事不同。
俄罗斯没有像 Gitee 那样有规模的本土代码托管。它有几个项目：
GitFlic：俄罗斯本土 forge，2018 年起步。它的功能跟 GitHub 类似但规模小得多。2022 年俄乌战争后用户开始显著增长，但绝对数字仍然有限（估计在数十万级别）4。
自托管 GitLab：俄罗斯大企业大量使用自托管 GitLab。GitLab 公司本身（在美国）没有像 GitHub 那样对俄罗斯实体大规模封锁，主要原因是 GitLab 的开源版本可以被自托管——俄罗斯企业即使被 GitLab.com 封了也可以继续用自己服务器上的 GitLab 实例。
Yandex 内部：Yandex 维护自己的内部 git 基础设施。这跟 GitFlic / GitLab 不同——它不对外公开，只服务 Yandex 内部和合作伙伴。
俄罗斯的 forge 状况反映了俄罗斯科技生态的一个特点：它较为集中。少数几个大公司（Yandex、VK、Sber）主导，没有像中国那样的丰富中型科技公司生态。这让俄罗斯本土 forge 没法形成像 Gitee 那样的规模——因为活跃用户基础有限。
但 2022 年俄乌战争之后，俄罗斯政府推动“数字主权”政策。Decree 166 要求关键基础设施迁移到本土软件——这间接推动 GitFlic 等本土 forge 的应用5。到 2026 年，俄罗斯主要政府部门已经基本完成代码托管的本土化——不一定到 GitFlic，但至少不在被制裁可影响的境外平台。
欧洲 forge 生态走了完全不同的路径。
欧洲不像中国那样有“国家强制”驱动的本土 forge——欧盟没有“欧产 GitHub”政策。相反，欧洲的 forge 替代品多数是社区驱动的、强调数据主权与隐私的项目。
Codeberg 是这个生态的代表。Codeberg 是德国非营利组织 Codeberg e.V. 运营的代码托管服务。它基于开源的 Forgejo 软件运行6。
Codeberg 的定位：
到 2024 年，Codeberg 用户在 10 万级别——相对 GitHub 的数千万小很多，但增长稳定。它的用户多数是隐私敏感的欧洲开发者、不愿被 AI 训练的项目、需要 GDPR 合规的小型公司。
Forgejo 是 Codeberg 背后的软件——一个 Gitea 的 fork。Gitea 是 2016 年起源的开源 GitHub 替代软件。2022 年 10 月，Gitea 的商标和域名被转给一个新成立的营利公司 Gitea Limited，没有事先咨询社区。这个商业化决定让大部分 Gitea 贡献者不满。他们 fork 了项目，成立 Forgejo——回归社区治理7。
Forgejo 由 Codeberg e.V. 维护，强调“无商业实体”原则。这跟 Gitea Ltd 的“开源 + 商业”模式形成对比。
Radicle 是另一种欧洲尝试。Radicle 是 peer-to-peer 的、不需要中心服务器的代码协作平台。每个用户在自己机器上运行 Radicle，repo 复制到多个 peer。这是“完全去中心化”的极端尝试——没有任何公司或基金会能“关闭”Radicle8。
Radicle 的实际使用规模很小——多数开发者发现完全 P2P 模型对日常协作不实用。但它代表了一种思想：如果你不想被任何 forge 管辖，去中心化是出路。
把 Gitee、GitFlic、Codeberg、Radicle 放在一起，能看到几种不同的“主权策略”：
| Forge | 主权模式 | 治理 | 用户规模 |
|---|---|---|---|
| Gitee | 中国国家合规 | 商业公司（开源中国 + 华为/阿里影响） | ~1000 万 |
| GitFlic | 俄罗斯国家驱动 | 商业公司 | ~数十万 |
| Codeberg | 欧洲社区数据主权 | 非营利 e.V. | ~10 万 |
| Forgejo | 完全开源、社区驱动 | 非营利 | 自托管，规模未知 |
| Radicle | 完全去中心化 | 协议（不是公司） | 极小 |
每种策略对应不同的“威胁模型”：
读懂这点，能理解 forge 平行化不是“反 GitHub”——是针对不同威胁的不同应对。
GitHub 仍然是全球最大的代码托管——估计 1 亿+ 开发者注册9。它服务的“威胁模型”是“绝大多数开发者大部分时间在做正常工作”。这种威胁模型对全球协作是高效的。但对那些有特定主权风险的开发者，GitHub 不够。
中国镜像生态是 forge 平行化的另一种形式。
中国主要大学和云服务商维护着丰富的开源软件镜像：
这些镜像同步 GitHub、PyPI、npm、Docker Hub、Maven、Ubuntu、Debian、CentOS 等几乎所有主要开源生态。一个中国开发者可以从这些镜像下载几乎所有开源软件——不需要直接访问国际原始仓库。
这个镜像基础设施的意义：它是“假如 GitHub 不可访问”的备援。
实际中，多数中国开发者仍然能访问 GitHub（虽然有时候慢，需要 VPN 等）。但镜像基础设施意味着即使 GitHub 完全断开，已经发布的开源软件仍然可以在中国境内获得。这不解决“实时协作”问题（issue、PR、social 仍然在 GitHub 上），但解决“软件可用”问题。
俄罗斯也有类似但规模小得多的镜像基础设施。Yandex 维护一些镜像；Mail.ru 维护一些。但俄罗斯的镜像覆盖比中国窄——主要是 Linux 发行版和最常用的工具，不像中国镜像覆盖几乎所有 PyPI、npm 等11。
“假如 GitHub 不可用”——这个 thought experiment 在 2022 年俄罗斯被部分测试。
2022 年俄乌战争后，俄罗斯部分企业失去了 GitHub 访问。这不是 GitHub 完全断开俄罗斯——而是 GitHub 对部分被制裁的俄罗斯实体封锁。具体说：
这种“部分断开”已经造成了显著的迁移：
但完整的“GitHub 不可用”仍然没有被测试。即使 2022 年俄乌战争后，GitHub 也没有对整个俄罗斯封锁——只针对被制裁实体。整个俄罗斯生态仍然能用 GitHub 做大部分工作。
如果哪一天 GitHub 对整个俄罗斯断开——比如美国制裁升级到“地区级”——会发生什么？
俄罗斯的回应大概率是：
技术上是可行的——但社交层面会损失。issue tracker 上的讨论历史、PR 上的 review 记录、组织页面、profile 关系——这些不容易被简单“镜像”。一个项目从 GitHub 切到 GitFlic，技术资产可以迁移，但社交资产部分丢失。
中国的“预演”更系统。
中国主要科技公司在 2018-2024 年间做了大量“假设 GitHub 不可用”的备援工作：
这种备援不是“反美”——是常规风险管理。任何主要中国科技公司都需要回答：“如果哪天 GitHub 不可用，我们能继续工作多久？”——答案应该是“至少几个月，可能几年”，而不是“立即崩溃”。
到 2026 年，中国科技公司的实际答案大致是：
这种“技术上可行但协作受损”的状态是 forge 平行化的真实代价。它不是“中国会失去开源”——是“中国会失去开源的全球性”。这是个微妙但重要的差异。
读到这里，一个自然的问题是：真的有“假设 GitHub 不可用”的可能吗？
短期内（1-2 年）：不太可能。GitHub 作为 Microsoft 的关键资产，整体关停某个大国会引起巨大商业损失。Microsoft 不会主动做这种决定，除非被美国政府强制。
中期（3-5 年）：可能性增加。如果美中关系恶化到某种临界点，美国政府可能强制 Microsoft 对中国关停 GitHub。具体触发条件难以预测，但理论可能性存在。
长期（5-10 年）：不可避免地需要考虑。即使 GitHub 不被关停，它的“美国合规约束”会越来越紧。最近的趋势——从国家级（2019 伊朗）到实体级（2022 俄罗斯）到 maintainer 级（2024 Linux 11 人）——是不断精细化。继续这个轨迹，下一步可能是“某些类型的中国 contributor 不能 maintain 某些项目”14。
每个国家都在为“长期可能”做准备——中国 OpenAtom、欧洲 STF、俄罗斯 Decree 166。这些不是为了“明天 GitHub 关停”，是为了“长期保持选择权”。
如果一个国家完全依赖 GitHub，它在跟美国的任何谈判中都有一个隐藏的脆弱性。如果一个国家有 viable 备援，它的谈判位置更稳。这就是平行 forge 生态的真正意义——不是替代，是保险。
最后看一个具体场景。
假设你是一个 2026 年的开源 maintainer。你的项目托管在 GitHub。你的 contributor 来自全球——美国、欧洲、中国、俄罗斯、印度、伊朗、巴西。你想保护项目的全球协作能力——避免在某个地缘事件中被穿透。
你的选择：
1. 保持 GitHub 主仓 + 多镜像
2. 迁到中立基金会
3. 完全去中心化
4. 接受单一 forge 的风险
到 2026 年，绝大多数项目仍然选 4 或 1——接受 GitHub 主仓的风险，最多加个镜像。选 2 的项目主要是大型企业项目。选 3 的极少15。
这反映了开源生态的现状：虽然有 forge 平行化的备援，但全球协作密度仍然集中在 GitHub。这是因为 GitHub 的网络效应——它有最多的开发者、最完整的工具链、最成熟的 CI 集成。任何替代都要付出“远离主流”的代价。
但 forge 平行化的存在本身改变了博弈。它给了开源运动一个“如果一切糟糕，我们至少有备援”的位置。这种位置——即使从未真正切换——也影响开发者、政府、监管者的行为。GitHub 知道有替代品，所以不会任意制裁；政府知道开发者有替代，所以制裁威力有限；维护者知道有备援，所以面对压力时有更多 leverage。
CHAOSS 是另一个值得提的项目。
CHAOSS（Community Health Analytics for Open Source Software）是 Linux Foundation 旗下的项目，2017 年成立。它的目标是开发开源社区健康度量——能客观衡量一个开源项目的活跃度、多样性、可持续性16。
CHAOSS 的具体指标包括：
这些指标本身不直接关系到地缘政治。但 CHAOSS 让一件事变得可能：追踪开源项目的“contributor 地理分布”如何变化。
如果哪一天 Linux 内核失去所有俄籍 contributor——不只是 11 个被删除的 maintainer，而是所有 .ru contributor 都因压力撤离——CHAOSS 能定量呈现这个变化。如果 PyTorch 在 2027 年突然中国 contributor 比例下降 50%，CHAOSS 能追踪到。
这种“contributor 地理分布”在 2014 年之前几乎没人关注——开源运动的姿态是“代码无国界”，所以贡献者来自哪里不是重要数据。2024 年之后这个数据变得至关重要——它能客观呈现“主权穿透”的实际效果17。
OpenSauced 和 Sourcegraph 是另外两个做类似工作的项目。它们提供更细粒度的 contributor 追踪和分析。Sourcegraph 2023 年发布的 “State of Open Source” 报告就显示，中国 contributor 数量在 2018-2023 年增长 47%——这是开源运动地缘格局变化的具体数据点18。
最后回到 Gitee。
Gitee 在 2024-2026 年继续增长——它声称用户突破 1000 万，托管的项目越来越多。但它也有挑战：
这些限制不阻止 Gitee 在中国生态的功能性——它仍然是 openEuler 这种关键项目的主仓。但它们限制 Gitee 成为“全球性 GitHub 替代”。它的实际角色是“中国生态的中心 + 全球生态的补充”19。
读懂这个，能理解 forge 平行化的真实形态：它不是建立“中国的全球开源平台”，是建立“中国生态的本土备援”。同样的逻辑适用于俄罗斯 GitFlic、欧洲 Codeberg——它们都是各自生态的本土备援，不是替代 GitHub 的全球野心。
这种“区域化备援”的格局，可能就是开源未来 10-20 年的实际状态。不是统一的全球生态，也不是完全断裂的多个生态——是一个由 GitHub 主导但有多个区域备援的格局。每个区域有自己的合规框架、用户基础、维护激励。GitHub 仍然是全球协作的中心，但越来越多的“主权敏感”工作通过区域 forge 完成。
下一章我们要看的是开源最新的一层——AI 模型权重。它带来了一个全新维度：不是源代码、不是 forge、不是 maintainer——而是数十亿个数字。这层的国家化已经开始，而它的逻辑跟传统开源很不一样。
Refine: GitHub Alternatives Worth Trying in 2026. 包括 Forgejo 从 Gitea fork 的描述。Link →
中国主要镜像站：USTC mirror (mirrors.ustc.edu.cn)、Tsinghua mirror (mirrors.tuna.tsinghua.edu.cn)、阿里云镜像 (mirrors.aliyun.com)、华为云镜像 (mirrors.huaweicloud.com) 等。
CHAOSS Community Health Analytics for Open Source Software project. Link →
多份 contributor geographic distribution 研究：Sourcegraph、OpenSauced、CHAOSS 等。
Sourcegraph 2023 “State of Open Source” 报告。中国 contributor 增长 47% 数据。
European GitHub Alternatives: Code Hosting with Privacy, Control, and Data Sovereignty. Link →
HowToGeek: “These 4 GitHub alternatives are just as good—or better”. 综合 GitHub 替代品评估。
Best Open Source GitHub Alternatives 2026 — OSSAlt Guides. Link →
2025 年 1 月 20 日，DeepSeek 公司发布了 R1 模型。它在多个推理 benchmark 上达到或超过 OpenAI 的 o1。R1 是在 DeepSeek-V3 基础上用强化学习做后训练得到的——而 V3 的预训练计算成本被报道为约 560 万美元（约 280 万 GPU 小时的 H800 算力），比 OpenAI 同级别模型低一个数量级。最关键的：DeepSeek R1 完全开源，用 MIT License 发布1。
接下来 72 小时是 AI 行业的一次小地震。Nvidia 股价单日下跌 17%，市值蒸发约 5900 亿美元。原因是 DeepSeek 用旧的 Nvidia H800 GPU——已经被美国出口管制限制了——做出了前沿水平的模型。这个事实“破坏”了美国“通过芯片出口管制阻止中国 AI 进展”的基础假设2。
DeepSeek R1 的故事不只是技术——它是开源运动新一章的开端。它代表了一个 Stallman 1985 年没法想象的现象：一个国家用开源策略反制另一个国家的出口管制。
要看清楚这件事，需要倒回去看 AI 开源是怎么变成“主权问题”的。
AI 模型的“开源”在 2010 年代后期还是个简单概念。早期项目像 Theano、Caffe、TensorFlow（Google 2015）、PyTorch（Facebook 2016）都是“开源框架”——你下载框架代码，自己训练模型。模型权重是你自己训练得来的产物，是你自己的财产。
但模型大小很快变得超出个人能力。2018 GPT-2 是 1.5B 参数；2019 GPT-3 是 175B 参数；2024 GPT-4 据传超过 1T 参数。训练这样的模型需要数千个 GPU + 几个月时间 + 数千万美元。普通开发者不可能自己训3。
所以“开源 AI”变成两种东西：
开权重（open weights）：你公开已训练好的模型权重。任何人可以下载、使用、修改、再训练。代表项目：Meta Llama、Mistral、Alibaba Qwen、DeepSeek、智源 BGE、Stability Diffusion。
闭权重（closed weights）：你只通过 API 提供模型——用户能用，但不能下载权重。代表项目：OpenAI GPT、Anthropic Claude、Google Gemini Pro。
这个分裂在 2023 年成为 AI 政治的关键问题。
开权重派的论点：
闭权重派的论点：
2023 年 7 月 18 日，Meta 发布 Llama 2。这是第一个被广泛使用、性能接近前沿的开权重模型。Llama 2 的 license 不完全是开源（它有“超过 7 亿月活用户的公司不能商用”等限制），但权重是公开的——任何人可下载5。
Llama 2 立即被全球 AI 社区采用。它成为微调（fine-tuning）研究的标准基准；它被部署到无数应用；它衍生出几百个 variant（Vicuna、Alpaca、Llama-2-Chat 等）。
Meta 做这个决定的逻辑：开源能让 Llama 成为生态主导。OpenAI 闭权重让它的模型只能被 OpenAI 服务；Llama 开权重让它能进入每个开发者的工具链。如果 Meta 想在 AI 长期竞争中获得位置——但 ChatGPT 已经主导消费市场——开源是一个不对称竞争策略。
2024 年 4 月 Llama 3 发布。性能进一步接近 GPT-4。2025 年 4 月 Llama 4 发布——其中的 Behemoth 变种用 2T 参数 + Mixture of Experts 架构6。
但到 2025 年下半年，开权重领域的主导权从美国（Meta、Mistral）转移到了中国。
Qwen（阿里达摩院）2024 年的版本已经在多个 benchmark 上接近 Llama 同代。2025 年 4 月 Qwen 3 与 Llama 4 同时发布。Qwen 3 在数学（AIME25 92.3%）和代码（HumanEval 88.5%）上超过 Llama 47。
DeepSeek 2024 年 12 月发布 V3——一个开权重的前沿性能模型。2025 年 1 月 R1 发布，在推理任务上达到或超过 OpenAI o1。
Yi（零一万物）、智源 BGE、智谱 GLM、月之暗面 Kimi——多个中国 AI 实验室加入开权重赛道。
到 2025 年 9 月，Qwen 在全球累计下载量超过 Llama。到 2025 年中，总开权重模型下载量从美国主导切换到中国主导8。
这是 AI 历史上一个少被注意但意义重大的转折。开权重领域不再是“美国主导，其他追随”——是中国主导，其他模仿。Llama 仍然有大量用户，但全球开权重格局的中心已经东移。
中国 AI 实验室为什么如此积极开源？答案有几层。
第一层是商业。在闭权重领域，OpenAI / Anthropic / Google 已经先发优势——它们有 ChatGPT、Claude、Gemini 等成熟产品。中国公司要做闭权重产品很难超越。开权重是一个不对称竞争——通过开放生态让全球开发者使用中国模型，最终建立生态主导。
第二层是规模。中国 AI 实验室普遍受美国芯片出口管制约束——它们不能像 OpenAI 那样用最新 H100、H200 GPU。但 DeepSeek 等用工程优化（FP8 训练、MoE 架构、专家路由）在旧硬件上达到接近前沿的性能。开源让这种技术创新被全球验证、扩散、反馈——这给了中国实验室的“工程优化”路径一个 multiplier9。
第三层是政治。如果 OpenAI 通过 API 控制全球 AI 访问，中国未来在 AI 主导权上是被动的。如果中国开源的 Qwen / DeepSeek 成为全球开发者的工具，那么不论政治如何变化，全球 AI 生态都不能脱离中国创新。开源是一种长期影响力建设。
第四层是务实。中国当前还没有像 OpenAI 那种全球消费品（ChatGPT 在中国境外占主导）。开源让中国模型被全球研究者引用、研究、改进——这建立学术影响力。学术影响力 → 长期人才吸引 → 长期生态主导。
这四层逻辑加起来，让中国在开权重领域的投入超过任何其他国家。到 2026 年，全球开源 AI 生态的核心节点——Hugging Face 上下载量最大的模型——绝大多数是中国实验室出品10。
但开权重的政治化也很快。
2024 年 2 月，美国 BIS（Bureau of Industry and Security）发布提案，要求对“双用 AI 模型权重”出口管制。具体的 framework 在 2025 年 1 月发布——叫《Framework for Artificial Intelligence Diffusion》11。
这个 framework 的核心：
为什么开权重不管制？因为 BIS 承认：一旦发布的开放权重模型不能召回。任何人都已经下载了 Llama、Qwen、DeepSeek；任何后续管制只对未来未发布的模型有效。
但 BIS 通过另一条路径管制开权重的使用。
2025 年 2 月，参议员 Bill Cassidy（路易斯安那共和党）和 Jacky Rosen（内华达民主党）提案：禁止联邦承包商在与联邦合同相关的活动中使用 DeepSeek 或其后续模型13。
2025 年 4 月，众议院“对中国共产党战略竞争特别委员会”发布关于 DeepSeek 的报告，建议更新 FAR（Federal Acquisition Regulations）禁止联邦政府采购基于中国 AI 模型的系统14。
2025 年 12 月，美国政府正式更新 AI 采购规则。联邦承包商被禁止使用中国 AI 模型——Qwen 和 DeepSeek 都在禁止列表15。
注意这个管制的形式：它不是禁止 DeepSeek 被下载（任何人仍然可以从 Hugging Face 下载）。它是禁止“在联邦合同中使用”。这跟我们在第 2 章讨论的 Bernstein 案保护“出版自由”但不保护“使用自由”的不对称完全对应。
中国对开权重的政策反应不同。
中国《生成式人工智能服务管理暂行办法》2023 年 7 月由网信办发布16。它的核心：
实际效果：
这造成了一个奇怪的状况：中国 AI 模型在全球开放权重（任何人能下载），但在中国境内的服务化（提供 chatbot 服务）受严格监管。一个 DeepSeek 模型可以被美国开发者下载、修改、商用——但在中国境内必须经过备案才能向用户提供服务。
这种“全球开放 + 本土受控”的模式是中国 AI 政策的一个独特设计。它最大化中国 AI 的全球影响力（开权重不受国内监管限制），同时保留对国内 AI 服务的国家控制。
Hugging Face 在这个新格局中扮演关键角色。
Hugging Face 是美国 Delaware 公司，2016 年成立，最初是个聊天机器人公司。2019 年它转向 AI 模型的开源 hub。到 2025 年它托管几百万个模型、数据集、demo——成为事实上的“AI 模型 GitHub”17。
Hugging Face 的关键特点：
这创造了一个有趣的悖论。最大的中国 AI 模型分发渠道是一家美国公司。
Hugging Face 怎么应对这个悖论？它的实际操作：
到 2026 年初，Hugging Face 仍然是全球 AI 模型分发的中心。中国实验室主动选择把模型上传到 Hugging Face（虽然中国有 ModelScope 等本土平台）——因为 Hugging Face 提供最大的国际可见性18。
但 Hugging Face 也面对越来越多的合规压力。美国国会有声音要求 Hugging Face 限制托管中国模型；中国监管要求 Hugging Face 不能托管违反中国内容规定的模型。这两种压力让 Hugging Face 在中美之间走钢丝。
如果 Hugging Face 受 OFAC 压力增加，会发生什么？
理论上的演化路径：
Step 1（已发生）：Hugging Face 限制部分高敏感账号——OpenAI、Anthropic 等“前沿闭权重”实验室自然不托管在 Hugging Face；OFAC SDN list 上的实体被限制 upload。
Step 2（可能 2026-2027）：Hugging Face 对某些“前沿开权重”模型加合规审查。如果某个模型被认为可能用于军事/双用途，Hugging Face 可能拒绝托管。
Step 3（可能 2027-2030）：Hugging Face 被迫拆分——美国部分和“国际部分”分立法律实体。中国实验室转向 ModelScope 等本土平台。“AI 模型 GitHub” 分裂为多个区域生态。
Step 4（远期）：每个区域 AI 生态有自己的模型 hub、自己的合规框架、自己的“主导模型”。全球 AI 协作变得复杂——一个中国实验室的模型可能在美国不能商用，反之亦然19。
读到这里要承认：这是合理推测，不是预言。Hugging Face 的未来可能完全不同。但合规压力的轨迹（2014 → 2019 → 2022 → 2024 → 2025）暗示 AI 模型分发的领域很可能跟随类似的精细化主权穿透。
中国模型托管平台是这种平行化的具体体现。
ModelScope（魔搭社区）由阿里达摩院 2022 年发布。它是中国版的 Hugging Face——托管模型、数据集、demo20。到 2026 年 ModelScope 托管的模型主要服务中国市场，国际可见性有限。
HF Mirror（多个第三方）：在中国镜像 Hugging Face 的尝试。规模有限——主要是为了让中国开发者更快下载 Hugging Face 上的模型。
百度 Wenxin Workshop：百度自己的模型生态。
智源 BGE / Tsinghua KEG / OpenBMB：学术机构主导的模型 hub。
这些平台的存在不是“反 Hugging Face”——是中国 AI 生态的本土备援。如果 Hugging Face 哪天对中国用户不可用，这些备援能保证中国 AI 工作继续。但它们目前的实际规模远小于 Hugging Face——多数中国 AI 研究者仍然主要用 Hugging Face21。
训练数据的国籍化是这个故事的另一层。
AI 模型训练需要大量数据。多数前沿模型用 CommonCrawl 等公开数据集——这是个非营利项目，自 2008 年起爬取整个 web 的快照22。
但 CommonCrawl 有几个特点：
这造成了一个“AI 训练数据的地缘特征”：用 CommonCrawl 训练的模型在英文任务上很强，在中文等小语种任务上较弱。中国 AI 实验室如果要做中文优秀的模型，必须额外爬取中国 web、收集中文语料23。
阿里、百度、字节、智源等都积累了自己的中文训练数据。这些数据不公开——它们是中国 AI 公司的护城河。一个外国实验室想做同等优秀的中文模型很难，因为他们没法访问这些专属语料。
类似的故事在其他语言领域上演：
到 2026 年，AI 训练数据已经在按语言/地区分化。多语言模型仍然由 CommonCrawl 主导，但单语言旗舰模型几乎都有专属语料。这是 AI “本土化”的具体技术基础24。
读到这里有人可能会问：AI 模型权重和源代码到底是不是同一种东西？
这个问题在第 2 章我们已经讨论过。简单回顾：
但模型权重也有源代码的某些属性：
到 2026 年，法律层面对这个问题没有清晰回答。Bernstein 案确立了“源代码是言论”——但这个判决是否延伸到模型权重，没有美国法院明确回答。BIS 的实际行动倾向于把模型权重当作“工具”而非“言论”——可以受出口管制覆盖。
这种法律不确定性是 AI 时代的一个核心问题。如果模型权重是言论，那么所有开权重模型受第一修正案保护——美国政府不能限制它们的发布或使用。如果模型权重是工具，那么它们可以被广泛管制——出口、使用、训练都能受限。
这两种判决的差异巨大。一个判决会决定全球 AI 发展的政治可能性25。
DeepSeek R1 之后一年的发展轨迹值得记住。
2025 年 1 月 R1 发布——震惊全球 AI 业。 2025 年 2 月：参议员提案禁止联邦承包商使用 DeepSeek。 2025 年 4 月：众议院特别委员会建议更新 FAR。 2025 年 5 月：美国一些州也开始限制政府机构使用 DeepSeek。 2025 年 8 月：DeepSeek V3.1 发布——继续保持开权重，性能进一步提升。 2025 年 9 月：Qwen 累计下载量超过 Llama，全球开权重领导权从美国转移到中国。 2025 年 12 月：美国正式更新 AI 采购规则——联邦承包商不能用中国 AI 模型。
到 2026 年，开权重领域已经形成新的格局：
这是 AI 史上一个少被预见的发展。2022-2023 年绝大多数 AI 预测都假设美国会主导生成式 AI。OpenAI、Google、Microsoft 的领先地位看起来不可动摇。但开权重路线的兴起——特别是中国实验室在开权重领域的领先——把这个预测推翻了。
DeepSeek 的故事让人想起 PRISM 系列里的另一个故事：2013 年 Snowden 揭露 NSA 监控之后，全球各国意识到他们需要建立“不依赖美国”的通信基础设施。十年后，2024 年的 AI 故事是类似的：各国意识到他们需要建立“不依赖美国”的 AI 基础设施。但应对的方式不同——这次主要工具是开源。
通过开源 AI 模型，各国（尤其是中国）能够：
这是开源运动新一章的核心矛盾。Stallman 1985 年写 GNU 宣言时想象的开源是“反企业、反专有”。2025 年的中国开源 AI 战略是“反美国出口管制、利用开放性建立国家影响力”。两种“开源”的形式相似但动机完全不同。
最后回到 DeepSeek R1 发布那一刻。
那个 1 月晚上，Hugging Face 上的 R1 model page 在几小时内被下载几百万次。Nvidia 股价开始下跌。Twitter / X 上一片喧嚣。OpenAI 的工程师们半夜被叫起来分析 R1 的训练细节。美国国会议员的助手们紧急起草关于 DeepSeek 的备忘录。Anthropic 的 Dario Amodei 公开承认 R1 让 Anthropic 重新思考自己的策略。
这个时刻就是 AI 开源进入国家化的标志。
在 R1 之前，“开源 AI” 还是个相对学术 / 技术圈的话题。多数政策制定者把 AI 主要理解为 OpenAI / Anthropic 那种闭权重商业产品。R1 让所有人意识到：开权重不只是“小项目玩具”——它能达到前沿水平，能挑战闭权重生态，能成为国家战略工具。
R1 之后的一年，关于“开源 AI 的政策”的讨论从专业领域扩展到国会、白宫、欧盟、北京。每个主要国家都在反思自己的 AI 开源策略。
到 2026 年 5 月，这种反思还在进行。没有一个国家给出了完整答案。但有几件事变得清楚：
下一章——也是最后一章——我们把所有这些放在一起，问一个最直接的问题：开源到底变成了什么？
MIT Technology Review 2025-01-24: “How Chinese company DeepSeek released a top AI reasoning model despite US sanctions”. Link →
Qwen 3 性能数据。AIME25 92.3%、HumanEval 88.5%。CodeSOTA Open LLM Leaderboard →
MIT Technology Review 2026-02-12: “What’s next for Chinese open-source AI”（Caiwei Chen）。文中指出 Qwen 在 Hugging Face 累计下载量超过 Llama，且到 2025-08-04 由 Qwen 衍生的新模型已占 Hugging Face 新增语言模型衍生体的 40% 以上，Llama 降至约 15%。Link →
Brookings: “DeepSeek shows the limits of US export controls on AI chips”. 关于工程优化策略的分析。Link →
Federal Register 2025-01-15: “Framework for Artificial Intelligence Diffusion”. Link →
Sidley: “New U.S. Export Controls on Advanced Computing Items and Artificial Intelligence Model Weights” (2025-01). Link →
CyberScoop: “Senators move to quash the use of Chinese AI system by federal contractors”. Link →
Mintz 2025-04-24: “House Select Committee Publishes Report on DeepSeek”. Link →
Inside Government Contracts 2025-02: “U.S. Federal and State Governments Moving Quickly to Restrict Use of DeepSeek”. Link →
IISS: “DeepSeek’s release of an open-weight frontier AI model”. 关于全球 AI 生态分裂可能的分析。Link →
BHASHINI 项目页面。Bhashini Challenge - Innovate India。Link →
Federal Register 2024-02-26: 关于 AI 模型权重法律性质的官方探讨。Link →
EU Institute for Security Studies: “Challenging US dominance: China’s DeepSeek model and the pluralisation of AI development”. Link →
Red Hat Developer: “The state of open source AI models in 2025”. 综合分析。Link →
Open Source LLM Comparison Table (2026). Link →
Vahu: “Selecting Open-Source LLMs: Llama, Mistral, Qwen, and DeepSeek Compared”. Link →
Washington Post 2025-02-03: “Sens. Warren and Hawley call for tougher chip export bans to stymie Chinese AI”. Link →
从开始到这一章，我们走了一段长路。1985 年 Richard Stallman 写《GNU 宣言》，41 年后 Greg Kroah-Hartman 用两句话删除 11 名俄籍 maintainer。1991 年 Phil Zimmermann 通过印一本书规避 ITAR，34 年后 DeepSeek 用 MIT License 发布前沿 AI 模型。1997 年 Eric Raymond 写“Given enough eyeballs, all bugs are shallow”，27 年后 xz 后门用三年时间证明国家级 social engineering 让眼睛不够用。
读到这里如果你感到沮丧，那不奇怪。这本书的几乎每一章都讲了一种“开源被穿透”的形式——制裁穿透 maintainer 名单，国家穿透基金会治理，合规穿透协作流程，AI 模型权重穿透传统的代码即言论原则。每一种穿透都是真实的，每一种都没有简单的回应。
如果你觉得整本书是关于“开源运动的失败”，那是误读。这本书想说的不是失败——是转变。
开源没有失败。在你读这一行字时，全球几百万个开源 maintainer 正在维护几亿个项目。Linux 仍然在运行；Apache 仍然在 host 网站；PostgreSQL 仍然在存数据；PyTorch 仍然在训练模型；curl 仍然在做 HTTP 请求。开源是地球上仍在运行的最大规模、最持续的志愿合作产物之一。
但它已经不是 1985 年的开源，不是 2001 年的开源，不是 2014 年的开源。它的形态变了——它从“全球公地”变成“被多个主权切割但仍然运转的多边生态”。理解这种变化，是理解 21 世纪 20 年代技术世界的一个关键。
回看四十年的轨迹，能识别出三个阶段：
自由阶段（1985-2000）：
企业阶段（2001-2014）：
主权阶段（2014-?）：
每个阶段没有终结上一个阶段。Stallman 的道德立场仍然在 FSF 工作；Apache 基金会的“企业可用”模式仍然有效；2014 年之后的“主权穿透”也没有替代之前的两层——它叠加在上面，让事情更复杂。
到 2026 年，一个开源项目同时面对：
这三层经常冲突。一个 maintainer 可能信仰“代码无国界”（自由立场），但他在为一家美国公司工作（企业立场），他的项目必须遵守 OFAC（主权立场）。这三层让简单的“开源运动应该怎么做”问题变得几乎不可回答。
但读到这里需要停下来纠正一个可能的误读：主权阶段不是开源的衰落。
这是一个常见的悲观叙事——“开源被国家捕获，理想已死”。这个叙事错在两个地方。
第一，它把“理想”当作“事实”。开源运动的“全球公地”姿态从来不是事实——它是 1985 年以来的 aspiration。即使在 1990 年代，开源软件的实际使用就充满了不平等——美国与欧洲开发者占绝对多数，非英语母语开发者贡献门槛更高，南半球国家几乎不参与核心治理。“全球公地”是个有效的 framing 来推动开放——但它从未是一个准确描述。
第二，它低估了开源的根本属性。开源的核心不是“全球协作”——是“代码可读、可分叉、可镜像”。前者是文化层面的实践，可以被国家穿透。后者是技术层面的属性，国家无法改变。
让我们具体看后者。如果 Linux Foundation 删除 11 名俄籍 maintainer，俄籍开发者仍然可以：
他们失去的是“参与 Linus 主仓的 maintainer 角色”——这是协作机制，不是技术属性。他们的代码工作并没有被切断；他们的能力没有被消除。他们只是失去了与 Linux 上游协作的官方渠道。
这是 Iran、Cuba、Crimea 程序员现在的真实处境。他们被 GitHub 制裁——失去 GitHub 协作渠道。但他们能继续工作——读源代码、自己 build、分享自己的版本。他们的开发能力没有消失——只是变得更孤立2。
这就是 Stallman 1985 年争取的根本权利——“四项自由”。这个权利不是国家给的，是 GPL 等开源 license 通过版权法的反向使用建立的。国家可以制裁主体（公司、个人、网站），但不能制裁抽象的代码可读性。
让我们具体看几个例子。
Iran：美国对伊朗实施严格制裁 40+ 年。但伊朗 IT 行业仍然在运转。伊朗有大量优秀开发者——很多在国际开源项目做出贡献。他们用 VPN 绕开 GitHub 限制（违反 GitHub TOS 但实际是常态），他们用自托管 GitLab，他们用 USTC 等中国镜像下载开源软件3。
伊朗政府推 “National Information Network” 项目——某种程度上类似中国的国家信息基础设施。但这个项目规模有限，主要目的是国内审查而不是建立完整生态。伊朗 IT 行业的实际状态是“非常困难，但没崩溃”。
Cuba：古巴 IT 行业规模很小，但仍存在。古巴开发者多数通过 VPN 用 GitHub。古巴政府支持本土软件（Cubadebate 等），但生态有限。多数古巴开发者通过移民工作——很多在西班牙、加拿大、墨西哥的开源项目中贡献。
Crimea：克里米亚被并入俄罗斯后，克里米亚的开发者技术上“自动变成”俄罗斯地区——同时被乌克兰和美国制裁。具体地说，2014 年克里米亚 GameHub 维护者（我们在第 6 章提过）失去 GitHub 私有 repo 访问，但仍然能继续在本地写代码4。
朝鲜：这是最极端的例子。朝鲜国家级与外网隔离的 intranet（Kwangmyong）让多数公民完全没有外网访问。少数特许 IT 工作者能访问 GitHub 等平台（被严格监控）。朝鲜本土有 Red Star OS——基于开源 Linux 的本土发行版。朝鲜的“开源使用”几乎完全是“下载已有版本”，几乎不向上游贡献5。
把这四个国家放在一起，是个递减的频谱：从“困难但有生态”（伊朗）到“几乎没有生态”（朝鲜）。但即使在朝鲜，开源代码仍然能存在和运行。Red Star OS 仍然是基于 Linux 的——朝鲜不需要美国 / 欧盟 / 中国的批准就能用 Linux 内核。这是 GPL 等 license 的根本保护——任何人都能用、研究、修改、分发6。
这是这本书想强调的最重要的结论：开源运动取得的不是“全球协作的成功”——那是文化层面的，可以被国家穿透。开源运动取得的是“代码作为公共财产”的法律和技术基础——这个基础不能被国家剥夺，因为它的存在不依赖任何国家的承认。
具体来说，开源给世界留下了这些不可逆的属性：
法律层面：
技术层面：
社会层面：
这些属性放在一起，意味着即使在最糟糕的地缘冲突场景下——比如美国和中国全面“科技脱钩”——开源仍然能继续存在。Linux 不会消失，PostgreSQL 不会消失，PyTorch 不会消失。它们的法律基础（开源 license）不被国家管辖；它们的技术属性（可读、可分叉、可镜像）不依赖任何中心化机构；它们的社会基础（全球 maintainer 网络）有多元化抗冲击。
但这种“不可被消灭”不等于“不会被改变”。
开源在 2014 年之后的变化是深刻的。变化不是表面的——不是 logo 改了、不是发行版增加了。变化是结构性的：
每一种变化都是不可逆的。Linux Foundation 不会“撤销”OFAC 合规决定。GitHub 不会回到 2014 年的“假装看不见制裁”状态。CRA 不会被废除（即使 EO 14028 被部分撤回，欧盟规则会保持）。AI 模型权重的国家化已经开始，不会停止。
所以开源进入的是一个新常态。它仍然是开源——但它运行在分裂的主权地图上。Linux 上游仍然 accept 全球贡献——但 maintainer 角色受 OFAC 约束。PyTorch 仍然全球可用——但联邦合同不能用中国 AI 模型。GitHub 仍然 host 几乎所有项目——但部分国家的开发者被制裁。
这种新常态有时让人不舒服。它不像 1990 年代的“代码无国界”姿态那样有道德 clarity。但它也比“开源已死”更准确——因为开源仍然在运行，仍然在创造价值，仍然让 Iran、Cuba、Crimea 的开发者能继续工作。
读到这里，一个自然的问题是：那么开源运动应该怎么自处？
事实是：没有统一答案。不同的项目、不同的 maintainer、不同的国家会做不同的选择。但有几种 emerging 的应对策略值得记录。
1. 接受新常态，在其中找到位置
这是大多数主流项目的实际策略。Linux Foundation 接受 OFAC 约束（删除 11 人）。Apache Software Foundation 等待自己的 trigger。CNCF 多元化 contributor 池。PyTorch Foundation 通过基金会治理获得多边缓冲。
这种策略不是投降——是务实。它承认开源不能在“全球公地”姿态下持续，所以它选择在“分裂主权”现实中找到可持续位置。每个项目根据自己的具体情况决定该执行什么样的合规、避免什么样的政治站队、维持哪些跨国协作渠道9。
2. 主权迁移
小数项目选择主动迁移到中立或更友好的法域。RISC-V International 2019 年从 Delaware 迁瑞士是最清晰的范例。ClickHouse 2021 年从 Yandex 剥离到 Delaware 是另一种类型的“主权重组”。
这种策略有显著代价——昂贵、需要资本和人脉、可能损失部分用户。但对于面对极端主权风险的项目，它是合理选择10。
3. 平行生态备援
中国 OpenAtom、俄罗斯 GitFlic、欧洲 Codeberg——这些是“如果主流被穿透时的备援”。每个区域有自己的本土备援，确保该区域的开源工作不会因某个国际事件突然停止。
这种策略对国家级行为者最合理。它不是“反 GitHub”——是确保即使 GitHub 不可用，该国生态仍然能运转11。
4. 商业模式创新
D. Richard Hipp 用 Hwaci 模式维护 SQLite——自己开公司，提供商业支持，避开开源基金会政治。这种模式不可 scale，但它对特定项目有效。
类似的模式：wolfSSL 雇佣 Daniel Stenberg 维护 curl；Tidelift 为多个 maintainer 提供商业 sponsorship 中介；GitHub Sponsors 让用户直接资助 maintainer12。
5. 政府资助
德国 Sovereign Tech Fund / Agency 是这个方向的最明确范例。政府直接资助关键开源项目——不要求项目“国产化”或“领土化”，只要求项目能持续维护。这种模式 2022-2024 年在欧洲扩散。
这种模式跟 1985 年 Stallman 想象的“反企业的自由软件”完全不同——它是政府支持的开源。但效果是让维护者能持续工作13。
6. 完全去中心化
Radicle 等 P2P 工具尝试让开源完全脱离任何中心。这是最理想主义但最不实用的策略。绝大多数项目不会选择它，因为它的协作效率远低于 GitHub。
但它的存在本身有价值——它证明“如果一切糟糕，仍然有去中心化选项”14。
每一种策略都有代价。没有一个策略能让开源回到 2014 年之前的“全球公地”姿态——那个姿态在地缘政治升级后不可恢复。但每一种策略都让开源在新常态下持续运转。
如果要预测未来 5-10 年的开源世界，我会给出以下指标作为关键观察点：
短期（1-2 年）：
中期（3-5 年）：
长期（5-10 年）：
这些是真问题。它们的答案会决定开源运动接下来十年的形态。
最后回到一个具体的人——一个我们在第 1 章提到过的人。
Richard Stallman 现在 73 岁（截至 2026 年 5 月）。他仍然写关于自由软件的文章。他仍然在 FSF 的 board 上。他仍然反对几乎所有专有软件。他的立场没有改变。
但他周围的世界完全改变了。1985 年他创立 FSF 时，自由软件是边缘运动，对抗主流商业软件。2026 年，他创立的运动（以及它的衍生品）已经是世界上最大的代码协作模式。Linux 内核运行全球大部分服务器。Apache 项目支撑全球大部分大数据基础设施。开源 AI 模型——包括 DeepSeek 这种用 MIT License 发布的中国模型——正在挑战 OpenAI 的闭权重主导。
但这种胜利不是 Stallman 想要的那种胜利。他想要的是“四项自由”——用户自由的胜利。他得到的是“开源作为基础设施”的胜利。这两种胜利重叠但不完全相同。
Stallman 在多个场合表达过对这种状态的不满。他批评 OSI 把开源运动“道德上抽空”。他批评 Linux Foundation 太接近企业。他批评 Microsoft 对 GitHub 的收购。他批评 AI 时代对模型权重的特殊对待16。
但他的批评——不论对错——已经是少数声音。主流开源运动不再听他的指导。多数维护者甚至不知道 Stallman 是谁。他从开源运动的中心，变成了某种“良心代表”——重要但越来越边缘。
这是开源运动 40 年的诚实总结。它的创始者仍然活着，仍然坚持原则，但运动已经远超他的预期、超出他的控制、走向他不完全赞成的方向。这是任何成功运动的常见结局——创始者的视野被现实的复杂性超越。
但这种“超越”不是失败。如果 Stallman 1985 年的“四项自由”被 100% 实现，开源就不会成为今天的关键基础设施。它仍然是 1990 年代那种边缘乌托邦。
实际发生的是：Stallman 的“四项自由”作为根本属性被保留——任何开源代码仍然受这些自由保护。但围绕这些自由的实际治理被现实重塑。Apache 2.0 license 接受商业衍生作品；Linux Foundation 接受企业资助；MIT License 几乎无限制；OpenAtom Foundation 在中国注册；CRA 给开源 steward 一些责任。每一种都背离 Stallman 的纯粹道德立场——但每一种也让开源在更广的世界中扎根。
这个过程是不可逆的，也不应该可逆。1985 年的“四项自由”在 2026 年仍然有效——它们是法律工具，不会失效。但围绕它们的实际世界已经被多种力量重塑——企业、政府、维护者、用户。
理解这种“不可逆 + 必然变化”的双重性，是理解开源现状的核心。不是“理想已死”——理想仍然在工具中固化。不是“完美胜利”——胜利伴随复杂的妥协。是“在妥协中持续工作”——这是开源运动 40 年的实际形态17。
我们一起读了 12 章。我们看了一些具体的事件、人物、项目。但有一件事这本书一直避免直接说——我现在想说一下。
这本书是关于一个奇迹的。
奇迹是这样的：在 1985 年，一个 32 岁的程序员决定写一个完全自由的操作系统。他没有公司支持，没有政府资助，没有主流学术圈认可。他被广泛视为乌托邦主义者。
41 年后，这个完全自由的操作系统的核心组件运行全球绝大部分服务器。它衍生出了世界上最大规模的志愿合作。它的法律工具——GPL、Apache、MIT 等 license——被全球几十万项目使用。它让 Iran 的开发者能继续工作，让 DeepSeek 能挑战 OpenAI，让一个非营利项目能维护被几十亿设备依赖的代码。
这件事在 1985 年是不可想象的。Stallman 当时不能预测它的具体形态。1995 年的 Linus Torvalds 不能预测。2001 年的 Apache 维护者不能预测。2010 年的 Linux Foundation 不能预测。每一代人都在做自己当时认为正确的事，加起来就是今天的开源生态。
这个奇迹的代价是它的复杂性。它不再是简单的“自由 vs 不自由”。它充满了张力——商业 vs 道德，主权 vs 全球性，安全 vs 开放，资助 vs 独立。每个 maintainer、每个项目、每个基金会、每个国家都在自己位置上处理这些张力。没有统一答案。
这本书想做的不是给出统一答案。它想做的是让一个读者——可能是一个开源 maintainer，可能是一个政策制定者，可能是一个普通好奇者——能看清这些张力的具体形态。看清它们是怎么来的，它们现在如何，它们可能走向哪里。
读完这本书，如果有一件事我希望你记得，那就是这个：
开源没有死。它没有被国家完全捕获。它没有变成主权工具。它仍然是开源——可读、可分叉、可镜像。它仍然让 Lasse Collin 那样的芬兰单人维护者影响全球。它仍然让 Iran 的开发者能写代码。它仍然让 DeepSeek 能挑战 OpenAI。
但它也变了。它不再是 1985 年想象的“全球公地”。它运行在分裂的主权地图上。它的每一个治理实体受某个国家法律管辖。它的每一个 maintainer 处在多重压力下。它的每一个 release 都可能被各种合规要求审查。
这不是失败——是进入了一个更复杂的世界。开源运动的最大成就不是任何一个具体的胜利——是它仍然在运转。它穿过了 1985 年没人能预料的所有挑战——商业捕获、国家穿透、关键基础设施的责任、AI 时代的不确定性——仍然在工作。
未来 10 年它还会面对新的挑战——我们在前几章预测了一些（CRA 生效、Hugging Face 拆分、中国 AI 主导等）。它会做出新的妥协，发明新的工具，创造新的形态。每一代开源运动者都在自己的位置上做选择——这些选择加起来，决定下一个十年开源是什么。
这是一本“被捕获之后仍未死亡的解剖报告”。不是讽刺——是事实。开源被多种力量捕获了。它仍然没死。这件事的意义远超它的具体形态。
它意味着：一种自下而上的、跨国的、基于自愿协作的、依赖于法律工具反向使用的、由具体的人组成的运动，可以持续 40 年，能够穿越所有主权穿透，能够仍然在全球数十亿台设备上运行。这不是任何政府的功劳。不是任何公司的功劳。是 Stallman、Linus、Behlendorf、Collin、Stenberg、Goers、Freund 这些人——以及他们之前和之后的几千几万个 maintainer——共同的功劳。
他们没有得到什么金钱回报。没有什么名声。没有什么稳定的工作保障。但他们做的东西——这本书每一章都谈到的开源运动——是现代社会最有意义的合作实验之一。
如果你现在仍然在维护开源项目，谢谢你。如果你曾经是 maintainer，谢谢你。如果你下载过别人的开源软件、用过、贡献过 issue 或 PR——你也是这个奇迹的一部分。
开源没死。它在继续。这就是这本书的全部内容。
Communications of the ACM: “Anti-Sanctions: New Operating System for Mobile Devices”. Link →
Linux Foundation Annual Report 2023. 包括项目数量、贡献者规模。Link →
多个开源基金会（Linux Foundation、Apache、CNCF、PyTorch Foundation）对地缘政治压力的实际应对策略。
Sovereign Tech Fund / Agency 详见第 3、7 章。Link →
未来观察指标详见 research/future-indicators/ 与 frameworks/series-outline.md。
Vice: “The Internet Was Built on the Free Labor of Open Source Developers. Is That Sustainable?” 早期深度报道。Link →
这本书的十二章已经穷尽了我做 desk research 能找到的所有 2014-2026 年公开材料的主要面向。我读了 LKML 邮件归档、xz-devel 邮件列表、Russ Cox 的复盘、各种 threat intel 团队的报告、OpenSSF 文档、CRA 法案文本、BIS 出口管制文件、各国政策报告、维护者的公开 blog、独立媒体的深度报道。我也访问了所有引用源的链接，验证了大部分关键事实。
但 desk research 有边界。有些问题只能通过现场访谈、内部档案、私域社群、政府文件解密来回答。这一章列出二十个仍待后续研究者、记者、学者去挖的方向。
按“重要性 × 可达性”分四类：高优先级 × 高可达性、高优先级 × 中低可达性、中优先级、超时或难以挖掘。每一条说明：现有证据等级、田野能提供什么、预计成本和伦理风险。
这一章不要求读者去做。它是路线图，不是任务清单。如果你是开源治理研究者、记者、学者，或者只是对这些细节感兴趣，欢迎用它作为后续研究起点。
现有证据等级：C 级（多家私营 threat intel 报告，但无政府正式归因）
田野能提供什么： - 攻击者使用的 OPSEC（操作安全）模式的更细分析——commit 时区、邮件 metadata、IP 信息（如果能获得） - 跟其他已知国家级 supply chain 攻击的 TTP（tactics、techniques、procedures）对比 - 加密的 Ed448 私钥的 forensic 分析
可访谈对象： - Andres Freund（已多次接受公开采访） - Lasse Collin（一直保持低调，但通过 Tukaani mailing list 可能接受） - Russ Cox（research!rsc 作者，对 timeline 有深度研究） - Securelist、ReversingLabs、Mandiant、CISA 的 xz 调查团队 - 各 Linux 发行版的安全响应团队（Debian、Ubuntu、Fedora、Arch、SUSE）
预计成本：中等。多数研究者愿意公开讨论已知信息；归因方面会谨慎。
伦理风险：低。除非接触正在调查中的具体技术细节，公开材料层面安全。
现有证据等级：B 级（公开 LKML 邮件 + 多份新闻报道）但具体名单未在主流报道中完整公布
田野能提供什么： - 11 个具体的人是谁、他们为哪家公司工作、他们对删除的个人反应 - 被删除之后他们的实际状态（是否找到了“sufficient documentation”路径，是否考虑迁移到其他项目） - 俄罗斯境内 maintainer 社区对这件事的更广泛反应
可访谈对象： - Greg Kroah-Hartman（公开 maintainer，可能愿意谈合规细节，不会谈具体人） - James Bottomley（在 LKML 上做了详细法律解释） - 被删除的 maintainer 本人（需要通过 LKML 邮件 + 已知公司联系；伦理上需要谨慎） - LWN.net 编辑（多年报道 Linux 内核动态）
预计成本：高。被删除人可能不愿公开讨论；通过中介接触需要时间。
伦理风险：中等。涉及个人隐私和职业现状，需要严格脱敏处理。
现有证据等级：B 级（Securelist 和 ReversingLabs 已识别 Jia Tan、Jigar Kumar、Dennis Ens、Hans Jansen、krygorin4545、misoeater91）
田野能提供什么： - 是否还有未识别的关联账号 - 这些账号在其他开源项目中是否有过类似活动（可能针对其他项目的类似攻击） - Wayback Machine、Internet Archive 的早期备份是否包含更多线索
可访谈对象： - Evan Boehs（独立研究者，详细记录 xz 时间线） - Securelist 和 ReversingLabs 的研究团队 - GitHub 安全团队（应该有内部账号关联数据）
预计成本：中等。需要 patience 做大量数据交叉。
伦理风险：低。所有相关账号都是公开的。
现有证据等级：D 级（部分匿名报告，没有系统统计）
田野能提供什么： - 截至 2026 年 9 月 CRA 部分生效后，有多少项目明确宣布不向 EU 用户提供 - 这些项目的规模分布（小项目占多数还是中大项目？） - 是否有项目专门为 EU 合规重新设计（如增加 SBOM、incident reporting 等）
可访谈对象： - OpenSSF 政策团队（维护 CRA 影响 tracker） - Eclipse Foundation、Linux Foundation Europe 的合规团队 - 中小开源项目的 maintainer（通过 GitHub、Mastodon 等渠道）
预计成本：低-中等。多数信息可以通过 survey + 邮件获得。
伦理风险：低。
现有证据等级：C 级（行业报告，但没有具体到关键基础设施的内部部署细节）
田野能提供什么： - 美国、欧盟、中国关键基础设施中开源依赖的实际清单 - 不同行业的 SBOM 采用率差异 - 关键 supply chain 攻击预案的具体内容
可访谈对象： - CISA、NSA Cybersecurity Directorate、欧盟 ENISA 的政策制定者 - 大型金融机构的 CISO（多数不愿公开讨论） - 医疗设备公司的安全工程师（FDA 监管下，SBOM 是合规要求） - 能源行业 ICS / OT 安全研究者
预计成本：高。需要建立专业网络。
伦理风险：中等。涉及国家关键基础设施的细节，可能触及保密信息。
现有证据等级：B 级（公开报道 + CSIS 智库分析）
田野能提供什么： - Intel、Google、Western Digital 等美国 RISC-V 成员公司的内部决策过程 - 他们如何在“国际中立的 RISC-V 标准化”和“美国出口管制压力”之间平衡 - 是否有美国公司因压力退出 RISC-V 国际基金会工作组
可访谈对象： - RISC-V International（瑞士）的高级管理层 - 美国半导体行业协会（SIA）政策团队 - 美国商务部 BIS 的 RISC-V 调查团队
预计成本：高。涉及商业机密和政策敏感性。
伦理风险：低-中等。
现有证据等级：D 级（部分企业公开声明备案通过；拒绝率不公开）
田野能提供什么： - 国家网信办备案的具体审查流程（公开材料只有大纲） - 通过率、拒绝率的统计数据 - 拒绝的典型原因（内容合规 vs 技术不足 vs 数据来源问题）
可访谈对象： - 已备案 AI 公司的合规团队（多数不愿公开讨论细节） - 协助备案的咨询公司 - 网信办前官员（如果能接触到） - 不愿/未能备案的项目的开发者
预计成本：中-高。
伦理风险：中等。涉及中国境内监管敏感性。
现有证据等级：C 级（美国 OFAC 公开 SDN list；其他国家的等同工具不太透明）
田野能提供什么： - 欧盟制裁 list（EU Consolidated List）对开源协作的实际执行 - 英国 OFSI（Office of Financial Sanctions Implementation）对开源平台的影响 - 中国“不可靠实体清单”对外国开源项目的影响
可访谈对象： - OFAC、OFSI、EU Commission 制裁政策制定者 - 大型开源基金会的合规律师 - 各国制裁法律学者
预计成本：中等。
伦理风险：低。
现有证据等级：D 级（公开 Trust & Safety 文档，但内部决策过程不透明）
田野能提供什么： - Hugging Face 如何决定哪些账号 / 模型受 OFAC 影响 - 内部是否有“合规升级”路线图 - 如何处理 OFAC 不明确的边缘案例（如中国模型在美国法律下的灰区使用）
可访谈对象： - Hugging Face 管理层（Clement Delangue 等） - 法律顾问与合规团队 - 大量在 Hugging Face 上托管模型的实验室
预计成本：中等。Hugging Face 多数对话相对透明。
伦理风险：低。
现有证据等级：B 级（USTC、Tsinghua 等镜像公开运行状态）
田野能提供什么： - 主要中国镜像与 GitHub、npm、PyPI 等原仓的实际同步延迟 - 哪些项目被有意 / 无意排除在镜像之外 - “假如 GitHub 不可用” 场景下，中国镜像能多大程度上保证生态运转
可访谈对象： - 中国主要镜像站的运维团队（USTC、清华、阿里等）
预计成本：低。多数镜像运维公开 contact。
现有证据等级：B 级（公开成立信息，但具体财务和治理不透明）
田野能提供什么： - OpenAtom 的年度财务（捐款来源、支出结构） - 治理结构的实际运作（董事会、决策机制） - 与 Linux Foundation 的合规对比
可访谈对象： - OpenAtom 管理层 - 主要 OpenAtom 项目的 maintainer
预计成本：高。中国非营利透明度有限。
现有证据等级：B 级（公开协议数）
田野能提供什么： - 23 个签署协议国家中，有多少实际部署了 UPI / DigiLocker 等 - 印度 IT 行业从 India Stack 推广中的实际收益 - 与中国“数字丝绸之路”的对比
可访谈对象： - 印度 IT 部、Modi 政府数字基础设施团队 - 国际数字公共物品基金会（Digital Public Goods Alliance）
预计成本：中等。
现有证据等级：C 级（Tidelift 调查数据）
田野能提供什么： - 25-35 岁开发者进入 maintainer 角色的比例变化 - 不同地区的趋势差异（美国、欧洲、中国、印度等） - “maintainer cohort 衰老” 的具体数据
可访谈对象： - Tidelift、GitHub 等的研究团队 - 大型开源项目的 governance team
预计成本：中等。
现有证据等级：C 级（OpenSSF Alpha-Omega 项目报告，但行业整体数据缺乏）
田野能提供什么： - SLSA Level 1-4 在主流项目中的实际采用率 - Sigstore 签名在不同包管理器中的覆盖率 - Reproducible Builds 在 npm、PyPI、Maven 等的状况
可访谈对象： - OpenSSF 工程师 - 大型企业的 supply chain security 团队
预计成本：低-中等。
为什么难以挖掘：除非有政府正式归因或攻击者被抓，否则只能停留在“嫌疑指向”
当前不要尝试。等待美国政府或其他主要政府发布正式归因后再调查。
为什么难以挖掘：涉及最高级保密；现有泄露材料（Snowden 等）已经多年，新材料不太可能短期出现
仅追踪现有公开材料，不深挖。
为什么难以挖掘：中国境内调研敏感性；多数证据是间接推断而非直接证据
通过公开学术研究跟踪，不做现场田野。
如果想长期追踪开源世界的地缘政治变化，可以监控这些指标：
1. 第二次 xz 类型的国家级供应链后门事件
至 2026 年 5 月没有第二次被识别的事件。但概率不为零——继续监控 oss-security 邮件列表、安全研究公司报告。
2. Linux Foundation 是否扩展 MAINTAINERS 清理到其他国家
2024 年 10 月针对俄罗斯。继续监控：是否会有中国、伊朗、朝鲜籍 maintainer 被以同样理由清理。
3. EU CRA 2026 年 9 月部分生效后的实际影响
4. AI 模型权重的法律定性
5. 主要 forge 平台的合规执行精细度
6. 国家级 AI 开源战略的演化
每一项都是 ongoing 的故事。这本书呈现的是 2014-2026 这一段的快照。下一段 5-10 年的故事还在写。
如果你想在这些方向做田野研究，几个伦理原则值得记住：
1. 保护个体 maintainer 的隐私
即使他们公开了某些信息（GitHub username、邮件等），他们没有同意成为研究对象。在引用他们之前问自己：他们愿意被这样写吗？
xz 后门事件让 Lasse Collin 不情愿地成为公众人物。这本书引用了他的公开邮件，但避免对他做心理推测。后续研究应该保持同样克制。
2. 区分合规与政治
Greg Kroah-Hartman 做删除决定是合规执行，不是政治推动。把合规决定写成政治站队是错的。同样，被删除的 maintainer 不一定是政治支持者——他们是合规风险的承担者。
3. 不点名被切断的开发者
伊朗、克里米亚、朝鲜的开发者已经处在脆弱状态。如果你做现场调研，避免点名具体个体——这可能让他们面对额外的风险（既来自本国监管，也来自国际制裁）。
4. 接受归因的开放性
xz 后门归因没有确凿证据。任何研究者宣称“知道是谁”——除非他们有明确证据——都在做不负责任的推测。这本书保持“嫌疑指向但未定论”。后续研究应该保持同样标准。
5. 不浪漫化 maintainer 或妖魔化国家行为者
Daniel Stenberg、Lasse Collin、Andres Freund 不是英雄——他们是处在结构张力中的具体的人。同样，中国、俄罗斯、美国不是单一意图的整体——每个国家都有内部博弈、不同声音、复杂利益。把任何一方简化为英雄或反派是写糟的研究。
最后我想做几个诚实声明。
这本书有相当大的不完整性。它依赖公开 web 材料、新闻报道、学术研究、官方文件，没有任何独立的现场田野。这是 desk research 的固有限度。
具体的不完整性包括：
这些不完整性不是 oversight——是 desk research 的边界。后续研究者如果想填补这些空白，应该考虑混合方法：desk research + 关键访谈 + 现场观察 + 内部文档分析。
这本书希望做的是给后续研究一个起点——一个能让读者从“模糊感觉开源在变化”到“具体理解开源如何在变化”的过渡。它不是终点。它是一个邀请——邀请其他研究者、记者、学者、政策制定者去填补这些空白。
如果有一天某位读者用这本书作为出发点，做出更深入的研究——挖出我没看到的事实、访谈我没接触的人、看清我没看清的细节——那是这本书最希望发生的事。
写完十二章 + 这个附录，写作工作就结束了。
这本书探讨的开源运动地缘政治化是 ongoing 的故事。10 年后回看 2014-2026，我们会知道这十年是开源的成熟阶段、衰退阶段、还是分裂阶段。现在没法知道。
但有一件事到 2026 年 5 月是清楚的：开源没有死。即使所有这一切——制裁、社会工程、合规、主权穿透——它仍然在运转。Stallman 1985 年的想法仍然有效；Linus 1991 年的内核仍然在运行；DeepSeek 2025 年的模型仍然被全球下载。
这是个奇迹。我们应该承认它，享受它，保护它。
不论开源接下来 10 年走向哪里，希望读者读完这本书之后，能对它的具体形态——它的脆弱、它的力量、它的复杂、它的不可预测——有一份具体的、不被简化叙事左右的理解。
这就是这本书想留给读者的。
Tidelift 2024 maintainer survey. Link →
OpenSSF Alpha-Omega 项目 Reports 页面。Link →
Open Regulatory Compliance Working Group (ORCWG). Link →
CHAOSS Community Health Analytics for Open Source Software. Link →
SovereignTech Agency: 关于跨国开源资助模式的范例。Link →
Sourcegraph 2023 “State of Open Source” 报告。中国 contributor 增长 47% 数据。
Linux Foundation Annual Report 2023. 项目数量与 contributor 规模。Link →