开源项目的法律与合规¶

主要作者

本节概览

开源世界看似自由奔放，但“自由”不等于“无法无天”。本节介绍开源背后的法律与合规框架：版权、许可证、CLA 与 DCO、专利，以及企业与个人真正需要的合规基础设施（SPDX、SBOM、OpenChain 与欧盟 CRA）。在开源的世界里，法律与伦理意识与代码能力同样重要。

学习目标¶

完成本节后，你应当能够：

说明版权、许可证与贡献者授权机制三者之间的关系；
区分 CLA 与 DCO，并在真实项目里判断该用哪一种；
识别许可证中的专利条款与防御性专利机制；
说出 SPDX 标识符、SBOM、OpenChain 与欧盟 CRA 各自解决什么问题；
描述企业开源合规的五步流程，并说明每一步应留下什么记录。

“自由”的边界在哪里？¶

提到开源，很多人首先想到的是“免费”、“自由”、“共享”。没错，这些都是开源的核心魅力。但如果因此认为开源世界就是一片没有任何规则、可以随心所欲的“法外之地”，那可就大错特错了。

事实上，开源的蓬勃发展，恰恰建立在一套相对完善且不断演进的法律框架和社区规范之上。其中，最核心的就是开源许可证 (Open Source Licenses)。它们规定了代码的使用者和贡献者各自拥有哪些权利，需要履行哪些义务。不理解这些规则，盲目地使用或贡献开源代码，轻则可能引发不必要的麻烦，重则甚至可能卷入法律纠纷，让你辛辛苦苦的成果付诸东流。

所以，想要在开源的世界里愉快地玩耍，不仅要会写代码，还得懂点“法”。

开源世界的“紧箍咒”：五花八门的开源许可证¶

你可能已经见过一些开源许可证的缩写，比如 GPL、MIT、Apache 2.0、BSD 等等。它们看起来都差不多，但实际上“内涵”大不相同。简单来说，开源许可证就是一份法律文件，它授权他人可以自由地使用、修改和分发受版权保护的软件源代码，但同时也附加了一些条件。

这些许可证种类繁多。按 copyleft（著佐权，俗称"传染性"）强度，可分为宽松型（permissive）、弱 copyleft、强 copyleft 三大族，此外还有不属于开源的 source-available 一族。每族的效力范围、专利条款与典型项目见开源许可证。

这里只强调三个最容易出错的地方：

Apache-2.0 不是 copyleft，它没有传染性，但有明文专利授权、专利报复终止与 NOTICE 义务；
copyleft 的效力范围不同：MPL-2.0 管到文件、LGPL 管到库、GPL/AGPL 管到整个衍生作品；
source-available 不是开源：SSPL、BUSL-1.1、Elastic License 2.0 都公开源码，但附加了 OSD 不允许的限制。

如何选择许可证？

选择取决于你的目标：希望代码被广泛使用（含商业公司）→ 宽松许可证（MIT、Apache-2.0）；希望衍生作品保持开源 → copyleft（GPL-3.0-or-later、AGPL-3.0-or-later）；库希望被闭源软件使用 → LGPL-3.0-or-later 或 MPL-2.0。

务必写成完整的 SPDX 标识符：只写 GPL-3.0 / AGPL-3.0 / LGPL-3.0 没有表达是否授予"按后续版本使用"的权利，会直接影响兼容性与再许可范围。上例按惯例用 -or-later（便于下游组合新版本）；若你不希望被升级到后续版本，就写 -only。

决策维度、兼容性矩阵与 SPDX 标识符写法见开源许可证。没有绝对的好坏，只有适不适合。

版权声明与贡献者权利管理¶

别忘了署名

CLA 与 DCO：贡献者的两种授权机制¶

当一个开源项目接收来自五湖四海的贡献时，需要确保这些贡献的来源清晰、合法，并且项目方有权以项目的许可证来分发这些贡献。常见机制有两种：

机制	形式	贡献者的动作	典型项目
贡献者许可协议（CLA）	一份需要签署的法律文件，授予项目管理方关于其贡献的版权与专利许可	一次性签署（个人或企业版）	Apache 基金会旗下项目、部分 Google 项目
开发者原创声明（DCO）	在每次提交信息中加入 `Signed-off-by: 姓名 <邮箱>`，声明有权以项目许可证提交该项工作	每次提交都需签名	Linux 内核、QEMU

怎么判断目标项目用哪一种

读 CONTRIBUTING。若要求配置 CLA 助手或签署在线协议，就是 CLA；若要求 git commit -s（或配置 format.signoff），就是 DCO。若一次提交忘记签名，可用 git rebase --signoff <base> 补上。

CLA 和 DCO，哪个更好？

