TLDR（如果觉得本文太长者，可以只看摘要）
包括开源软件在内的软件正在受到全世界的监管。这篇冗长的博文解释了欧盟《网络韧性法案》的背景、优点、缺陷以及对开源软件可能产生的负面影响。此外，它还解释了该法案在欧盟系统中的复杂流程，以帮助人们了解时间表和如何推动改变。
Software, including open source, is becoming regulated the world over. This lengthy blog post explains the background to the Cyber Resilience Act in the European Union, what is good, its flaws and the likely negative impact on open source. And it also explains the arcane process by which it moves through the EU system, to help understand the timeline and how to make a change.
| 译者注：欧盟《网络韧性法案》https://www.european-cyber-resilience-act.com/
如果您需要更多的口头介绍，Eclipse 的 Mike Milinkovich 提供了一个非常新颖、清晰的演示，涵盖了相同的内容。如果您更喜欢简短的行动呼吁，那么不妨试试 GitHub、CNLL（法语内容）、Linux 基金会或更广泛的行业响应。
If you are looking for a more verbal introduction – Mike Milinkovich at Eclipse gave a very up-to-date and lucid presentation that covers the same ground. If you are more into short calls to action – then try GitHub, CNLL (in French), the Linux Foundation, or the more comprehensive response of the wider industry.
| 译者注：
一个非常新颖、清晰的演示 Update on the European Cyber Resilience Act：https://www.youtube.com/watch?v=AmsM5_5QO5A行动呼吁：GitHub、Linux 基金会
GitHub：https://github.blog/2023-07-12-no-cyber-resilience-without-open-source-sustainability/
Linux 基金会：https://linuxfoundation.eu/cyber-resilience-act
行业响应：https://ccianet.org/library/joint-recommendations-for-a-feasible-cyber-resilience-act/
虽然与其他大型行业和部门相比，IT 行业的规模还很小，但在过去的几十年里，它已成为社会的关键。现在，在新闻中经常可以看到软件和 IT 行业的大型事件。而且，更常见的是由某种灾难引发的故事：配置错误、漏洞或显然太容易 "进入" 的犯罪分子和国家行为。现在，不良的 IT 实践也影响到了主要行业，从能源运输、制造业到金融业，再到民主进程和治理良好的政府。
Although the IT industry is still small compared to other large industries and sectors, over the past decades it has become crucial to society. It is now common to see large events in the software and IT industry in the news. And, more often than not, it’s a story triggered by some sort of disaster: a misconfiguration, bug, or criminals and state actors that “got in” apparently too easily. With poor IT practices now also affecting the major industries, from energy transport to manufacturing to finance to democratic processes and good government.
正因为如此，社会和各种管理机构当然也注意到了这一点，因此，世界各地都在制定各种软件管理条例和立法。
Because of this, societies and various governing bodies have certainly taken notice and, as a result, around the world, all sorts of software regulation and legislation are being prepared.
以工程史为例，这种监管是再正常不过的结果。19 世纪末，机械行业取得了惊人的发展，这在一定程度上要归功于蒸汽机的发明。但随着这一行业的发展，蒸汽锅炉爆炸事故也随之增多。这些事故通常会夷平半个城镇。
Using engineering history as an example, such regulation is a perfectly normal result. In the late 1800s, the mechanical industry saw incredible growth thanks, in part, to the invention of the steam engine. But as this industry grew; so did the number of accidents with exploding steam boilers. Often flattening half of a given town.
1865 年，蒸汽船 Sultana 号发生爆炸，造成 1,167 人丧生。因此，美国锅炉制造商协会（以下简称 ABMA）成立，开始对该行业进行自律。经过数百次此类爆炸，以及 1905 年在波士顿一家鞋厂发生的一次代价特别高昂的爆炸，政府才开始采取干预政策。
After the explosion of the steamship Sultana in 1865, which saw 1,167 people killed, pressure was placed on the industry in the United States. This resulted in the creation of the American Boiler Manufacturers Association (ABMA) to start self-regulation of the industry. It took several hundreds of such explosions; and a particularly expensive one in 1905 at a Boston shoe factory for the intervention of government policies to come into being.
有趣的是，应对 1905 年灾难的并不是 ABMA，而是由五名工程师组成的小组，他们是美国机械工程师协会的成员，这是一个由个人而非公司组成的专业组织。这些人撰写了第一版《锅炉规范》，随后不久便得到了马萨诸塞州立法机构的认可。
Interestingly, it was not ABMA that responded to the 1905 disaster, but a group of five engineers, members of the American Society of Mechanical Engineers, a professional organization of individuals, rather than companies. These people wrote the first version of the Boiler Code that subsequently was endorsed by the Massachusetts legislature shortly thereafter.
从很多方面来说，这些工程师、这些个人志愿者 "自救" 来解决问题；就像我们今天在 ASF 的开源以及 IETF（互联网工程任务组）在制定互联网标准中所做的一样。是专业团体解决了问题：而不是他们的雇主、行业或美国锅炉制造商协会。
In many ways, these engineers, these individual volunteers “scratched an itch” to solve the problem; much like we do today in Open Source at the ASF as well as, for example, the Internet Engineering Task Force (which sets the standards for the Internet). It was the professional community which solved the problem: Not their employers,the industry, or the ABMA.
目前，世界各地几乎都有大量立法正在进行中；美国和欧盟稍稍领先（各国决策者之间也进行了大量协调）。
There is currently a lot of legislation in process in almost all parts of the world; with the US and the European Union slightly ahead (and with plenty of coordination between the policy makers of the various countries).
在这篇博文中，我们暂时只关注其中一项：欧盟的《CRA - 网络复原力法案》，因为从时间轴的角度来看，这是 "先行者"。
In this blog post we’ll focus on just one for now: the Cyber Resilience Act (CRA) in the EU, as that is “first” from a timeline perspective.
这绝不是最重要的立法。在 ASF，我们认为欧盟的《PLD - 产品责任指令 Product Liability Directive》（引入了对软件 "严格课责" 的规范）、美国的第 14028 号行政命令 "提高国家网络安全” 和 "2023 年开源软件安全法案"（美国）可能会产生更大的影响。
It is by no means the most important piece of legislation. At the ASF we gauge the impact of the EU’s Product Liability Directive (introducing “strict-liability” to software), the US Executive Order 14028, “Improving the Nation’s Cybersecurity” and the “Securing Open Source Software Act of 2023“ (US), as perhaps having an even larger impact.
| 译者注：
美国的第 14028 号行政命令 "提高国家网络安全：
https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
2023 年开源软件安全法案"（美国） ：
https://www.congress.gov/bill/118th-congress/senate-bill/917/text
这一点可能尤为正确，因为美国立法可以通过国家标准与技术研究院（NIST）为本国制定标准，而国家标准与技术研究院制定标准的速度通常快于欧盟制定标准的速度（因此很可能制定出全球标准）。
This may be especially true as the US legislation could set standards for that nation through the National Institute of Standards and Technology (NIST), which is typically faster than standards developed by the EU (and thus may well set the global standard).
在日常实践中，软件开发人员很少需要考虑监管问题（除非 TA 们从事某些特定领域的工作，如医疗、航空航天、金融或核能）。开源许可证（在我们的下游）和提交者许可证协议（在我们的上游）往往有范围广泛的免责声明。我们通常将代码等同于编撰成文的知识或言论。
In day-to-day practice, software developers rarely need to consider regulation (unless you work in some specific field, say medical, aerospace, finance, or nuclear). Open Source licenses (on our downstream outflow) and committer license agreements (on our instream) tend to have far-ranging disclaimers. And we often equate code to codified knowledge or speech.
但在实际操作中，事情并非如此简单。例如，在 ASF，我们多年来一直需要提交一些文件，让美国工业与安全局（BIS）知道我们提供下载的加密代码的确切位置 [https://infra.apache.org/crypto.html]。由 ASF 发布的代码不能出口（或再出口）到特定目的地或特定名单上的人。
However, in actual practice, things are not that simple. For example, here at the ASF we’ve had, over the years, the need to file some paperwork to let the Bureau of Industry and Security (BIS) in the United States know the exact location of cryptographic code that we make available for download [https://infra.apache.org/crypto.html]. And code distributed by the ASF can not be exported (or re-exported) to certain destinations or to people on a certain list.
| 译者注：特定目的地或特定名单上的人 - 出口 ASF 产品的规范：https://www.apache.org/licenses/exports/
在欧盟，《CRA - 网络韧性法案》目前正在法律制定过程中（将于 2023 年 7 月 19 日进行关键投票）。该法案将适用于欧盟的大量软件（以及带有嵌入式软件的硬件）。该法规的初衷是好的（也可以说是早该如此）：使软件更加安全。
In the EU the Cyber Resilience Act (CRA) is now making its way through the law-making processes (and due for a key vote on July 19, 2023). This act will apply to a wide swath of software (and hardware with embedded software) in the EU. The intent of this regulation is good (and arguably long overdue): to make software much more secure.
| 译者注：欧盟《网络韧性法案》https://www.european-cyber-resilience-act.com/，已经投票通过，但是引发了许多反对意见，后续发展值得观察。
该法案试图通过多种方式来实现这一目标。最重要的是，CRA 将要求市场在设计、构建、发行和维护软件时对安全性采用行业良好实践。在最基本的层面上，CRA 正式确定了 ASF 现行的基本政策：管理您的错误，接受、分流并修复安全漏洞。这也是通过将其与良好的治理或实践相结合来实现的；例如，在适当的时候注册 CVE（Common Vulnerability and Exposures 常见漏洞和风险）、编写发行版说明和进行适当的版本管理（平心而论，其中一些我们应该进一步正规化和改进）。
The act attempts to do this in a number of ways. The most important is that the CRA will require the market to apply industry good practices to security when designing, building, releasing, and maintaining software. At a most basic level, the CRA formalizes what is by and large already policy at the ASF: manage your bugs and accept, triage, and fix security vulnerabilities. This is also done by pairing this with good governance or practices; such as registering CVEs when appropriate, doing release notes, and decent versioning (and in fairness, some of those we should further formalize and improve).
| 译者注：ASF 现行的基本政策
https://www.apache.org/security/committers.html
CRA 还将试图确保欧洲市场上的所有软件都能达到某种最低的安全级别，具体做法是在 CE 符合性声明中进行相当简单的自我认证。或者，对于更关键的软件，如防火墙或安全加密密钥飞地，由外部、受监管的指定机构进行实际的 "真正 "认证和审计。CRA 还将定义一系列流程，以监控市场的合规性。
The CRA will also attempt to ensure that any and all software in the European market meets some sort of minimum level of security by fairly simple self-certification documented in a CE conformity declaration. Or, for software that is more critical, such as a firewall or a secure cryptographic key enclave, an actual “real” certification and audit by an external, regulated, and notified body. The CRA will also define a number of processes to monitor compliance in the market.
| 译者注：
“CE” 标志是一种产品安全认证标志（即只限于产品不危及人类、动物和货品的安全方面的基本安全要求，而不是一般质量要求），被视为制造商打开并进入欧洲市场的护照。CE 代表欧洲统一（CONFORMITE EUROPEENNE）。
安全加密密钥飞地：是指硬件的处理器和内存的受保护部分。
欧盟政策制定者认识到，这些 "行业最佳实践" 还没有得到很好的定义（在整个行业内，ASF 的安全实践是例外，而不是一体适用的规则）-- 许多 CRA 都依赖于国际标准组织来制定标准，人们可以用这些标准来审核自己的项目（自我认证），或者外部审核人员也可以使用这些标准。
EU policymakers recognize that these “industry best practices” are not yet well defined (within the industry in general, the ASF is the exception, not the rule) — and a lot of the CRA relies on international standards organizations to create the standards one can use to audit one’s project (self-certification) or that can be used by external auditors.
此外，人们还期望重大漏洞能得到特殊处理，并尽早报告。稍后再详述。
There is also an expectation that significant vulnerabilities will get special treatment – and that these will get reported early. More on that later
如果你关注过各种博客和公开信，开源基金会一直在关注如何帮助完善 CRA 的现有措辞，使开源软件获得 "豁免"；也就是说，只有当代码离开了开源公域（译者注：Commons 亦可翻译为公共资源）时，CRA 才适用；然后继续适用于整个商业供应链。同时，当某些东西（如安全修复）再次进入公域时，《CRA - 网络韧性法案》也不再适用。
If you’ve followed the various blogs and letters, there has been a lot of focus by open source foundations to help refine the current wording of the CRA to make open source software “exempt”; i.e, have the CRA apply only when the code leaves the open source commons; and then continue to apply throughout the entire commercial supply chain. And also to stop the CRA from applying when something, e.g. a security fix, comes back and enters the commons again.
| 译者注：
博客：https://blog.opensource.org/what-is-the-cyber-resilience-act-and-why-its-important-for-open-source/
公开信：https://blog.opensource.org/the-ultimate-list-of-reactions-to-the-cyber-resilience-act/
总的来说，这些开源基金会或是社区的努力并不成功。《CRA - 网络韧性法案》历次迭代的文件版本都有很大变化，但不是围绕着以上所述开源基金会或是社区关切的具体政策问题。
By and large, these efforts have not been successful. Successive versions of the documents changed considerably – but not around this specific policy issue.
为了了解原因，ASF 的代表（连同 OpenSSL）于 7 月 7 日直接与欧盟进行了对话，这是我们第一次真正能够与立法者进行有意义的互动。
To understand why, representatives of the ASF (together with OpenSSL), spoke directly to the EU on July 7, the first time we actually were able to interact with lawmakers in a meaningful way.
从这次谈话中，我们了解到，政策制定者非常清楚，开源对 IT 行业至关重要，无论是对 "生产 "还是创新都是如此。正因为如此，他们希望避免杀鸡取卵。
From this conversation, we learned that the policy makers are very aware that open source is crucial to the IT industry — both for “production” and innovation. And, because of this, they want to avoid killing the goose that lays the golden eggs.
| 译者注：政策制定者非常清楚
https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-impact-assessment
另一方面，欧盟立法者也意识到，开源通常占典型欧洲中小企业（SME）运营或获得许可的软件堆栈的 95% 或更多。而中小型企业作为将其推向市场的一方，要对整个软件栈负责。
On the other hand, EU lawmakers also realize that open source is often 95% or more of the software stack on which a typical European Small and Medium Enterprise (SME) operates or is licensed. And it is that entire stack which the SME, as the party that places it on the market, is liable for.
据我们了解，政策制定者认为这些流程改进（和（自我）认证）的成本很高；大约会增加 25% 的管理费用。这是基于最近在医疗领域引入的类似法规和 CRA 影响评估（任何欧盟法律提案都需要将其可能产生的经济影响记录在案）。
From what we understand, policymakers assume that these process improvements (and (self) certification) are costly; on the order of 25% more in cost overhead. This is based on recently introduced similar regulations in the medical sector and the CRA impact assessment (any EU law proposed needs to have its likely impact in economic terms documented).
因此，从中小型企业的整个堆栈（即 95% 的开源代码和 5% 的私家秘方）来看，对于大多数欧洲中小型企业来说，在全部 100% 的代码上额外付出的努力将是其工程努力的数倍，因此是不可行的。而欧盟的想法是，认证他们在开源堆栈基础上构建的 5% 或 10% 的代码要容易得多。
So looking at the whole stack of an SME (i.e., 95% open source, 5% secret sauce), then for most European SMEs this extra effort over the full 100% would be several times their engineering effort and hence would not be feasible. Whereas, the thinking is at the EU, certifying the 5 or 10% of the code they build on top of the open source stack is a lot more achievable.
因此，政策制定者 (1) 向 ASF 明确表示，他们打算将 CRA 适用于开源基金会。目前，开放源代码的例外情况要么是纯粹的业余爱好者，要么是不在现实生活中使用的代码，要么是诸如镜像和软件包仓库（如 NPM 或 Maven Central）之类的东西。他们的做法是，如果软件在商业环境中的任何地方使用，就推定其具有商业意图。
So, for this reason, the policymakers (1) have made it crystal clear to the ASF that they intend to have the CRA apply to open-source foundations. The current exceptions for open source are either for pure hobbyists, code that is not used in real life, or for things such as mirrors and package repositories like NPM or Maven Central. The way they do this is a presumption of commercial intent if the software is used anywhere in a commercial environment.
欧盟的一项立法通常由欧盟委员会起草（该委员会还负责准备 ”影响研究” 等工作）。然后在议会进行讨论。讨论一般在较小的委员会中进行。这些委员会编写报告，最终立法提交议会全体会议表决(2)。
A piece of EU legislation is generally drafted by the European Commission (who also prepares things such as impact studies). It is then discussed in Parliament. This is generally done in smaller committees. These committees prepare reports and ultimately legislation then goes to a plenary session of the parliament for voting(2).
CRA 的主要委员会是 LIBE、IMCO 和 ITRE。
For the CRA the main committees are LIBE, IMCO, and ITRE.
第一个委员会是公民自由、司法和内政委员会（LIBE），负责讨论 "言论自由 "等问题，但该委员会拒绝提交报告。接下来，内部市场和消费者保护委员会（IMCO）研究了什么对消费者和内部市场是重要的。该委员会编写了一份报告，并提交给了工业、研究和能源委员会（ITRE）。
The first, LIBE (Committee on Civil Liberties, Justice and Home Affairs) — where things such as `free speech’ are discussed — declined to produce a report. Next IMCO, the Committee on the Internal Market and Consumer Protection, looked at what is important for the consumers and the internal market. It produced a report that was fed into ITRE.
此后，工业、研究和能源委员会（ITRE）编制了一份协商一致的文件，预计将于 20230717 这一周进行公开讨论，并获得委员会的最终批准（在获得同意的情况下，委员会一般不进行表决）。
ITRE, the Committee on Industry, Research and Energy, has since produced a consensus document that is expected to be discussed publicly the week of 20230717 and gets its final committee endorsement (they generally do not vote on things when there is consent).
| 译者注：20230717 这一周进行公开讨论
https://www.europarl.europa.eu/committees/en/itre/home/highlights
一旦这项工作完成，提案将提交欧洲议会表决。根据当时的争议或共识程度，可能会、也可能不会进行讨论和自由表决。
Once this completes, the proposal goes through the European Parliament for voting. Depending on how controversial or consensual it is at that time, there may, or may not, be discussion and a free vote.
| 译者注：工作完成https://www.europarl.europa.eu/legislative-train/theme-a-europe-fit-for-the-digital-age/file-european-cyber-resilience-act
与此同时，欧盟的第三方--即欧盟理事会--也在准备其版本的法案。主要由各国的相关部长从本国的角度进行审议。然后，三个版本（欧盟委员会、议会和理事会）将在 "三方合议庭"（Trialogues）中进行闭门讨论，最后产生成为法律的最终版本。
In the meantime – the third party of the EU – the Council – also prepares its version of the Act. These are essentially the relevant ministers of each country that look at it from a national perspective. The three versions (EC, Parliament and Councils) are then discussed, behind closed doors, in the Trialogues – which then yields the final version that becomes law.
目前，据说立法过程中的所有各方都已达成了大致的共识--其中有两方与 ASF 分享了他们的观点，即不存在争议。此外，各种共识文件的副本也已泄露--因此我们知道它们之间的差距并不大，现在我们也可以开始对它们进行分析了。
Right now all parties in the lawmaking process are said to have reached a rough consensus – and two of them shared with the ASF their opinion that there is no controversy. Also, copies of the various consensus documents have leaked – so we know that they are not far apart, and we can now also start to analyze them.
目前的定义(3) 规定，《反垄断法》适用于 ASF、及其所有（志愿）开发人员以及我们的所有产出。而且，根据 ASF 与政策制定者的会谈了解，这是有意为之。
The current definitions(3) are such that the CRA applies to the ASF, all of its (volunteer) developers, and all our output. And, as the ASF understands from its meeting with policy makers, this was intentional.
对 CRA 的忧虑有很多，但对 ASF 社区来说，以下几个问题可能是最重要的。
There are quite a few concerns with the CRA; but the following are probably tops for the ASF community.
公域的概念与商业市场并无区别，它是一种全押模式：第一个问题是，《反垄断法》采取的是全有或全无的二分法。要么加入，要么退出。当你加入时，对你适用的基本上就是需要适用于出售给消费者的全套商业产品的内容。
No concept of a commons is distinct from the commercial market; it is an all-in approach: The first issue is that the CRA takes a binary all-or-nothing approach. You are either in or you are out. And when you are in – what is applied to you is, essentially, what needs to be applied to a full-blown commercial product that is sold to consumers.
虽然开放源码可能与此相近（如 Apache Netbeans 或 Apache Zeppelin，尽管没有实际商业产品出售），但开放源码一般不属于商业环境。相反，它可以作为共享知识或公共资源来管理。就像学术论文或参考蓝图一样。CRA 并不承认这一点--因此，CRA 完全适用于开源软件"（而不是仅仅适用 CRA 中在这种情况下可能有意义的要素--如良好的漏洞处理、版本控制和 “软件物料清单-SBOM”）。
While open source can be close to that (e.g., Apache Netbeans or Apache Zeppelin – albeit not sold) — open source generally is not part of that commercial setting. Instead, it may be managed as a piece of shared knowledge or a commons’. Much like for example academic papers or reference blueprints. The CRA does not acknowledge this – and hence applies itself in full’ (as opposed to for example just applying the elements of the CRA that could make sense in that context — such as good vulnerability handling, versioning and SBOMs).
除非开源项目具有 "完全分散的开发模式"，否则 CRA 将对其进行监管。然而，"公司" 雇员拥有贡献提交（commit）权的项目将不会被豁免（无论上游开源合作是否与其雇主的商业产品有任何或是毫无关系）。有些项目，如古老的 OpenSSL 项目，其模式甚至更为复杂。
The CRA would regulate open source projects unless they have “a fully decentralized development model.” However, a project where a “corporate” employee has commit rights would not be exempt (regardless, potentially, of the upstream collaboration having little or anything to do with their employer’s commercial product). And some projects, like the venerable OpenSSL project have an even more complex model.
| 译者注：OpenSSL 项目，其模式甚至更为复杂
https://www.openssl.org/blog/blog/2023/07/17/who-writes-openssl/
这颠覆了开源的双赢原则。如果禁止企业维护者，企业可能会放弃让其员工维护项目，从而损害开源创新生态系统，具有讽刺意味的是，这将破坏其韧性及其对经济/增长的巨大推动作用（根据欧盟影响评估，每年90亿欧元）。
This turns the win-wins of open source on its head. If corporate maintainers are banned, corporations may pull back from allowing their employees to maintain projects, harming the open source innovation ecosystem and, ironically, undermining its resilience and its significant economic/growth generator (9bn€ per year according to the EU impact assessment).
这也让人很难看出 ASF 社区中有谁会去做 ASF 可能被要求需要做的额外的（自我）认证工作。
It also makes it very hard to see who in the ASF community would do the extra (self) certification work that the ASF would need to do.
这样做的净效果实际上相当广泛。举一个 "序言(4)，10a "中的例子（这样的例子还有很多）：
The net effect for this is actually quite broad. To give an example from the “Recitals(4), 10a” (and there are many such examples):
同样，如果自由和开源项目的主要贡献者是受雇于商业实体的开发人员，而且这些开发人员或雇主可以控制代码库中接受哪些修改，则该项目一般应被视为具有商业性质。
Similarly, where the main contributors to free and open-source projects are developers employed by commercial entities and when such developers or the employer can exercise control as to which modifications are accepted in the code base, the project should generally be considered to be of a commercial nature.
在这里，这些贡献者与商业雇主之间缺乏交易关系的联结是个问题。例如，开发者可以是受雇于商业航空公司（即商业实体）的飞行员，利用业余时间为开源做出贡献：这部分政策将使这种贡献具有 "商业性"。此外，在 ASF，主要贡献者（提交者）当然可以对进入代码库的内容进行一定程度的控制(5)。
Here the lack of a transactional connection between those contributors and the commercial employers is problematic. For example, the developer could be an airline pilot employed by a commercial airline (i.e. a commercial entity) – who contributes to open source in their spare time: this part of the policy would make that contribution ‘commercial’. Also, at the ASF, the main contributors (committers) are of course able to exercise a level of control over what goes into a codebase(5).
| 译者注：意即与开源没有半毛钱关系的雇主航空公司也将遭受池鱼之殃，而被列入监管范围内。
更糟糕的是，受影响最严重的开源组织类型也正是那些如今往往拥有非常成熟的安全流程的组织，它们负责任地分流、修复和披露漏洞，并提供与之相匹配的 CVE（常见漏洞和风险）。一般来说，CRA 需要在下游，即将产品投放到市场上的公司中推动重大改进。而现在却有可能出现相反的情况。
And what makes matters worse is that the type of open source organizations most affected are also exactly those that, today, tend to have very mature security processes, with vulnerabilities getting triaged, fixed, and disclosed responsibly with CVEs to match. While it generally is further downstream; with the companies that place the product on the market — that the CRA needs to drive significant improvement. It now risks doing the reverse.
CRA 影响了完全由志愿者领导和驱动的项目（如 ASF），在这些独立自主的 ASF 项目中，没有任何公司能对产品的操作和发布有任何影响。而 CRA 将对任何商业实体的员工拥有贡献提交（Commit）权的项目都会受到影响。
The CRA affects projects that are entirely volunteer-led and -driven (e.g. such as at the ASF) where no one company has any influence on what the product does and releases. Any project where an employee of a commercial entity has commit rights is affected.
这就带来了一个问题：无论是商业公司还是开源项目，都需要对哪些提交者可以修改代码、接受哪些资助以及接受哪些补丁等问题更加谨慎。
This leads to the problem: that both commercial companies and open-source projects will need to be much more careful as to what committers can work on code, what funding they take, and what patches they can accept.
在 CRA 认证中，有一个很强的假设，即模块的（自我）认证是 "传递性" 的；也就是说，如果你用经过认证的模块构建了一些东西，你只需要认证你所做的 "额外 "的一些事情。不幸的是，这在一般情况下是不正确的；认证通常在很大程度上是要表明你（作为最终承担责任的组织）是如何确保所交付的东西适合你在客户的特定环境下交付的目的的。开源组织在自我认证其构建的软件模块时，并无法提供 "上游” 信息。
In the certification there is the strong assumption that (self) certification of modules is transitive’; i.e. that if you build something from certified modules, you only have to certify the few extra things you have done. Unfortunately, this is not true in general; certification is generally very much about showing how, as the final, liable organization, you have made sure that what you delivered is fit for the purpose you delivered it for the specific setting at your customer. Information that is not available `upstream’ at the open source organizations that self-certified building blocks.
认证的核心是确保所发布的信息对其预期目的具有适当的安全性。具体地说，就是在设计时就考虑到安全问题，规划出威胁行为者、载体和风险。然后根据风险做出合理的工程妥协。
The core of certification is to ascertain that what you release is suitably secure for its intended purpose. Specifically, you have done your security by design and mapped out your threat actors, vectors, and risks. And then made reasonable engineering compromises based on risk.
遗憾的是，在开源领域，我们往往不知道我们的软件会被如何使用。而且，正如我们在过去十年中学到的（困而知之），对于我们良好治理共享资源来说，关键是我们不能在许可证中（译者注：对如何使用开源软件）进行歧视或限制（事实上，这也是开源定义的一部分）。
Unfortunately in open source, we often have no idea how our software is going to be used. And, as we’ve learned (the hard way) over the past decade, it is key for the good governance of our shared commons, that we do not discriminate or otherwise limit our licenses (in fact – that is part of the open source definition).
| 译者注：开源定义 Open Source Definition 是 OSI 制定关于开源许可协议的 10 条基本原则。违反这些原则的许可协议，不得自称为 ”开源” 许可协议。开源定义：https://zh.wikipedia.org/zh-cn/%E5%BC%80%E6%BA%90%E5%AE%9A%E4%B9%89
有些义务几乎是不可能履行的：例如，有一项义务是 "提供没有已知可利用漏洞的产品"。这几乎是一个不可能设定的标准；尤其是开源软件的作者既不知道也无法控制他们的代码是如何被整合到下游的。
Some of the obligations are virtually impossible to meet: for example, there is an obligation to “deliver a product without known exploitable vulnerabilities”. This is an almost impossible bar to set; especially as open-source authors, neither know, nor have control over, how their code is integrated downstream.
下一个问题与标准有关。CRA 提到了大量 "待编写 "的国际标准（一般认为由 CEN-CENELEC 制定）。一般来说，IT 行业，尤其是开源，在与这些标准机构合作方面并没有很好的记录（也包含了 ASF），部分原因是几乎所有关键的互联网标准都由 IETF 和 W3C 维护。事实上，这些标准组织的章程不允许开源组织以有意义的方式成为其成员的情况并不少见。
The next problem is around standards. The CRA refers to a large number of `to be written’ international standards (generally assumed to be created at CEN-CENELEC). The IT industry in general, and open source in particular, does not have a great track record of working with these standard bodies — in part as almost all key internet standards (also at the ASF) are maintained at the IETF and W3C. In fact, it is not uncommon for the bylaws of these standards organizations to not allow open source organizations to be members in a meaningful way.
| 译者注：不允许开源组织以有意义的方式成为其成员https://blog.opensource.org/another-issue-with-the-cyber-resilience-act-european-standards-bodies-are-inaccessible-to-open-source-projects/
CRA 要求在漏洞修复前，以小时为单位的时限内向 ENISA（欧盟机构）披露严重的未修补漏洞和被利用漏洞。这与行业最佳实践--负责任地披露修复和（变通的）解决办法--背道而驰。
The CRA requires the disclosure of serious unpatched and exploited vulnerabilities to ENISA (an EU institution) within a timeline measured in hours before they are fixed. This is opposed to what is industry best practice — responsible disclosure of the fix and workaround.
而且，这种过早的报道不仅会分散发布修复信息的注意力，对于国际社会来说，还很容易触犯其他国家坚持要相同信息的规定，或者更糟糕的是，禁止分享此类信息。这就破坏了开源所依赖的公平公正的报告的文化核心。
And not only does this too-early reporting distract from getting a fix out – for international communities it is easy to run foul of other countries insisting on the same information or, worse, prohibiting such sharing. Thus breaking the very core of the fair and equitable reporting culture that open source relies on.
而且，只有当这些信息被广泛共享时，才会对 ENISA 有用--因此，各组织理应选择谨慎、全球 "公平 "的方案，采取简单易行的方法：确保永远不会听说这些问题。或者，反其道而行之，在（第一个）报告截止日期结束之前，即在问题得到解决之前，将问题公之于众。
And, as this information is only useful to ENISA when it is then widely shared — it is rational for organizations to choose the prudent, globally ‘fair’ option and take the easy path out: ensure you never hear about them. Or, the opposite, simply makes things public right before your (first) reporting deadline rolls over, i.e., before they are fixed.
| 译者注：意即在问题解决前，不对外公布；或是一有问题，立即全球公布。而不是优先将问题只通知某些特定机构，如欧盟的 ENISA。
因此，这又是一个例子，说明 CRA 虽然用心良苦，但最终可能适得其反。
So this is yet another example where, with all its good intentions, the CRA may end up accomplishing the exact opposite.
纵观欧洲目前的 IT 行业，我们可以发现，造成 IT 行业安全状况不佳的根本原因通常并不是开源（尤其是来自 ASF 这样的组织）。事实上恰恰相反。
Looking at the IT industry in Europe now, one can observe that it is generally not open source (especially coming from the likes of the ASF) which is the root cause for the sorry state of security in the IT industry. Quite the contrary.
与此相反，欧洲的大多数中小型企业很少更新他们所依赖的系统，通常也不擅长处理安全问题报告。而 ASF 的（定期）更新为他们带来了更多的（重新）认证工作，可能会使他们更慢地接受我们的更新和安全修复。
While, in contrast, most SMEs in Europe rarely update their dependencies and are generally not well-versed in dealing with security issue reports. And (regular) updates at the ASF creating even more (re)certification work for them may make them even slower to pick up on our updates and security fixes.
不过，CRA 中也有很多可行的方法，而且我们知道这些方法很可能会有效；在开源组织（如 ASF）层面也是如此。
However, there is also a lot in the CRA that is feasible, and where we know that it is likely going to be effective; also at the level of open source organizations such as the ASF.
事实上，我们今天已经做到了大部分，例如对漏洞报告进行良好的分流、负责任的披露、注册 CVE（常见漏洞和风险）以及谨慎使用版本号。在此基础上，我们还实行了良好的治理，各项目都要向董事会报告，偶尔也会有项目在时机成熟时被转移到阁楼上（译者注：束之高阁，意即项目进入退役或退休状态）。
In fact, we do most of this already today, such as good triage of vulnerability reports, responsible disclosure, registering CVEs, and being careful with version numbers. And to this we apply good governance, with board reporting by the projects and the occasional project that gets moved to the Attic when their time has come.
问题更多的在于，CRA 还提出了一系列要求，这些要求要么威胁到开源贡献或我们的公有（或共享）领域非常脆弱的 "双赢 "局面，要么违背行业良好实践，要么根本不可能实现，也就是说，它试图将开源公有领域与商业领域等同对待。
The problem is more that the CRA also piles on a whole range of requirements that are either threatening the very fragile “win-win” of open source contributions or our commons, which go against industry good practices or are downright impossible, i.e. it tries to treat the open source commons identical to the commercial sector.
事实上，美国似乎已经意识到了这一点，并正在与美国国家标准与技术研究院（NIST）合作，与业界一起记录这些现有的良好实践。
In fact, the USA appears to realize this and is taking the path with NIST to work with the industry to document these existing good practices.
在某种程度上，美国似乎更接近于历史上由工程师和个人主导的 ACME 程序，该程序产生了锅炉规范；而欧盟似乎更倾向于询问制造商，而不是专家。
And to some extent – it appears that the US is closer to the historical engineer and individual-led ACME process that produced the Boiler code, while the EU seems to be more on the path of asking manufacturers, rather than experts.
"互联网将审查制度这一运转良好的机制（就如同房间里的一头大象确实存在）视为故障，并绕开它"（约翰-佩里-巴洛）。
There is of course an elephant in the room: the well-oiled mechanism that “The internet treats censorship as a malfunction and routes around it” (John Perry Barlow).
| 译者注：房间里还有一头大象：意指 “一个问题因太过于庞大或麻烦，导致没有人愿意去碰”
上世纪 90 年代，当美国试图对加密软件进行监管时，我们看到了这一机制的作用。只有 "达到出口规范要求” 的加密软件技术才能离开美国。这导致大量加密行业和人员从物理上和法律上离开美国，并将该行业从美国转移到欧洲。在那里，公司只需将其代码输入美国，或从欧洲将其运往世界各地，不受美国出口管理局（BXA: The Bureau of Export Administration）规则的限制。二十多年后，这种情况才得以正常化（我们在 ASF 中仍然可以看到这种情况的残余）。
We saw that mechanism come into action in the 90s when the USA tried to regulate cryptographic software. And only “export strength” cryptography could leave the US. That led to a lot of cryptographic industry and staff leaving the US, physically and legally; and a move of that industry from the USA to Europe. From there the companies would then simply import their code back into the USA or ship it from Europe, unencumbered by USA BXA rules, to the rest of the world. It took over two decades for this to normalize (and we still have the vestiges of that at the ASF)
| 译者注：ASF 中仍然可以看到这种情况的残余https://www.apache.org/licenses/exports/
因此，ASF 还需要考虑到我们的社区可能会因 CRA 而分裂的风险。尤其是当我们散布在欧洲各国的 ASF 项目社区不能调动足够的能力和实力来在 ASF 项目上实施 CRA。
So, as the ASF, we also need to factor in the risk that our communities may split on the CRA. Especially if our European communities are not able to muster enough capacity and capability to implement the CRA at the ASF.
2023 年 7 月 17 日这一周将举行工业、研究和能源委员会（ITRE）投票。这是一个向欧洲议会成员建议如何投票的议会委员会。投票结束后，2023 年夏季休会后可能将开始三方讨论（Trialogues：欧洲议会、欧盟理事会、欧盟委员会）。如果三巨头达成共识（目前看来如此），这一进程最早可能在 12 月结束。
The week of July 17, 2023 will see the ITRE vote. This is the parliamentary committee that recommends to the Members of the European Parliament how to vote. Once that is done, the Trialogues will likely start after the Summer 2023 recess. If the consensus between the three powers holders (as they appear for now) – this process may conclude as early as December.
因此，在很短的时间内，人们可以联系工业、研究和环境部的欧洲议会议员。一般来说，如果这些信息是礼貌性的，由具有一定政治或经济地位的一方（如中小型企业组织的首席执行官）发送，并且符合当地的环境，如用当地语言发送给本国的议员，并注意他们所代表的政党的政治立场，则会有所帮助。由于对开源的监管是有意为之，而且《CRA：网络韧性法案》中也有很多具备常识性的良好（开源）实践：目前的期望值是，我们（开源社区）已经有所斩获并且已经过了要求全面例外的阶段。
So, in the very short term, one can reach out to the MEPs of ITRE. It generally helps if these messages are polite, sent by a party with some political or economic standing (e.g. the CEO, a SME organization) and are tuned to your local setting, such as to a parliamentarian of your own country in your own local language, and mindful of the political position of the party they represent. As the regulation of open source is intentional, and there are also a lot of common sense, good (open source) practices, in the CRA: the expectation is that we are past the point where asking for a blanket exception is productive.
| 译者注：工业、研究和环境部的欧洲议会议员
https://www.europarl.europa.eu/committees/en/itre/home/members
ASF 将专注于欧盟理事会版本（因为其文本通常在三方讨论中 "胜出"，而且现在比 ITRE 的共识文本更好一些）。为此，我们需要您的帮助：特别是，如果您能帮助我们让贵国较具规模的中小企业高管参与进来，并愿意在国家层面解释 CRA 将造成的负面影响（请联系 ASF 公共事务副总裁；dirkx@apache@org）。
At the ASF we expect to focus on the Council version (as its text generally `wins’ and right now is a bit better than the ITRE consensus text). For this we can use your help: in particular, if you can help us get the executives of larger SMEs in your country engaged and willing to explain the impact at a national level (just contact the VP of Public Affairs; dirkx@apache@org).
| 译者注：最后的几个段落的诉求看起来比较隐晦，其实就是说 ”开源尚未成功，同志仍需努力”！
转载自 | 开源雨林
编辑 | 王军
相关阅读 | Related Reading
波波的 CommunityOverCode Asia 2023 办/参会感想
COSCon'23 开源市集：共赴一场草坪上的开源派对
开源社简介
开源社成立于 2014 年，是由志愿贡献于开源事业的个人成员，依 “贡献、共识、共治” 原则所组成，始终维持厂商中立、公益、非营利的特点，是最早以 “开源治理、国际接轨、社区发展、项目孵化” 为使命的开源社区联合体。开源社积极与支持开源的社区、企业以及政府相关单位紧密合作，以 “立足中国、贡献全球” 为愿景，旨在共创健康可持续发展的开源生态，推动中国开源社区成为全球开源体系的积极参与及贡献者。
2017 年，开源社转型为完全由个人成员组成，参照 ASF 等国际顶级开源基金会的治理模式运作。近九年来，链接了数万名开源人，集聚了上千名社区成员及志愿者、海内外数百位讲师，合作了数百家赞助、媒体、社区伙伴。
