1.7 自由与开源软件及其管理者 (Art. 3(14)、3(48)、24–25)
1.7.1 概述
CRA 并未整体豁免开源。它对每一个具体项目依次提出三个问题——同一组织在同一天发布的两个项目，答案可能不同。
1. 该软件是否符合 Art. 3(48) 的 FOSS 定义？ → 1.7.2
└── 否 → 适用一般产品规则
2. 该 FOSS 是否在「你的」责任之下？ → 1.7.3
└── 否 → 你是贡献者；CRA 对你不适用
3. 你是否在「商业活动」过程中提供它，
即它是否被投放市场？ → 1.7.4
├── 是 → 你是其「制造商」（完整的 Art. 13 义务）
└── 否 → 你是否为法人，且对面向商业活动的 FOSS
持续提供支持？ → 1.7.5
├── 是 → 你是其「管理者」（Art. 24）
└── 否 → 该项目下无 CRA 义务已采纳欧盟委员会指南
本章落实 2026 年 7 月 27 日欧盟委员会指南第 3 章——迄今关于 CRA 项下开源问题最详尽的论述。该指南不具法律约束力，且在撰写时尚未正式通过——见欧盟委员会 CRA 指南。
1.7.2 何为 FOSS (Art. 3(48))
法律依据
Art. 3(48) CRA： 「『自由与开源软件』指其源代码被公开共享、并依据授予自由访问、使用、修改与再分发全部权利的自由开源许可证提供的软件。」
两个条件必须同时满足：
| # | 条件 | 说明 |
|---|---|---|
| 1 | 授予完整权利的自由开源许可证 | 可自由访问、使用、修改与再分发——即 FOSS 的传统理解 |
| 2 | 源代码被公开共享 | 公开可得，无论上游还是下游——而非仅在受限或附条件的基础上提供 |
仅有 FOSS 许可证并不足够
以自由开源许可证分发、但源代码仅向付费客户或有限用户群体开放的软件，不属于 Art. 3(48) 意义上的 FOSS。获取源代码是行使其他权利的必要前提：没有源代码，实际上无法修改或有意义地复用该软件。
指南未指明哪些具体许可证兼容或不兼容。判断针对的是许可条款以及代码的实际可得性。
1.7.3 该 FOSS 是否在你的责任之下
FOSS 开发通常涉及众多贡献者、去中心化协作，以及贡献与决策的分离。CRA 只将义务施加于真正掌控项目的一方。
| 角色 | 判断 | CRA 后果 |
|---|---|---|
| 维护者 | 发布该 FOSS 且对其开发、发布与分发决策行使主要控制权 | 该 FOSS 在其责任之下 |
| 贡献者 | 提交源代码，但不掌控发布、路线图或治理决策 | 该 FOSS 不在其责任之下——CRA 就该项目对其不适用 |
提交权限不等于控制权
仅存在技术权限（如 commit 权限）不足以确立责任归属。责任在于发布并掌控项目的一方。
示例： 某开发者——无论是个人还是企业员工——提交了包含安全补丁或新功能的 Pull Request。维护者审查、接受并合并，随后纳入某个发布版本。该提交者是贡献者，就该项目不受 CRA 约束。
1.7.4 是否被投放市场：货币化判断
一旦确认项目在你的责任之下，问题就变成你是否在商业活动过程中提供它——这正是投放市场的构成要件。
CRA 鉴于条款 18 设定了基线：「产品含数字元素的开发情形本身，或其开发的资金来源，不应被纳入考量」，且*「由制造商未予货币化的、符合自由与开源软件条件的含数字元素产品的提供，不应视为商业活动」*。
判断汇总
| 情形 | 是否投放市场？ |
|---|---|
| 对软件本身收费，如对预编译二进制文件收费 | 是 |
| 在收费版本之外另有免费「社区」版本（含 open-core） | 收费版是；社区版否 |
| 借以货币化其他产品或服务的软件（广告、佣金、订阅、付费扩容） | 是 |
| 以处理个人数据为使用条件，且目的并非仅为改进安全性、兼容性或互操作性 | 是 |
| 可免费下载的软件，附带可选的、单独购买的专业服务 | 否 |
| 付费版或企业版，其访问权包含技术支持或性能优化等附加权益 | 是 |
| 自然人将技术支持与访问权捆绑，且收费仅覆盖实际成本 | 否 |
| 为不在自身责任之下的 FOSS 提供技术支持，且未作实质性修改 | 否 |
| 自愿捐赠，包括通过捐赠链接，即使金额超过成本 | 否（不太可能被视为投放市场） |
| 实际上以捐赠作为获取软件、核心功能或更新之条件 | 是 |
| 由第三方出资、赞助或资助的开发，成果被公开共享且可自由获取 | 否 |
| 由非营利实体发布，其扣除成本后的全部收益用于非营利目的 | 否 |
| 供其他制造商集成、且发布者未予货币化的 FOSS | 否 |
收费与社区/付费双版本
若发布者对软件本身收费，即为投放市场，是其制造商。
许多发布者在收费版本之外提供代码库几乎相同的免费「社区」版本。二者被视为不同产品：
- 付费版本被货币化，因而投放市场 → 制造商义务。
- 免费/社区版本未被货币化，因而未投放市场。
即便付费版本是扩展免费代码库的增强型商业版本，或将其纳入更大的产品——即 open-core 模式——结论同样成立。
法人身份带来的转折
若社区版本的发布者是法人，则其就该免费版本另须承担管理者义务。若发布者是自然人，该免费版本完全不在 CRA 范围内。
货币化其他服务或个人数据
| 示例 | 判定 |
|---|---|
| 一款自由开源的市场应用，支持购买行为，发布者由此获得广告收入、佣金或订阅费 | 投放市场 |
| 一款自由开源的 VPN，用户可付费获取额外服务器或专用 IP 地址 | 投放市场 |
| 一款自由开源的健身追踪应用，其使用以处理个人数据用于定向广告或与安全性、兼容性、互操作性无关的分析为条件 | 投放市场 |
支持服务
在 FOSS 项目之外提供付费支持，并不使其成为商业提供。支持服务包括与软件使用、文档、配置和部署有关的咨询、培训与专业服务。
决定性因素
获取 FOSS 本身——包括其维护——是否以报酬为条件？ 若软件可自由下载安装，用户可自愿另行购买专业服务，则未投放市场。若获取某一特定版本（含技术支持、性能优化等权益）以付费为条件，则属投放市场——无论功能等效的软件是否也以 FOSS 许可证免费提供。
两点细化在实践中很重要：
- 自然人与实际成本。 对自然人而言，即便将技术支持与访问权直接捆绑，只要所收取的价格仅用于回收实际成本，仍不构成商业活动。该成本包括设计、开发与维护——并明确包括该自然人的合理生活开支。因此，发布 FOSS 并提供技术支持以覆盖成本并获取公平报酬的自然人，仅凭此点并未投放市场。
- 为他人项目提供支持。 为不在自身责任之下的 FOSS 提供技术支持者，并未投放市场——除非其在提供支持过程中对该 FOSS 作了实质性修改（Art. 22）。服务商帮助客户在其本地服务器上安装 FOSS 而未作实质性修改的，未投放市场。
捐赠
捐赠总体上是安全的
「无营利意图地接受捐赠不应被视为商业活动」（鉴于条款 15）。仅仅附上捐赠平台链接并非营利意图——即便所募集金额超过设计、开发与提供的成本亦然。这也包括法人所雇贡献者的合理报酬，以及自然人的合理生活开支。
由于捐赠随时间波动，应保留一定的灵活性。仅依靠捐赠维持的 FOSS 「不太可能被视为投放市场」。
例外在于综合判断下捐赠实质上等同于收费的情形：
| 模式 | 判定 |
|---|---|
| 可下载的发布版与安全更新仅提供给捐赠者；非捐赠者无法获得当前版本 | 投放市场 —— 捐赠成为获取条件 |
| 源代码公开，但预编译二进制、常规更新与有保障的安全修复仅面向捐赠者 | 投放市场 —— 捐赠与产品的核心要素挂钩 |
| 捐赠与合同性权益或超出社区福利的专属优待相绑定 | 投放市场 |
资助与赞助
第三方出资、赞助或以其他方式资助开发，本身并不决定是否投放市场。资助、漏洞赏金、赞助、服务合同与付费开发工作均同。
若成果被公开共享、对所有人可自由访问、使用、修改与再分发，且未以其他方式货币化，则未投放市场。出资方——与任何集成者一样——在集成时须履行 Art. 13(5) 的尽职调查。
非营利实体
若发布者是*「其组织形式确保扣除成本后全部收益用于实现非营利目的」*的非营利组织（鉴于条款 18），则其发布的 FOSS 未投放市场。若其符合管理者定义，则适用 Art. 24。
示例： 某法人发布一款通过搜索引擎合作直接货币化的自由开源浏览器，但其扣除成本后的全部收益均用于非营利目的。该浏览器不被视为投放市场；其发布者是该软件的管理者。
供其他制造商集成的 FOSS
若 FOSS 由可识别的主体发布，但意图供其他制造商集成到自身产品中，则未在欧盟市场投放——除非发布者另行将其货币化。在未投放市场的情形下，若发布该软件的法人持续提供支持，则须承担管理者义务。
1.7.5 开源软件管理者 (Art. 3(14))
法律依据
Art. 3(14) CRA： 「『开源软件管理者』指制造商以外的任何法人，其目的或宗旨在于持续、系统地为特定的、符合自由与开源软件条件且面向商业活动的含数字元素产品的开发提供支持，并确保这些产品的可持续性。」
Art. 24 CRA： 开源软件管理者的义务。Art. 25 CRA： 安全认证。
构成要件（累积）
- 法人（非自然人）
- 就该具体项目而言不是制造商 —— 即未将其投放市场
- 对其开发持续、系统地提供支持
- 该项目面向商业活动 —— 例如用于集成到商业服务或货币化产品中
- 该实体确保项目的可持续性
角色按项目而定，而非按组织而定
一个实体，多重角色
成为某个项目的管理者，并不使该实体成为其发布的其他一切内容的管理者。同一法人可以同时是：
- 项目 A 的制造商（其已将其货币化），
- 项目 B 的管理者（已发布、未货币化、面向商业活动），以及
- 就项目 C 完全不承担 CRA 义务（未投放市场且未被其系统性支持，或不面向商业活动）。
这也包括 1.7.4 中描述的社区/付费分野：发布者是付费版本的制造商，同时是社区版本的管理者。
持续支持的三个层级及其报告义务
所有管理者均须遵守 Art. 24(1) 与 (2)。Art. 14(1)、(3) 与 (8) 的报告义务适用到何种程度，依所提供支持的类型而定，依据 Art. 24(3)：
| 层级 | 典型支持 | Art. 14(1) 报告被主动利用的漏洞 | Art. 14(3) 报告严重事件 | Art. 14(8) 告知用户 |
|---|---|---|---|---|
| 1 — 非技术性 | 品牌管理、制定治理规则、组织社区活动、募集捐赠 | 否 —— 未参与开发 | 否 —— 未为开发提供网络与信息系统 | — |
| 2 — IT 基础设施 | 托管源代码仓库、提供版本控制、生成签名密钥 | 否 | 是 —— 与该基础设施相关、影响产品安全的严重事件 | 在适当情形下告知所有用户（如发布公告） |
| 3 — 工程资源 | 雇用开发者、协调开发工作、审查或合并代码、管理发布、处理漏洞报告与安全补丁 | 是 | 是 | 在适当情形下告知所有用户；若与受影响用户存在直接关系，则直接告知 |
层级 1 的管理者仍应做什么
即便管理者无须报告被主动利用的漏洞，一旦知悉，也应依其网络安全政策将信息传达给项目维护者。维护者与管理者还应考虑依 Art. 15 自愿报告。层级 2 的管理者同样应促进正确的漏洞处理并考虑自愿报告。
触发点是知悉「被利用」，而非知悉「有缺陷」
管理者在 Art. 24(3) 项下的报告义务，自其知悉存在主动利用时产生——而非仅因代码库中存在漏洞。由于 FOSS 组件通常被下游集成，管理者通常经由第三方报告获知：某制造商在其自有产品中检测到该组件被利用并向上游报告，或用户、安全研究人员报告了被利用的证据。
身份变化
| 变化 | 后果 |
|---|---|
| 该实体停止系统性、持续性支持 | 其可能不再符合管理者定义，可能不再承担相应义务。建议其就该项目明确沟通身份变更。 |
| 管理者决定直接货币化该项目 | 其即投放市场，自投放市场之日起成为该产品的制造商——但不及于其此前以管理者身份参与的早期版本。 |
1.7.6 管理者的义务 (Art. 24–25)
1. 网络安全政策 (Art. 24(1))
- 制定并实施书面的网络安全政策，促进安全产品的开发与漏洞的有效处理
- 促进与市场监管机构的合作
2. 漏洞处理与报告 (Art. 24(1)、(3))
- 在 1.7.5 层级表所确定的范围内报告被主动利用的漏洞与严重事件——在层级适用之处，这些是义务，而非自愿行为
- 促进协调漏洞披露 (CVD)
- 提供漏洞报告联系点（SECURITY.md 或等效方式）
- 在无强制义务之处，考虑依 Art. 15 自愿报告
3. 与主管机关的合作 (Art. 24(2))
- 应要求提供文档
- 协助消除安全风险
- 共享漏洞信息
4. 安全认证 (Art. 25)
管理者可发起自愿的安全认证：记录所采用的网络安全实践、漏洞处理流程的证据，以及（可选的）第三方认证。
1.7.7 贡献者、集成者与下游使用
| 陈述 | CRA 项下的定位 |
|---|---|
| 向不在自身责任之下的 FOSS 贡献源代码者 | 就该项目不受 CRA 约束（鉴于条款 18） |
| 将 FOSS 组件集成到自有产品的制造商 | 不会因此对这些组件各自的 CRA 合规负责——即便其为组件维护贡献了源代码 |
| 被集成到货币化产品中的 FOSS 组件 | 其自身状态不受影响。CRA 是否适用于它，仅取决于其发布者是否将其投放市场 |
| 未投放市场的 FOSS 的维护者 | 对集成其组件的实体不负义务 |
集成者就自有产品必须做的事：
- 就产品整体遵守 CRA
- 对集成组件履行尽职调查（Art. 13(5)）→ 5.3 第三方评估
- 向上游报告漏洞并共享安全修复（Art. 13(6)）→ 3.5 漏洞处理要求
1.7.8 角色界定
| 角色 | CRA 身份 | 义务 |
|---|---|---|
| 贡献者（不掌控发布/治理） | 无 CRA 角色 | 无 |
| 维护者，自然人，未货币化 | 不在适用范围内 | 无 |
| 维护者，自然人，已货币化 | 制造商 | 完整的 Art. 13 义务 |
| 维护者，法人，未货币化，项目面向商业活动，持续支持 | 管理者 | Art. 24–25，按 1.7.5 分层 |
| 维护者，法人，未货币化，无持续支持或不面向商业活动 | 无 CRA 角色 | 无 |
| 货币化版本的发布者 | 该版本的制造商 | 完整的 Art. 13 义务（若为法人，同时是社区版本的管理者） |
| 将 FOSS 集成到自有产品的集成者 | 自有产品的制造商 | 自有产品的完整义务 + Art. 13(5) 尽职调查 + Art. 13(6) 上游报告 |
1.7.9 情景目录
| # | 情景 | 结论 |
|---|---|---|
| 1 | 个人开发者以自有名义发布 FOSS，不收费，附捐赠链接。公司 B、C、D 集成该软件并自愿捐赠以支持维护。 | 未投放市场。 该开发者无 CRA 义务。B、C、D 履行 Art. 13(5) 尽职调查。 |
| 2 | 非营利基金会 F 发布供集成到商业产品的 FOSS 组件，并承诺持续支持。公司 A 与 B 投入开发者时间。 | 未投放市场。 F 是管理者（Art. 24）。A、B、C 履行尽职调查。 |
| 3 | 公司 A 为自有产品开发 FOSS 组件，同时单独发布并维护它，未予货币化。B、C、D 集成并投入时间。 | 未投放市场。 A 不是其制造商，而是其管理者。 |
| 4 | 公司 A 发布 FOSS，并提供含技术支持与性能优化的付费版本。B、C、D 参与贡献，控制权仍在 A。 | A 是付费版本的制造商（除非 A 是符合条件的非营利实体，此时为管理者）。B、C、D 就该项目无义务。 |
| 5 | 公司 A 发布并维护供他人集成的 FOSS；不收费、不处理个人数据、不销售支持。公司 B 贡献代码并独立于分发另行提供支持服务。 | A 是管理者。B 就该项目无 CRA 义务。 |
| 6 | 某非营利实体发布 FOSS 组件并持续支持；维护由科研资助支撑，新功能由捐赠及与集成制造商的合作项目资助并并入代码库。 | 该非营利实体是管理者。资助了某项功能的制造商不会成为该组件的制造商；其在集成时履行尽职调查。 |
| 7 | 某非营利实体发布 FOSS SDK，由会员费资助；会员单位员工贡献代码。制造商使用该 SDK 构建产品。 | 该非营利实体是管理者。会员不对 SDK 的 CRA 合规负责。制造商履行尽职调查。 |
| 8 | 个人在公共包仓库发布 FOSS 库并附捐赠链接；某制造商免费下载并集成。 | 该开发者与包仓库均无义务。制造商履行尽职调查。 |
1.7.10 BAUER GROUP 的定位
BAUER GROUP 在何时不是管理者？
- 将开源库用作依赖项 → 仅就自有产品承担制造商义务
- 以贡献者身份参与开源项目 → 无管理者角色
- 发布自有代码并将其货币化 → BAUER GROUP 是其制造商
BAUER GROUP 在何时可能成为管理者？
- 发布未货币化、供第三方产品集成的 FOSS 组件并持续维护 → 该组件的管理者
- 在付费版本之外提供社区版本 → 社区版本的管理者，付费版本的制造商
- 系统性地推动并维护某个外部开源项目（自有员工担任维护者、赞助基础设施）
- 设立自有基金会管理开源项目
需要行动 —— 逐项目判定
管理者问题须逐项目回答，而非对组织一次性作答。BAUER GROUP 控制下的每个已发布 FOSS 仓库都需要一份书面判定：制造商、管理者 或 无 CRA 角色 —— 并附得出该结论的货币化判断与日期。
当前评估
根据现有认知，BAUER GROUP 主要作为制造商（自有代码）与使用者（开源依赖）行事。目前不主张管理者角色——但对于未货币化且供第三方集成的已发布仓库，必须按 1.7.5 复核，因为正是这一组合会构成管理者。
对供应链的影响
- 审视开源依赖： 关键依赖是否有管理者？
- 漏洞报告： 在层级 3 适用之处，管理者会报告被主动利用的漏洞——需跟踪这些渠道
- 安全认证： 评估开源组件时优先选择已获认证的软件
- 风险评估： 无管理者或无活跃社区的开源意味着更高风险
1.7.11 FOSS 的合规评估减免 (Art. 32(5))
属于 FOSS 的重要产品
符合 FOSS 条件并投放市场的 I 类或 II 类重要产品，可依 Art. 32(5) 采用标准类别的合规评估程序——分类本身不会将其推入更严格的路径。参见 7.1 产品分类。
1.7.12 处罚
| 违规 | 最高处罚 |
|---|---|
| 未履行 Art. 24 义务 | 最高 500 万欧元或年营业额的 1% |
在裁量处罚时会考虑管理者活动的特殊角色与非商业性质。
1.7.13 相关进展
- 委员会可通过实施法案进一步细化安全认证（Art. 25）
- 与管理者相关的协调标准正在制定中
- 委员会仍可能依 Art. 26 发布进一步指南
本页解释的来源与法律地位：欧盟委员会 CRA 指南。