CLA 为项目方提供了更强的法律保障和运营灵活性，但签署过程相对繁琐，有时也会引发关于贡献者权利是否被过度集中的担忧。DCO 更简单便捷、对贡献者更友好，但项目方在面临潜在法律风险时可能需要承担更多举证责任。选择哪种方式取决于项目的具体需求、社区文化和风险考量；作为贡献者，你要做的是遵循目标项目的规定，而不是替它选择。

义务什么时候触发？

使用、修改、分发、提供网络服务这四类行为触发的义务完全不同。分发才会触发 copyleft 的源码义务，AGPL 额外在网络交互时触发。 完整的义务判断方法见开源许可证。

“看不见的陷阱”：开源软件中的专利问题¶

虽然开源的核心在于代码的开放共享，但软件专利 (Software Patents) 的存在，给开源世界带来了一些不确定性和潜在风险。如果你的开源软件不小心用到了别人已经注册的专利技术，就可能构成专利侵权，引来官司。

为了应对这种风险，一些主流的开源许可证在其条款中也包含了专利相关的内容：

Apache License 2.0 就以其明确的专利授权条款而闻名。它规定，每一位贡献者都授予软件接收者一份关于其贡献中所包含的任何专利的许可。这就像给用户吃了一颗“定心丸”，不用太担心因为用了这个贡献者的代码而被反过来告专利侵权。
GNU GPLv3 也加强了专利方面的规定，旨在防止专利被用作阻碍软件自由共享和修改的工具。

除了许可证本身的保护，开源社区和一些组织也想出了一些“防御姿势”，比如成立防御性专利联盟（如开放创新网络 OIN），大家把专利放到一个池子里，互相承诺不攻击，一致对外，共同抵御“专利流氓”（那些手握一堆专利但自己不做产品，专门靠告别人侵权赚钱的公司或个人）的骚扰。

法律与伦理的十字路口：案例引发的思考¶

空谈法律条文可能有点枯燥，让我们来看一些真实发生过的，或者可能发生在我们身边的案例，或许能让你对开源世界的法律和伦理问题有更切身的体会。

场景一：公司的“拿来主义”与 GPL 的“紧箍咒”

想象一下，一家公司开发了一款商业产品，为了加快开发进度，研发团队从网上找了一些遵循 GPL 许可证的开源代码，直接用到了自己的产品里。产品上市后卖得还不错，但他们并没有按照 GPL 的要求公开自己产品的源代码。结果，被原始开源项目的权利人发现了，一纸诉状告上法庭，指控他们侵犯版权并违反了 GPL 许可证的条件。 * 思考与讨论： 1. 这家公司的行为，问题出在哪里？ 2. GPL 许可证的核心要求是什么？为什么被称为具有“传染性”？ 3. 如果这家公司不想公开其商业产品的全部源代码，他们当初在选择开源组件时，应该注意些什么？（比如选择更宽松的许可证，或者对 GPL 组件进行隔离使用等） 4. 这样的案例（比如早年间 BusyBox 系列诉讼）在国际上并不少见，它们对企业使用开源软件有何警示意义？

场景二：许可证被违反时，权利人怎么维权？

开源许可证是有法律效力的授权，违反其条件即失去授权，构成版权侵权。国际上有若干具有代表性的判例：

Jacobsen v. Katzer（2008，美国）：法院确认开源许可证的署名等条件属于可执行的许可条件，违反条件即丧失许可，而不只是合同违约。这一判决确立了开源许可证的可执行性。
Artifex v. Hancom（2017，美国）：围绕 Ghostscript 的 AGPL 义务达成和解，明确了 AGPL 在商业产品中的实际约束力。
BusyBox 系列诉讼（2007 年起，美国）：多起针对未履行 GPL 义务的厂商的诉讼，最终多以公开源码并和解告终，成为企业使用 GPL 组件的经典警示。
数字天堂案（2019，中国） 与 "不乱买"案（2021，中国）：中国法院认可了 GPL 系列许可证的约束力，确认违反开源许可条件构成侵权。

思考与讨论：

"借鉴思路"和"复制代码"的界限在哪里？开源是否意味着可以随意复制粘贴？（提示：思想与算法不受版权保护，具体的代码表达受保护；许可证约束的是后者。）
如果你发现自己贡献的开源项目被他人违反许可证使用，你会如何维护权益？请列出至少三条由轻到重的处理路径。
为什么法院倾向于把开源许可证认定为"授权条件"而不是"普通合同"？这对使用者的行为有什么实际影响？
企业在引入第三方开源组件时，应该留下哪些"自证合规"的证据？

合规基础设施：从"看许可证"到"可审计"¶

真实项目的合规不是读一遍 LICENSE，而是建立一套可审计的流程。以下是当前业界的基本配置。

1. SPDX 标识符与许可证清单¶

SPDX 标识符是描述许可证的标准短名（如 MIT、Apache-2.0、GPL-2.0-only）。在包元数据与源码文件头标注它，能让工具自动识别，也能避免"GPLv2 到底是不是 or-later"这类歧义。

