共计 8138 个字符，预计需要花费 21 分钟才能阅读完成。
TLDR_（如果感觉本文太长者，能够只看摘要）_
包含开源软件在内的软件正在受到全世界的监管。这篇简短的博文解释了欧盟《网络韧性法案》的背景、长处、缺点以及对开源软件可能产生的负面影响。此外，它还解释了该法案在欧盟零碎中的简单流程，以帮忙人们理解时间表和如何推动扭转。
如果您须要更多的口头介绍，Eclipse 的 Mike Milinkovich 提供了一个十分新鲜、清晰的演示，涵盖了雷同的内容。如果您更喜爱简短的口头呐喊，那么无妨试试 GitHub、CNLL（法语内容）、Linux 基金会或更宽泛的行业响应。
背景
尽管与其余大型行业和部门相比，IT 行业的规模还很小，但在过来的几十年里，它已成为社会的要害。当初，在新闻中常常能够看到软件和 IT 行业的大型事件。而且，更常见的是由某种劫难引发的故事：配置谬误、破绽或显然太容易 “ 进入 ” 的犯罪分子和国家行为。当初，不良的 IT 实际也影响到了次要行业，从能源运输、制造业到金融业，再到专制过程和治理良好的政府。
正因为如此，社会和各种管理机构当然也留神到了这一点，因而，世界各地都在制订各种软件管理条例和立法。
历史
以工程史为例，这种监管是再失常不过的后果。19 世纪末，机械行业获得了惊人的倒退，这在肯定水平上要归功于蒸汽机的创造。但随着这一行业的倒退，蒸汽锅炉爆炸事变也随之增多。这些事变通常会夷平半个城镇。
1865 年，蒸汽船 Sultana 号发生爆炸，造成 1,167 人丧生。因而，美国锅炉制造商协会（以下简称 ABMA）成立，开始对该行业进行自律。通过数百次此类爆炸，以及 1905 年在波士顿一家鞋厂产生的一次代价特地昂扬的爆炸，政府才开始采取干涉政策。
乏味的是，应答 1905 年劫难的并不是 ABMA，而是由五名工程师组成的小组，他们是美国机械工程师协会的成员，这是一个由集体而非公司组成的业余组织。这些人撰写了第一版《锅炉标准》，随后不久便失去了马萨诸塞州立法机构的认可。
从很多方面来说，这些工程师、这些集体志愿者 “ 自救 ” 来解决问题；就像咱们明天在 ASF 的开源以及 IETF（互联网工程工作组）在制订互联网规范中所做的一样。是业余个人解决了问题：而不是他们的雇主、行业或美国锅炉制造商协会。
现状
目前，世界各地简直都有大量立法正在进行中；美国和欧盟稍稍当先（各国决策者之间也进行了大量协调）。
在这篇博文中，咱们临时只关注其中一项：欧盟的《CRA – 网络还原力法案》，因为从时间轴的角度来看，这是 “ 先行者 ”。
这绝不是最重要的立法。在 ASF，咱们认为欧盟的《PLD – 产品责任指令 Product Liability Directive》（引入了对软件 “ 严格课责 ” 的标准）、美国的第 14028 号行政命令 “ 进步国家网络安全”和 “2023 年开源软件平安法案 ”（美国）可能会产生更大的影响。
这一点可能尤为正确，因为美国立法能够通过国家标准与技术研究院（NIST）为外国制订规范，而国家标准与技术研究院制订规范的速度通常快于欧盟制订规范的速度（因而很可能制订出寰球规范）。
这种事件能做吗？
在日常实际中，软件开发人员很少须要思考监管问题（除非 TA 们从事某些特定畛域的工作，如医疗、航空航天、金融或核能）。开源许可证（在咱们的上游）和提交者许可证协定（在咱们的上游）往往有范畴宽泛的免责申明。咱们通常将代码等同于编撰成文的常识或舆论。
但在实际操作中，事件并非如此简略。例如，在 ASF，咱们多年来始终须要提交一些文件，让美国工业与安全局（BIS）晓得咱们提供下载的加密代码的确切地位_[https://infra.apache.org/crypto.html]_。由 ASF 公布的代码不能进口（或再进口）到特定目的地或特定名单上的人。
网络韧性法案
在欧盟，《CRA – 网络韧性法案》目前正在法律制订过程中（将于 2023 年 7 月 19 日进行要害投票）。该法案将实用于欧盟的大量软件（以及带有嵌入式软件的硬件）。该法规的初衷是好的（也能够说是早该如此）：使软件更加平安。
| 译者注：欧盟《网络韧性法案》，曾经投票通过，然而引发了许多拥护意见，后续倒退值得察看。
该法案试图通过多种形式来实现这一指标。最重要的是，CRA 将要求市场在设计、构建、发行和保护软件时对安全性采纳行业良好实际。在最根本的层面上，CRA 正式确定了 ASF 现行的根本政策：治理您的谬误，承受、分流并修复安全漏洞。这也是通过将其与良好的治理或实际相结合来实现的；例如，在适当的时候注册 CVE（Common Vulnerability and Exposures 常见破绽和危险）、编写发行版阐明和进行适当的版本治理（平心而论，其中一些咱们应该进一步正规化和改良）。
CRA 还将试图确保欧洲市场上的所有软件都能达到某种最低的安全级别，具体做法是在 CE 合乎性申明中进行相当简略的自我认证。或者，对于更要害的软件，如防火墙或平安加密密钥飞地，由内部、受监管的指定机构进行理论的 “ 真正 “ 认证和审计。CRA 还将定义一系列流程，以监控市场的合规性。
| 译者注：
- “CE”标记是一种产品安全认证标志（即只限于产品不危及人类、动物和货品的平安方面的根本平安要求，而不是个别品质要求），被视为制造商关上并进入欧洲市场的护照。CE 代表欧洲对立（CONFORMITE EUROPEENNE）。
- 平安加密密钥飞地：是指硬件的处理器和内存的受爱护局部。
欧盟政策制定者意识到，这些 “ 行业最佳实际 ” 还没有失去很好的定义（在整个行业内，ASF 的平安实际是例外，而不是一体实用的规定）– 许多 CRA 都依赖于国际标准组织来制订规范，人们能够用这些规范来审核本人的我的项目（自我认证），或者内部审核人员也能够应用这些规范。
此外，人们还冀望重大破绽能失去非凡解决，并尽早报告。稍后再详述。
对开源的影响
如果你关注过各种博客和公开信，开源基金会始终在关注如何帮忙欠缺 CRA 的现有措辞，使开源软件取得 “ 豁免 ”；也就是说，只有当代码来到了开源公域_（译者注：Commons 亦可翻译为公共资源）_时，CRA 才实用；而后持续实用于整个商业供应链。同时，当某些货色（如平安修复）再次进入公域时，《CRA – 网络韧性法案》也不再实用。
总的来说，这些开源基金会或是社区的致力并不胜利。《CRA – 网络韧性法案》历次迭代的文件版本都有很大变动，但不是围绕着以上所述开源基金会或是社区关切的具体政策问题。
为了理解起因，ASF 的代表（连同 OpenSSL）于 7 月 7 日间接与欧盟进行了对话，这是咱们第一次真正可能与立法者进行有意义的互动。
从这次谈话中，咱们理解到，政策制定者十分分明，开源对 IT 行业至关重要，无论是对 “ 生产 “ 还是翻新都是如此。正因为如此，他们心愿防止饮鸩止渴。
另一方面，欧盟立法者也意识到，开源通常占典型欧洲中小企业（SME）经营或取得许可的软件堆栈的 95% 或更多。而中小型企业作为将其推向市场的一方，要对整个软件栈负责。
据咱们理解，政策制定者认为这些流程改良（和（自我）认证）的老本很高；大概会减少 25% 的管理费用。这是基于最近在医疗畛域引入的相似法规和 CRA 影响评估（任何欧盟法律提案都须要将其可能产生的经济影响记录在案）。
因而，从中小型企业的整个堆栈（即 95% 的开源代码和 5% 的私家秘方）来看，对于大多数欧洲中小型企业来说，在全副 100% 的代码上额定付出的致力将是其工程致力的数倍，因而是不可行的。而欧盟的想法是，认证他们在开源堆栈根底上构建的 5% 或 10% 的代码要容易得多。
因而，政策制定者 (1) 向 ASF 明确示意，他们打算将 CRA 实用于开源基金会。目前，凋谢源代码的例外情况要么是纯正的业余爱好者，要么是不在现实生活中应用的代码，要么是诸如镜像和软件包仓库（如 NPM 或 Maven Central）之类的货色。他们的做法是，如果软件在商业环境中的任何中央应用，就推定其具备商业用意。
欧盟流程和 CRA 的现状
欧盟的一项立法通常由欧盟委员会起草（该委员会还负责筹备”影响钻研”等工作）。而后在议会进行探讨。探讨个别在较小的委员会中进行。这些委员会编写报告，最终立法提交议会全体会议表决(2)。
CRA 的次要委员会是 LIBE、IMCO 和 ITRE。
第一个委员会是公民自由、司法和外交委员会（LIBE），负责探讨 “ 言论自由 “ 等问题，但该委员会回绝提交报告。接下来，外部市场和消费者爱护委员会（IMCO）钻研了什么对消费者和外部市场是重要的。该委员会编写了一份报告，并提交给了工业、钻研和能源委员会（ITRE）。
尔后，工业、钻研和能源委员会（ITRE）编制了一份协商一致的文件，预计将于 20230717 这一周进行公开探讨，并取得委员会的最终批准（在取得批准的状况下，委员会个别不进行表决）。
一旦这项工作实现，提案将提交欧洲议会表决。依据过后的争议或共识水平，可能会、也可能不会进行探讨和自在表决。
与此同时，欧盟的第三方 – 即欧盟理事会 – 也在筹备其版本的法案。次要由各国的相干部长从外国的角度进行审议。而后，三个版本（欧盟委员会、议会和理事会）将在 “ 三方合议庭 ”（Trialogues）中进行闭门探讨，最初产生成为法律的最终版本。
较量情况
目前，据说立法过程中的所有各方都已达成了大抵的共识 – 其中有两方与 ASF 分享了他们的观点，即不存在争议。此外，各种共识文件的正本也已泄露 – 因而咱们晓得它们之间的差距并不大，当初咱们也能够开始对它们进行剖析了。
CRA 给行业带来的问题
目前的定义(3) 规定，《反垄断法》实用于 ASF、及其所有（意愿）开发人员以及咱们的所有产出。而且，依据 ASF 与政策制定者的谈判理解，这是无意为之。
对 CRA 的忧愁有很多，但对 ASF 社区来说，以下几个问题可能是最重要的。
公域的概念与商业市场并无区别，它是一种全押模式：第一个问题是，《反垄断法》采取的是全有或全无的二分法。要么退出，要么退出。当你退出时，对你实用的基本上就是须要实用于发售给消费者的全套商业产品的内容。
尽管开放源码可能与此相近（如 Apache Netbeans 或 Apache Zeppelin，只管没有理论商业产品发售），但开放源码个别不属于商业环境。相同，它能够作为共享常识或公共资源来治理。就像学术论文或参考蓝图一样。CRA 并不抵赖这一点 – 因而，CRA 齐全实用于开源软件 ”（而不是仅仅实用 CRA 中在这种状况下可能有意义的因素 – 如良好的破绽解决、版本控制和“软件物料清单 -SBOM”）。
除非开源我的项目具备 “ 齐全扩散的开发模式 ”，否则 CRA 将对其进行监管。然而，” 公司 ” 雇员领有奉献提交（commit）权的我的项目将不会被豁免（无论上游开源单干是否与其雇主的商业产品有任何或是毫无关系）。有些我的项目，如古老的 OpenSSL 我的项目，其模式甚至更为简单。
这颠覆了开源的双赢准则。如果禁止企业维护者，企业可能会放弃让其员工保护我的项目，从而侵害开源翻新生态系统，具备讥刺象征的是，这将毁坏其韧性及其对经济 / 增长的微小推动作用（依据欧盟影响评估，每年 90 亿欧元）。
这也让人很难看出 ASF 社区中有谁会去做 ASF 可能被要求须要做的额定的（自我）认证工作。
这样做的净成果实际上相当宽泛。举一个 “ 序言(4)，10a “ 中的例子（这样的例子还有很多）：
同样，如果自在和开源我的项目的次要贡献者是受雇于商业实体的开发人员，而且这些开发人员或雇主能够控制代码库中承受哪些批改，则该我的项目个别应被视为具备商业性质。
在这里，这些贡献者与商业雇主之间不足交易关系的联结是个问题。例如，开发者能够是受雇于商业航空公司（即商业实体）的飞行员，利用业余时间为开源做出奉献：这部分政策将使这种奉献具备 “ 商业性 ”。此外，在 ASF，次要贡献者（提交者）当然能够对进入代码库的内容进行肯定水平的管制(5)。
| 译者注：意即与开源没有半毛钱关系的雇主航空公司也将蒙受池鱼之殃，而被列入监管范畴内。
更蹩脚的是，受影响最重大的开源组织类型也正是那些现在往往领有十分成熟的平安流程的组织，它们负责任地分流、修复和披露破绽，并提供与之相匹配的 CVE（常见破绽和危险）。一般来说，CRA 须要在上游，行将产品投放到市场上的公司中推动重大改良。而当初却有可能呈现相同的状况。
CRA 影响了齐全由志愿者领导和驱动的我的项目（如 ASF），在这些独立自主的 ASF 我的项目中，没有任何公司能对产品的操作和公布有任何影响。而 CRA 将对任何商业实体的员工领有奉献提交（Commit）权的我的项目都会受到影响。
这就带来了一个问题：无论是商业公司还是开源我的项目，都须要对哪些提交者能够批改代码、承受哪些赞助以及承受哪些补丁等问题更加审慎。
在 CRA 认证中，有一个很强的假如，即模块的（自我）认证是 “ 传递性 ” 的；也就是说，如果你用通过认证的模块构建了一些货色，你只须要认证你所做的 “ 额定 “ 的一些事件。可怜的是，这在个别状况下是不正确的；认证通常在很大水平上是要表明你（作为最终承担责任的组织）是如何确保所交付的货色适宜你在客户的特定环境下交付的目标的。开源组织在自我认证其构建的软件模块时，并无奈提供 “ 上游”信息。
认证的外围是确保所公布的信息对其预期目标具备适当的安全性。具体地说，就是在设计时就思考到平安问题，布局出威逼行为者、载体和危险。而后依据危险做出正当的工程斗争。
遗憾的是，在开源畛域，咱们往往不晓得咱们的软件会被如何应用。而且，正如咱们在过来十年中学到的（困而知之），对于咱们良好治理共享资源来说，要害是咱们不能在许可证中_（译者注：对如何应用开源软件）_进行歧视或限度（事实上，这也是开源定义的一部分）。
| 译者注：开源定义 Open Source Definition 是 OSI 制订对于开源许可协定的 10 条根本准则。违反这些准则的许可协定，不得自称为”开源”许可协定。
有些任务简直是不可能履行的：例如，有一项任务是 “ 提供没有已知可利用破绽的产品 ”。这简直是一个不可能设定的规范；尤其是开源软件的作者既不晓得也无法控制他们的代码是如何被整合到上游的。
下一个问题与规范无关。CRA 提到了大量 “ 待编写 “ 的国际标准（个别认为由 CEN-CENELEC 制订）。一般来说，IT 行业，尤其是开源，在与这些规范机构单干方面并没有很好的记录（也蕴含了 ASF），局部起因是简直所有要害的互联网规范都由 IETF 和 W3C 保护。事实上，这些规范组织的章程不容许开源组织以有意义的形式成为其成员的状况并不少见。
CRA 要求在破绽修复前，以小时为单位的时限外向 ENISA（欧盟机构）披露重大的未修补破绽和被利用破绽。这与行业最佳实际 – 负责任地披露修复和（变通的）解决办法 – 南辕北辙。
而且，这种过早的报道不仅会扩散公布修复信息的注意力，对于国内社会来说，还很容易触犯其余国家保持要雷同信息的规定，或者更蹩脚的是，禁止分享此类信息。这就毁坏了开源所依赖的偏心公正的报告的文化外围。
而且，只有 当这些信息被 宽泛共享 时，才会对 ENISA 有用 – 因而，各组织理当抉择审慎、寰球 “ 偏心 “ 的计划，采取简单易行的办法：确保永远不会据说这些问题。或者，反其道而行之，在（第一个）报告截止日期完结之前，即在问题失去解决之前，将问题公之于众。
| 译者注：意即在问题解决前，不对外颁布；或是一有问题，立刻寰球颁布。而不是优先将问题只告诉某些特定机构，如欧盟的 ENISA。
因而，这又是一个例子，阐明 CRA 尽管用心良苦，但最终可能事与愿违。
一个无效的 CRA
纵观欧洲目前的 IT 行业，咱们能够发现，造成 IT 行业平安状况不佳的根本原因通常并不是开源（尤其是来自 ASF 这样的组织）。事实上恰恰相反。
与此相反，欧洲的大多数中小型企业很少更新他们所依赖的零碎，通常也不善于解决平安问题报告。而 ASF 的（定期）更新为他们带来了更多的（从新）认证工作，可能会使他们更慢地承受咱们的更新和平安修复。
不过，CRA 中也有很多可行的办法，而且咱们晓得这些办法很可能会无效；在开源组织（如 ASF）层面也是如此。
事实上，咱们明天曾经做到了大部分，例如对破绽报告进行良好的分流、负责任的披露、注册 CVE（常见破绽和危险）以及审慎应用版本号。在此基础上，咱们还履行了良好的治理，各我的项目都要向董事会报告，偶然也会有我的项目在时机成熟时被转移到阁楼上_（译者注：束之高阁，意即我的项目进入服役或退休状态）_。
问题更多的在于，CRA 还提出了一系列要求，这些要求要么威逼到开源奉献或咱们的私有（或共享）畛域十分软弱的 “ 双赢 “ 场面，要么违反行业良好实际，要么基本不可能实现，也就是说，它试图将开源私有畛域与商业畛域等同看待。
事实上，美国仿佛曾经意识到了这一点，并正在与美国国家标准与技术研究院（NIST）单干，与业界一起记录这些现有的良好实际。
在某种程度上，美国仿佛更靠近于历史上由工程师和集体主导的 ACME 程序，该程序产生了锅炉标准；而欧盟仿佛更偏向于询问制造商，而不是专家。
互联网如此绕开这样的问题
“ 互联网将审查制度这一运行良好的机制（就如同房间里的一头大象的确存在）视为故障，并绕开它 ”（约翰 - 佩里 - 巴洛）。
| 译者注：房间里还有一头大象：意指“一个问题因太过于宏大或麻烦，导致没有人违心去碰”
上世纪 90 年代，当美国试图对加密软件进行监管时，咱们看到了这一机制的作用。只有 “ 达到进口标准要求”的加密软件技术能力来到美国。这导致大量加密行业和人员从物理上和法律上来到美国，并将该行业从美国转移到欧洲。在那里，公司只需将其代码输出美国，或从欧洲将其运往世界各地，不受美国进口管理局（BXA: The Bureau of Export Administration）规定的限度。二十多年后，这种状况才得以正常化（咱们在 ASF 中依然能够看到这种状况的残余）。
因而，ASF 还须要思考到咱们的社区可能会因 CRA 而决裂的危险。尤其是当咱们分布在欧洲各国的 ASF 我的项目社区不能调动足够的能力和实力来在 ASF 我的项目上施行 CRA。
口头时间表
2023 年 7 月 17 日这一周将举办工业、钻研和能源委员会（ITRE）投票。这是一个向欧洲议会成员倡议如何投票的议会委员会。投票完结后，2023 年冬季闭会后可能将开始三方探讨（Trialogues：欧洲议会、欧盟理事会、欧盟委员会）。如果三巨头达成共识（目前看来如此），这一过程最早可能在 12 月完结。
因而，在很短的工夫内，人们能够分割工业、钻研和环境部的欧洲议会议员。一般来说，如果这些信息是礼貌性的，由具备肯定政治或经济位置的一方（如中小型企业组织的首席执行官）发送，并且合乎当地的环境，如用当地语言发送给外国的议员，并留神他们所代表的政党的政治立场，则会有所帮忙。因为对开源的监管是无意为之，而且《CRA：网络韧性法案》中也有很多具备常识性的良好（开源）实际：目前的期望值是，咱们（开源社区）曾经有所斩获并且曾经过了要求全面例外的阶段。
ASF 将专一于欧盟理事会版本（因为其文本通常在三方探讨中 “ 胜出 ”，而且当初比 ITRE 的共识文本更好一些）。为此，咱们须要您的帮忙：特地是，如果您能帮忙咱们让贵国较具规模的中小企业高管参加进来，并违心在国家层面解释 CRA 将造成的负面影响_（请分割 ASF 公共事务副总裁；dirkx@apache@org）_。
| 译者注：最初的几个段落的诉求看起来比拟费解，其实就是说”开源尚未胜利，同志仍需致力”！
【英文原文】
作者：Dirk-Willem van Gulik，Apache 软件基金会公共事务副总裁
译者：刘天栋 Ted
开源雨林 围绕 开源通识、开源应用、开源奉献 三大方面构建常识体系，愿把长期积攒的教训系统化分享给企业，在 团队、机制、我的项目 三方面提供单干，推动各企业更高效地应用开源、奉献开源，晋升全行业开源技术与利用程度。
开源雨林的内容已开源，并托管在 https://github.com/opensource-rainforest/osr，欢送通过 Pull Request 的模式奉献内容，通过 Issue 的模式展开讨论，独特保护开源雨林的内容。
如果您有新的想法，欢送退出开源雨林交换群，一起探讨。小助手微信：osrainforest（增加时请备注“交换群”）
