Barry O’Donovan：CRA 身份要按产品判断

摘要

CRA 关注具体产品如何供给、由谁持续维护。Barry O’Donovan 认为，一个组织可以是免费版本的开源软件管理方（CRA 原文称 open-source software steward），同时是付费版本的制造商。
“非营利”这块招牌不能代替产品分类。运营商仍要逐产品登记依赖、漏洞联系人和补丁路径。

同一个项目可以免费发布开源版，也出售功能更多的版本。CRA 可能把它们放进不同角色。Barry O’Donovan 在 RIPE 93 给出的实践判断很直接：角色跟着产品走，而不是跟着组织名称走。

O’Donovan 是 INEX 的 IXP Manager 首席开发者。他在软件供应链演讲中提出了运营商真正要问的问题：交换中心或网络依赖开源软件时，能向上游项目要求哪些安全工作？

欧盟委员会现行说明把制造商和开源软件管理方分开。制造商把开源产品投放市场，就承担制造商义务。法人如果没有把产品投放市场，却长期、系统性地支持某个面向商业活动的开源产品，并对其存续发挥主要作用，可能属于开源软件管理方。这个角色需要制定网络安全政策、处理漏洞，并配合市场监督机关。

O’Donovan 用了常见的双版本模式：项目免费提供开源版，再出售增加功能的版本。他认为，同一组织可以是开源版的管理方、商业版的制造商。委员会的规则也围绕具体产品及其供给方式展开。比起给基金会、公司或开发团队贴一张永久 CRA 标签，这种产品级判断更有用。

法律本身也挡住了简单推断。公司资助、外部贡献或定期发布版本，单独看都不足以证明软件属于商业活动。法规还规定，非营利组织开发的开源软件，如果扣除成本后的收入都用于实现非营利宗旨，其开发不属于商业活动。价格、谁对产品负责、支持是否持续、产品是否面向商业用途，需要一起判断。

O’Donovan 用 IXP Manager 作例子。他说 INEX 认为这个项目符合开源软件管理方的角色；其他交换中心要求供应链材料后，INEX 已发布安全开发与漏洞披露政策。他还指出，INEX 是非营利组织，却会对交换端口收费。这是他对运营实践的解读，不是监管机构对 IXP Manager 作出的分类。公开规则仍要求看产品本身和组织的实际职责。

对适用 NIS2 的运营商，上游身份标签不会代替自己的供应链管理。NIS2 第21条涵盖供应链安全、网络系统的采购、开发与维护，也包括漏洞处理和披露。O’Donovan 给出的做法很具体：维护软件清单、跟踪漏洞，并制定及时修补政策。

问答环节里，他判断容易的案例会很清楚，中间地带可能要由法院逐步厘清。运营商眼下可以先逐个依赖问清楚：谁控制版本发布？谁接收漏洞报告？谁能交付修复？实际使用的是哪个版本？商业模式变化时，产品的法律角色也可能随之变化。只记组织名称的资产清单会漏掉这一转折。