2. SBOM：软件物料清单¶

SBOM（Software Bill of Materials） 是一份机器可读的组件清单，记录项目包含的所有依赖及其版本、许可证与来源。主流格式有两种：

格式	主导方	常见场景
SPDX	Linux 基金会	许可证合规、法规申报
CycloneDX	OWASP	安全漏洞管理、供应链风险

当出现像 Log4Shell 这样的事件时，有 SBOM 的团队可以在数小时内定位受影响范围，没有 SBOM 的团队只能逐个系统排查——这是 SBOM 从"合规负担"变成"工程必需"的直接原因。

3. 扫描与审计工具¶

工具	用途
ScanCode	扫描代码库识别许可证与版权声明
FOSSA / Black Duck	商业化的许可证与依赖合规平台
ORT（OSS Review Toolkit）	开源项目的依赖审查与合规流程
reuse	检查每个文件是否带有许可证与版权信息

4. 流程标准¶

OpenChain ISO/IEC 5230：开源许可证合规管理体系的国际标准，规定了一套可审计的流程要求（识别、审查、履行义务、培训、对外沟通）。企业建立开源合规体系时通常以它为框架。
欧盟《网络韧性法案》（CRA）：对含数字元素的产品提出安全与漏洞管理要求，并规定了分阶段生效时间——漏洞与事件报告义务自 2026 年 9 月 11 日起适用，主要义务自 2027 年 12 月 11 日起全面适用（以官方文本为准）。对开发者而言，最直接的影响是：需要为产品维护 SBOM、建立漏洞处置与披露流程，并向用户提供安全更新。

给学生的最小可执行动作

你不需要企业级工具链。从今天就能做的三件事：① 在自己的项目里加 LICENSE 文件与 SPDX 文件头；② 用 reuse 或 ScanCode 扫一遍自己参与的项目；③ 在贡献提案里写清"这个依赖的许可证是什么、是否与本项目兼容"。

企业合规流程：五步走¶

graph LR
    A[识别：扫描依赖与许可证] --> B[审查：判断义务与兼容性]
    B --> C[整改：替换/隔离/取得授权]
    C --> D[履行：附声明/NOTICE/提供源码]
    D --> E[归档：SBOM 与决策记录]

每一步都应留下可审计的记录。"我们审查过了"不是证据，"审查记录 + 结论 + 依据链接"才是证据。

中国的开源法律与合规实践¶

中国在开源法律与合规方面已有明确的进展，同时也有需要继续完善的地方。

法律与司法层面

《著作权法》2020 年修订（2021 年 6 月 1 日起施行）为软件著作权保护提供了更清晰的规则框架；
**数字天堂案（2019）与"不乱买"案（2021）**在司法实践中认可了 GPL 系列许可证的约束力，确认违反开源许可条件可以构成侵权；
围绕开源许可证的性质（授权条件还是合同）、开源抗辩、赔偿数额计算等问题，实践仍在发展中。

许可证与生态层面

木兰（MulanPSL-2.0） 是中国首个获得 OSI 批准、由基金会主导的开源许可证；
开放原子开源基金会于 2020 年 6 月成立，托管 OpenHarmony、openEuler 等一批项目；
国内社区组织（如开源社）在持续推广开源文化与合规知识。

需要警惕的三种现象

"伪开源"：只在宣传中使用"开源"一词，实际核心代码封闭、许可证缺失或混乱，社区无法参与；
许可证使用不当：不理解条款就随意选择许可证，或把互不兼容的许可证混用在同一个项目中；
忽视社区贡献：使用了大量开源组件，却在文档、致谢与许可证声明中省略原始作者与来源。

讨论与练习¶

思考题（附参考要点）

作为使用者：在学习和使用开源软件时，如何培养合规意识？ 参考要点：看 LICENSE 而不是看宣传语；确认版本与 only/or-later；判断自己属于"使用/修改/分发/网络服务"哪一类；保留声明与 NOTICE。
作为旁观者：发现身边有不规范使用开源代码的现象，应该以什么态度和方式提醒？ 参考要点：先确认事实、对事不对人；用许可证原文与条款说话；给出可执行的整改路径；不公开点名指责。
作为贡献者：如果你的贡献被下游违反许可证使用，你会怎么做？ 参考要点：友好沟通 → 在项目公开渠道说明 → 请求项目维护者以项目名义交涉 → 必要时寻求法律途径；保留证据。
作为推动者：如何在国内更好地推动开源合规文化？ 参考要点：从课程与社团做起、把合规写进项目模板与 CI、分享真实案例而不是恐吓、让合规成为"顺手的事"。

完整的许可证判断训练（含答案与评分标准）见许可证判断练习。

开源的世界，技术是基石，但法律与伦理是护栏。只有当每一位参与者都树立起规则意识，尊重他人的劳动成果，共同维护一个健康、有序的生态环境，开源的"自由之花"才能绽放得更加持久。