FreeBSD参与者、Varnish HTTP Cache开发者 Poul-Henning Kamp，在 ACM Queue 2026 年第 24 卷第 3 期发表告别专栏，谈的不是某个项目的版本变化，而是他对 FOSS（自由及开源软件）未来处境的推演：年龄验证需求，可能把软件完整性证明、可信计算平台和受认可的应用商店串成一条制度链，最后压缩用户修改软件后运行的空间。
这是一种前瞻性判断，不是欧盟已经决定禁止修改开源软件，也不是年龄验证已经等同于全面实名制。Kamp真正提出的警告是：当监管要求“出了问题必须找到责任人”，可自由修改的软件会越来越难进入那些需要认证、审计和合同担保的系统。开源未必会关闭源码，但它可能只剩下“可阅读、可复现”，运行自由则要经过平台和机构的许可。
Kamp的告别专栏，把风险链条指向“运行自由”
传统 FOSS 的便利，来自一组相对宽松的安排：源码公开，任何人都能复制、修改、重新编译；维护者通常通过许可证、免责声明和社区协作降低个人责任。Linux、FreeBSD，以及大量基础设施软件，都在这套规则下成长。
Kamp担心的变化，发生在另一条线上：
年龄验证需求
→ 用加密证明软件没有被修改
→ 依赖可信计算平台确认运行状态
→ 只有未修改的软件，或来自受认可应用商店的软件，才能接入服务
这条链并非技术上必然成立。远程证明、可信启动等技术，完全可以被设计成“证明软件版本”，也可以被平台运营者用来拒绝未经认可的修改版。决定用户能否运行自编译软件的，往往不是密码学本身，而是服务商、操作系统厂商和监管机构怎样设置接入规则。
年龄验证只是引线。真正的压力来自问责和数字主权。
当一套软件被用于医疗、能源、金融或公共服务，采购方会要求漏洞响应、版本追踪和责任承诺。一个由个人维护者维持的项目，很难长期提供这些东西。软件出了事故，许可证里的免责声明也未必能满足监管者、保险公司和采购合同的要求。
我的判断是，FOSS最可能出现的变化不是“源码消失”，而是自由权分层：
| 权利或能力 | 传统FOSS的常态 | 可能出现的制度限制 |
|---|---|---|
| 阅读源码 | 通常开放 | 仍可能保留 |
| 修改并重新编译 | 用户自行决定 | 技术上可行，但未必能接入关键服务 |
| 运行修改版 | 通常由用户控制 | 可能被安全启动、远程证明或服务端策略限制 |
| 获得企业采购与合规背书 | 依赖社区信誉 | 需要机构、基金会或企业承担合同责任 |
这比“开源终结”更准确，也更值得警惕。开源项目仍然可以在代码托管平台上存在，但如果修改版无法启动、无法通过设备认证、无法连接云服务，它的自由就从使用权退化成了阅读权。
欧盟监管真正改变的，是谁要为软件签字
欧盟《网络韧性法案》（Cyber Resilience Act，CRA）给非商业活动中的 FOSS 留出了豁免空间。这一点不能被省略：个人发布代码、社区协作和不以商业活动为目的的维护，并不自动等同于受到完整的产品合规义务约束。
但“开源”也不等于天然免除责任。项目一旦通过商业服务、企业支持、产品集成或其他带有盈利性质的活动进入市场，是否属于非商业 FOSS，就不能只看许可证文本。CRA 已于 2024 年通过，主要义务分阶段实施，企业需要面对漏洞报告、产品安全和合规责任；具体项目是否落入哪一类，还要看其活动方式、产品角色和商业关系。
这形成了一个很现实的分界：
- 代码由社区维护，但没有合同收入，项目可能仍接近非商业 FOSS；
- 代码被公司打包销售、提供托管服务，或成为商业产品的一部分，责任链就会变长；
- 项目即使没有直接卖软件，只要企业围绕它收费，维护者与企业之间也可能需要重新划分义务。
传统模式里，维护者靠声誉、时间和免责声明维持项目。未来更可能出现 FOSS steward、基金会、企业或委员会，代表项目接受审计、签署合同、处理漏洞通报。技术工作没有因此减少，反而会多出安全响应、版本归档、SBOM、合规文档和责任保险等成本。
这也是 Kamp 的判断比“监管要消灭开源”更有现实感的地方：监管未必要求关闭源码，却可能把关键软件的合法使用资格交给能够承担责任的组织。
对维护者和欧洲CIO，决策会先变得更保守
关键基础设施和企业开源项目维护者，最先遇到的不是代码还能不能发布，而是谁愿意为发布后的结果负责。
一个只有个人或松散社区的项目，可能继续适合开发环境和普通服务器；但进入医院、交通系统或政府平台后，采购方会追问：
- 谁负责漏洞响应，响应时间能否写入合同？
- 哪个版本经过审计，修改补丁如何留痕？
- 项目停更时，谁接手维护？
- 企业自编译版本能否通过设备或云服务的完整性检查？
维护团队若不想被机构接管，就需要建立更清楚的发布、签名、审计和安全响应流程。若不愿承担这些成本，项目可能主动缩小使用范围，或者把维护权交给基金会与企业。这不是代码能力问题，而是组织能力和资金来源问题。
欧洲企业和公共部门的 CIO 则会面对另一种选择。数字主权项目常希望掌握源码、减少对单一供应商的依赖；但一旦采购规则要求持续合规和责任担保，最便宜的开源方案未必还是总成本最低的方案。预算可能从“购买软件许可”转向购买长期维护、审计和安全响应。
因此，短期内不必因为 Kamp 的文章就停止采用 Linux 或 FreeBSD。更现实的做法是把采购问题拆开：
- 允许团队修改源码但确认修改版能否脱离原厂服务独立运行；
- 把签名、构建链、漏洞响应和项目接班人写进合同；
- 区分“能运行”与“能通过关键平台认证”不要把两者当成一回事。
这也解释了它和过去开源争论的差别。过去的争论常围绕代码是否开放、许可证是否自由；现在的争点开始转向软件能否被信任、谁来证明它安全、谁来赔付事故。源码仓库里的自由，可能还在；产品入口处的自由，未必。
眼下仍有几个变量没有答案：欧盟成员国和监管机构如何解释商业活动边界，设备与云服务是否会普遍采用强制远程证明，企业会不会为社区项目建立新的托管组织。Kamp的推演成立，需要这些环节逐步接上；任何一个环节不成立，结论都会弱一些。
但维护者和 CIO 不必等到规则完全落地才行动。真正该审查的，是项目有没有明确的责任主体，以及用户修改软件之后，是否还拥有把它运行起来的最后一把钥匙。
锐评
开源未亡，免责时代先退潮。源码可以留下，权限却会被责任、认证与平台一层层收回。