开源软件管理者 (Art. 18-19)
概述
CRA 引入了开源软件管理者 (Open Source Software Steward) 这一新角色。这涉及系统性地支持用于商业活动的开源软件开发的法人实体（如基金会、公司）。
法律依据
Art. 3 No. 16 CRA： "开源软件管理者"是指制造商以外的任何法人实体，其目的是在持续基础上系统性地为特定含数字元素的产品（属于自由和开源软件，且用于商业活动）的开发提供支持，并确保这些产品的市场可行性。
Art. 18 CRA： 开源软件管理者的义务。
Art. 19 CRA： 自由和开源软件的安全证明。
开源软件管理者角色何时适用？
要求（累积性）
- 法人实体（非自然人）
- 不是相关产品的制造商
- 系统性和持续性地支持开发
- 该开源软件产品用于商业活动
- 在确保市场可行性方面具有决定性作用
典型的开源软件管理者
- 开源基金会（Apache、Linux Foundation、Eclipse）
- 赞助和维护开源项目但自身不是制造商的公司
- 托管开源项目并提供其发布基础设施的组织
BAUER GROUP 何时不是开源软件管理者？
- 将开源库用作依赖项时 --> 仅对自有产品承担制造商义务
- 作为贡献者向开源项目贡献时 --> 不承担管理者角色
- 将自有代码发布为开源时 --> BAUER GROUP 此时是制造商，而非管理者
BAUER GROUP 何时可能成为开源软件管理者？
- 如果 BAUER GROUP 系统性地推动和维护来自外部社区的开源项目（例如，自有员工担任维护者、基础设施赞助）
- 如果 BAUER GROUP 设立管理开源项目的自有基金会
当前评估
根据目前的了解，BAUER GROUP 主要作为制造商（自有代码）和使用者（开源依赖项）。开源软件管理者角色当前不适用，但必须对新的开源参与进行审查。
开源软件管理者的义务（Art. 18）
尽管管理者角色的范围不如制造商全面，但以下义务适用：
1. 网络安全策略（Art. 18 第1款）
- 建立和实施文档化的网络安全策略
- 促进与市场监管机构的合作
- 支持软件的安全开发
2. 漏洞处理（Art. 18 第1款）
- 自愿向 ENISA 和国家 CSIRT 报告被积极利用的漏洞
- 促进协调漏洞披露 (CVD)
- 提供漏洞报告的联系点（SECURITY.md 或类似文件）
3. 与机构合作（Art. 18 第2款）
- 应要求：提供文档
- 协助消除安全风险
- 共享漏洞信息
4. 安全证明（Art. 19）
开源软件管理者可发起自愿安全证明：
- 记录已应用的网络安全实践
- 提供漏洞处理流程的证据
- 第三方证明（可选）
开源角色区分
| 角色 | CRA 状态 | 义务 |
|---|---|---|
| 开源使用者（作为依赖项） | 自有产品的制造商 | 对整体产品承担全部制造商义务 |
| 开源贡献者 | 无 CRA 角色 | 无直接 CRA 义务 |
| 开源维护者（自然人） | 非管理者（需为法人实体） | 无直接 CRA 义务 |
| 开源软件管理者（组织） | Art. 18-19 义务 | 有限义务（见上文） |
| 开源制造商（商业性） | 完全的制造商 (Art. 10) | 全部制造商义务 |
对供应链的影响
对 BAUER GROUP 作为制造商的影响
即使 BAUER GROUP 不是开源软件管理者，开源软件管理者条款也有影响：
- 审查开源依赖项： 关键依赖项是否有开源软件管理者？
- 漏洞报告： 开源软件管理者自愿报告漏洞——主动跟踪这些报告
- 安全证明： 评估开源组件时，优先选择经认证的软件
- 风险评估： 没有管理者或活跃社区的开源软件 = 更高风险
处罚
与制造商相比，开源软件管理者受到较低的处罚：
| 违规行为 | 最高处罚 |
|---|---|
| 未履行 Art. 18 义务 | 最高500万欧元或年营业额的1% |
欧盟委员会在确定处罚时会考虑管理者活动的特殊角色和非商业性质。
相关发展
- 欧盟委员会将通过进一步规定安全证明的实施法案（Art. 19）
- 针对开源软件管理者的协调标准正在制定中
- 确切的界定将通过实践和判例法进一步澄清