Mi&Bee Blog
English

从 Redis 转 BSL 到 AGPL 复兴：Source Available、AI 与许可证攻防

架构设计 开源许可证, Source Available, BSL, SSPL, AGPL, AI 许可证 开源与工程决策系列 10966 字 22 分钟阅读
🔊

2023 年 8 月，HashiCorp 把 Terraform、Vault、Consul 等全部核心产品从 MPL 2.0 改成 BSL 1.1。社区炸了，一个月后 Linux 基金会牵头 fork 出 OpenTofu。本以为故事到此为止——结果 2024 年 4 月 IBM 宣布 64 亿美元收购 HashiCorp，2025 年 2 月完成交割，HashiCorp 变成 IBM 旗下的 Red Hat 业务单元。改许可证的 OSS 公司不但没衰落，反而成了被并购的标的。

更反讽的是另一条线：2021 年 Elastic 把 Elasticsearch 从 Apache 2.0 改成 SSPL+ELv2 双协议，AWS 随手 fork 出 OpenSearch 反击。三年后的 2024 年 8 月，Elastic 又把 AGPL v3 加进来，凑成 SSPL+ELv2+AGPL 三协议，CEO Shay Banon 发了一篇博客叫《We are back open source》——绕了一圈又回来了。2025 年 Redis 8.0 跟着加 AGPL，剧本几乎一模一样。

这一篇讲的就是这一组「源码可见但不是开源」的许可证（Source Available），它们怎么演化、怎么和 OSI 的开源定义对抗、又怎么被云厂商逼得退回 AGPL。最后讲中美法院已经确认了开源许可证的可执行性，再附一份选型合规清单。

先把术语分清：Open Source vs Source Available

Open Source（开源） 是 OSI 的注册商标。一份许可证要叫自己"open source"，必须通过 OSI 的《开源定义》（OSD）十项条款审批。截至 2026 年，OSI 已批准了 100 多份许可证。

Source Available（源码可见） 不等于开源。代码公开可读、可 fork，但有使用限制——比如「不能拿去做托管服务」「生产环境用要付费」。BSL、SSPL、ELv2、RSALv2、FSL 都属于这一类，OSI 一个都没批准。

OSD 里被 Source Available 许可证最常违反的是三条：

mermaid
flowchart TD
    OSD["OSD 十项条款"] --> V5["第 5 条<br/>不歧视任何人/团体"]
    OSD --> V6["第 6 条<br/>不歧视使用领域"]
    OSD --> V9["第 9 条<br/>不限制其他软件"]

    V5 -->|"SSPL 对 SaaS<br/>公司区别对待"| X["违反"]
    V6 -->|"BSL/ELv2/RSALv2/FSL<br/>限制托管/生产使用"| X
    V9 -->|"SSPL 要求整套服务栈<br/>也必须 SSPL"| X

    classDef base fill:#bbdefb,stroke:#2196F3,color:#0D4741
    classDef clause fill:#fff3e0,stroke:#FF9800,color:#BF360C
    classDef bad fill:#ffcdd2,stroke:#f44336,color:#B71C1C
    class OSD base
    class V5,V6,V9 clause
    class X bad

OSI 执行总监 Stefano Maffulli 2025 年有过一句话：「把 BSL 称为开源，就像把素汉堡称为牛肉。」 他同时承认「延迟开源发布（DOSP）」是一种合法实践——意思是项目可以预先承诺"几年后自动转成 OSI 许可证"，BSL 就是这么做的。这条出路也是 Elastic、Redis 后来「回归开源」的路径。

普通开发者最容易踩的坑就是看到 GitHub 上的 BSL 或 FSL 标签，误以为「开源可自由用」，结果一年后法务审查才发现生产环境部署违反了许可证。两难：买商业许可证，或迁移到其他项目。

Source Available 五大主力和两个变种

BSL 1.1：填空式条款的鼻祖

Business Source License 由 MariaDB 在 2013 年创建，起草人是律师 Heather Meeker。核心机制：

mermaid
flowchart LR
    NOW["今天<br/>源码可读/可改/<br/>非生产可用"] -->|"Change Date<br/>默认 4 年"| FUTURE["到期自动转换<br/>GPL/Apache/MPL"]

    classDef now fill:#fff3e0,stroke:#FF9800,color:#BF360C
    classDef fut fill:#c8e6c9,stroke:#4CAF50,color:#1B5E20
    class NOW now
    class FUTURE fut
  • 源码公开可读、可修改、可在非生产环境用
  • 设置 Change Date（变更日期），默认 4 年，可由许可方提前
  • 到期后自动转换成 GPL 2.0 或其他兼容的开源许可证（也可指定 Apache、MPL）
  • 到期前，生产环境商业使用要购买商业订阅
  • 通过 Additional Use Grant（额外使用授权）的填空式条款，每个项目可以自定义允许的使用范围

采用方：HashiCorp 全线（2023 年 8 月，4 年 Change Date，到期转 MPL 2.0）、CockroachDB（3 年转 Apache 2.0）、Sentry（早期用，后转 FSL）。

BSL 不被 OSI 批准，原因就是第 6 条——变更日期前限制生产性使用属于「歧视使用领域」。

SSPL：MongoDB 给云厂商下的套

Server Side Public License 由 MongoDB 在 2018 年 10 月创建，基于 AGPL v3 修改。它和 AGPL 的关键差异在第 13 条：

  • AGPL v3 第 13 条：只要求公开「直接与软件交互的网络服务」的源码
  • SSPL 第 13 条：扩展到整个服务栈——若将软件作为公共服务提供，必须把整套服务栈的源码（管理工具、备份、监控、界面、EC2/IAM 等所有相关程序）都在 SSPL 下公开

这意味着 AWS、Azure、GCP 想提供 MongoDB 托管服务，就得把自己整套云服务栈都开源——事实上不可能。这就是 SSPL 的设计目的：让云厂商无法用现成的代码做托管。

MongoDB 2018 年向 OSI 提交 SSPL 审批，2019 年 3 月在确定无法通过后主动撤回。OSI 明确指出 SSPL 同时违反 OSD 第 5、6、9 条。从此 SSPL 被正式归类为「源码可见许可证，非开源」。Debian、Red Hat、Fedora 随后把 MongoDB 从软件仓库移除。

采用方：MongoDB（2018）、Elastic（2021 双协议）、Redis（2024）。

ELv2：Elastic 的简化版

Elastic License v2 是 Elastic 在 2021 年 2 月发布的，相比 1.0 版大幅简化。核心限制就两条：

  1. 禁止把软件作为托管服务提供给第三方（不能直接和 Elastic Cloud 竞争）
  2. 禁止绕过许可限制（比如不能移除许可证密钥检查）

ELv2 不强制 copyleft，所以嵌入应用不会触发传染。和 SSPL 搭配成双协议——用户二选一。OSI 没批准，原因还是第 6 条限制托管这一使用领域。

RSALv2：Redis 的版本

Redis Source Available License v2 在 2024 年 3 月 20 日发布。自 Redis 7.4 起，核心 Redis 从 BSD 3-Clause 改成 RSALv2 + SSPLv1 双协议。

RSALv2 是宽松型非 copyleft 的源码可见许可证：允许使用、复制、分发、修改、嵌入应用程序；禁止把软件作为托管服务提供给第三方（和 ELv2 类似）；不强制 copyleft，所以嵌入应用不传染。

FSL：Sentry 的标准化模板

Functional Source License 由 Sentry 在 2023 年 11 月推出，由 Sentry CEO David Cramer 和 Heather Meeker（没错，就是 BSL 起草那位）共同设计。FSL 想解决 BSL 的「每个项目实质是不同许可证」问题，提供标准化模板。

维度BSL 1.1FSL 1.1
转换期默认 4 年（可调）固定 2 年
Change License任意 GPL 兼容许可证仅 Apache 2.0 或 MIT
使用限制通过 Additional Use Grant 自定义固定定义「Competing Use」
可变性每个实施实质是不同许可证标准化模板，无变量
合规审核需逐案审查可批量批准

FSL 核心机制：定义「Permitted Purpose」（允许用途）——除「Competing Use」外的一切用途；定义「Competing Use」（竞争性使用）——用于和许可方软件竞争的商业产品或服务。2 年后每个版本自动转换成 Apache 2.0 或 MIT。

采用方：Sentry、Codecov、HashiCorp Boundary 部分组件、Liquibase。FSL 自我定位为「Fair Source」许可证，不再自称开源。但 OSI 仍未批准。

两个变种：PolyForm 和 Hippocratic

  • PolyForm 系列（2019，Heather Meeker 主导）：提供一堆用通俗英文撰写的源码可见许可证模板——Noncommercial（非商业）、Small Business（中小企业）、Strict、Perimeter、Trial、Internal Use 等等，覆盖不同使用场景。均未获 OSI 批准。
  • Hippocratic License（2019，Coraline Ada Ehmke）：在 MIT 基础上加道德条款——禁止把软件用于违反《联合国世界人权宣言》的活动。3.0 版（HL3，2021）做成模块化，核心条款保护人权，可选模块覆盖环境正义、劳工权利、媒体、军事、监视等。法律界普遍质疑可执行性，Bruce Perens 等批评者认为这些条款远远超出版权许可证可执行范围。OSI 未批准。

还有个老古董 JSON License——Douglas Crockford 2002 年写的，实质是 MIT 加一行：「The Software shall be used for Good, not Evil.」（本软件应用于善，不得用于恶。）就这一句，违反 OSD 第 6 条，被 FSF 和 OSI 都拒绝承认。Apache 基金会曾允许 JSON 许可证代码进入项目，后因歧义收紧；IBM 等公司内部干脆禁止使用 JSON.org 解析器，因为法务担心「Evil」定义模糊。

八年许可证战争：完整时间线

把 2018 到 2026 这八年的关键事件按时间排开，能看出整个行业的演化逻辑：

mermaid
timeline
    title 2018-2026 开源/源码可见许可证战争
    2018.10 : MongoDB : AGPL v3 → SSPL v1
             : 首个反 CSP 许可证
    2019.01 : AWS : 推出 DocumentDB
             : 干净实现绕过 AGPL
    2019.03 : MongoDB : 撤回 OSI 申请
    2021.01 : Elastic : Apache → SSPL + ELv2
    2021.04 : AWS : fork 出 OpenSearch
    2023.08 : HashiCorp : MPL → BSL 1.1
    2023.09 : OpenTofu : LF fork Terraform
    2023.11 : Sentry : BSL → FSL
    2024.03 : Redis : BSD → RSALv2 + SSPL
             : LF fork Valkey
    2024.04 : IBM : 64 亿美元收购 HashiCorp
    2024.08 : Elastic : 加 AGPL（三协议）
    2024.10 : OSI OSAID v1.0 发布
    2025    : Redis 8.0 加 AGPL（三协议）

时间线背后是三个固定模式：云厂商免费吃开源项目、项目改 Source Available 反击、Linux 基金会 fork 替代。下面四个案例把这套流程完整跑了一遍。

案例 1：Facebook React BSD+Patents（2016-2017）

React 在 BSD 许可证之外附带一个 PATENTS 文件，里面是「专利报复条款」：如果你对 Facebook 发起任何专利侵权诉讼，你立即失去使用 React 的专利授权。

这条款的风险是单向的——风险全压在被许可人这边，Facebook 不承担对等义务。Apache 基金会法务委员会 2017 年 7 月把 Facebook BSD+Patents 归入 Category X（禁止类），禁止 Apache 项目把它作为直接依赖。受影响的包括 RocksDB、Bahir。Automattic 的 Matt Mullenweg 同期宣布 WordPress 放弃基于 React 重写界面，原话是「我们不能把整个产品建立在 Facebook 可以单方面撤销专利授权的代码上」。

2017 年 9 月，Facebook 把 React、Jest、Flow、Immutable.js 全部改成 MIT 许可证。这是开源社区集体施压取得胜利的标志性案例。

案例 2：Elasticsearch 双协议 → AWS fork → 回归 AGPL

2010 年以来 Elasticsearch 一直是 Apache 2.0。2015 年 AWS 推出 Amazon Elasticsearch Service，直接基于 Elastic 开源代码做托管，收入几乎全归 AWS。双方互相指责对方「反 fork」。Elastic 2018 年把 X-Pack 安全/监控代码改成专有 Elastic License；AWS 2019 年推出 Open Distro for Elasticsearch 反击。

2021 年 1 月，Elastic 宣布 Elasticsearch 和 Kibana 从 Apache 2.0 改为 SSPL v1 + ELv2 双协议，用户二选一。博客标题是反讽的《Doubling Down on Open》（加倍开放）。OSI 董事会随后发表声明《The SSPL is Not an Open Source License》。

2021 年 4 月，AWS 基于 Elastic 7.10（最后一个 Apache 版本）fork 出 OpenSearch，保留 Apache 2.0，把 Amazon Elasticsearch Service 改名 Amazon OpenSearch Service。Logz.io、Aiven 等加入 OpenSearch 阵营。

2024 年 8 月，Shay Banon 发表《We are back open source》，新增 AGPL v3 作为第三个许可选项（SSPL + ELv2 + AGPL）。他给的理由是：（1）和 AWS 的关系已改善；（2）想赢回开源社区信任。同期 AWS 把 OpenSearch 捐给 Linux 基金会成立 OpenSearch Software Foundation。这是行业里第一次出现「许可证变更后又回归」的案例。

案例 3：MongoDB AGPL → SSPL（2018）

MongoDB 从 2009 年起用 AGPL v3，本来就是为了堵 SaaS 漏洞。但 AWS 走了第三条路：写一个干净的 reimplementation——Amazon DocumentDB（2019 年推出），只兼容 MongoDB API、不使用其源码，从而绕过 AGPL 的 copyleft。

MongoDB 于是自创 SSPL，把传染范围扩到整套服务栈。但这一招也没拦住 DocumentDB——它根本没用 MongoDB 源码。结果是双输：MongoDB 没拦住云厂商，反而被 Debian、Red Hat、Fedora 从仓库移除，社区贡献流量下降。2019 年 3 月，MongoDB 在确定无法通过后撤回 OSI 审批申请。

商业上 MongoDB 没明显损失，股价短暂下跌后恢复。SSPL 反而成了后续 Elasticsearch、Redis 的「许可证模板」。

案例 4：HashiCorp MPL → BSL（2023）

2023 年 8 月 10 日，HashiCorp 把 Terraform、Vault、Consul、Nomad、Packer、Boundary、Waypoint、Vagrant 全部核心产品从 MPL 2.0 改成 BSL 1.1。联合创始人 Armon Dadgar 公开点名 Spacelift、env0、Scalr 直接基于 Terraform 构建 SaaS 产品和 Terraform Cloud 竞争，「用我们造的工具和我们竞争不公平」。BSL 1.1 的核心约束是 Change Date 内（4 年）不得用于竞争性产品，4 年后自动转 MPL 2.0。

一个月后的 2023 年 9 月，Spacelift、env0、Harness、Gruntwork、Scalr 等公司宣布 fork 出 OpenTF（后改名 OpenTofu），2024 年 1 月正式成为 Linux Foundation 项目，保留 Apache 2.0。OpenTofu 1.7（2024 年 5 月）加入了原版 Terraform 没有的 state encryption 等特性。

Vault 的 fork 跟着到——2024 年 4 月 Linux Foundation 推出 OpenBao，保留 MPL 2.0，参与方有 GitLab、1Password、SUSE。

2024 年 4 月 IBM 宣布 64 亿美元收购 HashiCorp，2025 年 2 月完成交割。收购后许可证政策不变。OpenTofu 已经成为开源 IaC 的事实标准之一。

案例 5：Redis BSD → RSALv2+SSPL（2024）

2024 年 3 月 20 日，Redis 宣布自 Redis 7.4 起从 BSD 3-Clause 改成 RSALv2 + SSPL v1 双协议。理由和前几家一样：AWS ElastiCache、Google Cloud Memorystore、Azure Cache for Redis 多年来基于 Redis 提供托管服务，几乎不向上游贡献也不付费。

2024 年 4 月 1 日，Linux Foundation 宣布成立 Valkey，基于 Redis 7.2.4（最后 BSD 版本）fork，保留 BSD 3-Clause。背书方包括 AWS、Google Cloud、Oracle、Ericsson、Snap。原 Redis 核心维护者 Madelyn Olson（就职于 AWS）等转投 Valkey。Valkey 8.0（2024 年 9 月）引入多线程 I/O 改进，单节点吞吐提升 2-3 倍，开始和 Redis 在内核层面分叉。

AWS ElastiCache for Valkey 2024 年 10 月正式上线；Google Memorystore 2025 年增加 Valkey 选项；Oracle 同步支持。三大云厂商集体用 fork 替代原版。

2025 年 Redis 8.0 起新增 AGPL v3 作为第三个许可选项（RSALv2 + SSPLv1 + AGPLv3），跟随 Elastic 的「回归 AGPL」路线。

几条规律

跑完五场，能总结出几条几乎必然发生的规律：

  • Source Available 许可证几乎总会触发 fork。Linux 基金会已经实质成为「fork 孵化器」——OpenSearch、OpenTofu、OpenBao、Valkey 都出自它。
  • AGPL 重新被发现为「既 OSI 合规又能反云厂商」的选项。近两年 Elastic 和 Redis 都走这条路：Source Available + AGPL 三协议组合。AGPL 让云厂商要么公开自己代码、要么不托管。这是 2024-2025 出现的两条路径之一，是否扩展成行业范式还要看后续。
  • AGPL 的「网络条款」对 API 兼容的洁净室实现无效。MongoDB 的案例证明：云厂商可以写一个干净的兼容实现绕过 copyleft。「源码 copyleft」无法替代「商业模式护城河」。

AI 时代的许可证：三层法律性质

AI 模型比软件复杂——一个模型里同时存在三层法律性质完全不同的东西：权重（weights）、代码（code）、训练数据（training data）。传统软件许可证对其中任何一层都没有完美覆盖。

mermaid
flowchart TD
    M["AI 模型"] --> W["权重文件<br/>类似数据/产物"]
    M --> C["训练/推理代码<br/>传统软件"]
    M --> D["训练数据<br/>版权+数据库权"]

    W --> W1["LLaMA / Gemma<br/>自定义许可"]
    W --> W2["Falcon / Mistral<br/>Apache 2.0"]
    W --> W3["Stable Diffusion<br/>OpenRAIL-M"]
    C --> C1["通常 Apache 2.0<br/>或 MIT"]
    D --> D1["争议最大<br/>版权局报告 2025"]

    classDef base fill:#bbdefb,stroke:#2196F3,color:#0D4741
    classDef layer fill:#fff3e0,stroke:#FF9800,color:#BF360C
    classDef leaf fill:#c8e6c9,stroke:#4CAF50,color:#1B5E20
    class M base
    class W,C,D layer
    class W1,W2,W3,C1,D1 leaf

大模型许可证三个流派

自定义商业许可（带限制）——Meta 的 LLaMA 是代表。LLaMA 2（2023 年 7 月）允许商业使用，但月活用户超过 7 亿的公司必须向 Meta 单独申请付费许可；LLaMA 4（2025）维持 7 亿月活门槛，禁止欧盟用户使用或分发 Llama 4 模型；要求衍生模型名称以「Llama」开头；要求显示「Built with Llama」标识。Google 的 Gemma 类似，禁止特定有害用途分类，要求衍生作品继承相同条款。

纯 Apache 2.0（真正宽松开源）——少数派。Falcon 40B / 180B（TII）是早期少数采用纯 Apache 2.0 的大型 LLM 之一；Mistral 7B v0.1（2023 年 9 月）被认为是第一个「在 OSI 2024 AI 定义之外，几乎所有标准下都属开源」的商业重要模型；Mixtral 8x7B（2023 年 12 月）也是 Apache 2.0。但 Codestral 走非生产许可证，Mistral Large/Small 通过 API 的部分是专有商业条款——同一家公司内部不同模型许可证可能完全不同。

OpenRAIL 家族（带使用限制的类 copyleft）——由 RAIL Initiative（licenses.ai）设计。RAIL-A（应用程序）、RAIL-M（模型）、RAIL-S（源代码）；衍生包括 BigScience BLOOM RAIL 1.0、CreativeML OpenRAIL-M（Stable Diffusion）、CodeML OpenRAIL-M（BigCode）等。OpenRAIL 的关键特性：使用限制传染到所有衍生作品；OpenRAIL 自身声明不是 OSI 开源许可证（违反 OSD 第 6 条）。截至 2023 年 4 月，OpenRAIL 已成为仅次于宽松开源许可证的第二大类许可证。

OSAID 与未解决的争议

2024 年 10 月，OSI 正式发布 OSAID v1.0（Open Source AI Definition）。要求模型提供训练数据信息、模型架构、训练代码的访问。按这个定义，Llama、Gemma、Qwen 这些「开放」模型大多不符合 OSAID——因为它们要么不公开训练数据，要么限制商业用途。OSAID 本身行业内仍有争议，部分研究者认为门槛过高，部分厂商认为过严。

几个尚未解决的问题：

  • 训练数据版权：美国版权局 2025 年报告明确 AI 训练涉及复制权。多家版权方正在起诉 AI 公司，判决走向未定。
  • EU TDM 例外：欧盟文本与数据挖掘例外可能凌驾于 Share-Alike 条款之上，但解释空间大。
  • Open Washing（开源洗白）：模型自标「open」但实际有重大限制，引发反制。

耶鲁的 CCAI 提案（2026）

2026 年 6 月 15 日，耶鲁大学研究者 Grant Shanklin 在 Oxford International Journal of Law and IT 发表论文，提出 Contextual Copyleft AI License（CCAI）。核心机制：把生成式 AI 模型视为训练数据的衍生作品，要求 AI 开发者若在开源代码上训练模型，必须公开其模型架构和训练数据。这是把传统 copyleft 思路延伸到 AI 时代的一种学术提议，目前还不是法律或行业标准。是否被采纳、是否能落地，要看后续立法和判例。

开源许可证真的能在法院执行吗

很多人对开源许可证有一个误解：以为是社区公约，没有法律约束力。其实中美法院都已经明确判定过——开源许可证具有版权法上的可执行性。

美国：Jacobsen v. Katzer（2008-2010）

美国首例联邦上诉法院明确承认开源许可证可执行性的判例。Robert Jacobsen 是开源模型火车控制软件 JMRI 的作者，使用 Artistic License。Matthew Katzer / KAMIND Associates 没遵守 Artistic License 条款（未署名、未标注修改、未说明来源），就把代码纳入商业产品。

地区法院一审认为 Artistic License 是「合同约定」（covenant）而非「许可条件」（condition），违反只能主张合同违约。联邦巡回法院（CAFC）2008 年反转，明确裁定开源许可证的条件是版权许可的条件，违反即构成版权侵权，不仅仅是合同违约。法院认为开源许可证通过「开放分发 + 条件义务」换取版权使用授权，本质上是版权许可。

意义：证明「开源许可证无法在法院执行」是无稽之谈，为后续所有开源许可证诉讼奠定法律基础。

美国：Artifex v. Hancom（2016-2017）

Artifex Software 是 Ghostscript 的版权方（GPL v3）。韩国 Hancom 在其商业办公软件 Hancom Office 中集成了 Ghostscript，既没开源自己源码，也没购买商业许可证。Artifex 起诉，同时主张版权侵权和违反 GPL 的合同违约。

Hancom 辩称 GPL 只是版权许可，违反最多导致许可终止，不应承担合同违约。法官 Jacqueline Scott Corley 驳回撤案动议，裁定：用户下载软件即默认接受 GPL 条款，GPL 具有合同性质；GPL 的「源码公开义务」构成版权法之外的「额外要素」（extra element），合同违约主张可成立。

意义：法院首次明确 GPL 既是版权许可，也具有可执行的合同性质。每次分发使用 Ghostscript 的产品都必须提供或要约提供源码，许可终止后这个义务仍然持续。2017 年 12 月双方达成和解，具体条款保密。

美国：Oracle v. Google Java API 案（2010-2021）

争议焦点：API 是否受版权保护；Google 复制 Java SE 37 个 API 的声明代码用于 Android 是否构成合理使用。

十一年诉讼，多次反转：2012 年一审法院判 API 不受版权保护；2014 年 CAFC 反转，认定 API 可受版权保护，发回重审合理使用；2016 年陪审团判 Google 构成合理使用；2018 年 CAFC 再反转，判侵权；2021 年 4 月 5 日，美国最高法院以 6:2 判决 Google 胜诉，认定复制 11,500 行声明代码（仅占 Java SE 平台 0.4%）构成合理使用和转换性使用。

意义：确立了 API 复制可构成合理使用 的判例，但同时暗示 API 本身可受版权保护——对 clean-room 实现和兼容性开发留下长期不确定性。

中国：数字天堂「罗盒案」与 GPL 可执行性

中国法院也对开源许可证可执行性给出了标杆裁判。**数字天堂案（「罗盒案」）**是中国首例 GPL「不洁之手」抗辩案：法院明确认定 GPL 协议属于具有合同性质的法律关系，违反协议可导致许可终止，构成对上游的侵权；并基于「独立程序原则」（separate program doctrine）判断何为衍生作品。

2018 年北京知识产权法院作为一审法院，在软件著作权侵权案中被告援引 GPL-3.0 的 copyleft 机制作抗辩，法院虽未直接解读 GPL 条款，但暗示 GPL 在中国具有可执行性。

GPL 传染边界的关键争议

实务中最常被问的是：动态链接 GPL 代码到底算不算「衍生作品」？

FSF 的官方立场非常强硬——静态链接 GPL 代码 = 衍生作品，整体必须 GPL；动态链接 GPL 代码也构成衍生作品，整体必须 GPL；只有通过管道、socket、命令行通信的独立程序才算「聚合体」（aggregate），不传染。

但法律上「衍生作品」定义未明，FSF 的扩张解释未必被法院全部采纳。Linux 内核有 syscalls 例外（明确允许非 GPL 程序通过系统调用使用内核）；LGPL 设计就是为允许动态链接而不传染。实务建议：想保留闭源，要么用 LGPL，要么走 IPC 通信，要么洁净室重写。试图通过「动态链接」绕过 GPL 是重大法律风险。

一份企业选型合规清单

引入新依赖前必检

第一步：识别许可证类型

  • 查看 LICENSE 文件
  • 查看 package.json / pom.xml / Cargo.toml 等元数据
  • 检查依赖项的所有许可证（包括传递依赖）
  • 区分 OSI 开源 / Source Available / 专有——看到 BSL/SSPL/ELv2/RSALv2/FSL 立刻警觉

第二步：评估合规义务

  • 宽松型（MIT/BSD/Apache）：保留版权声明；Apache 额外遵守 NOTICE 和变更声明
  • 弱 copyleft（MPL/LGPL/EPL）：修改部分须开源，新增部分可闭源
  • 强 copyleft（GPL）：衍生作品整体须 GPL；警惕动态链接陷阱
  • 最强 copyleft（AGPL）：SaaS 部署也触发开源义务
  • Source Available（BSL/SSPL/ELv2/RSALv2/FSL）：评估「竞争性使用」条款、Change Date

第三步：识别专利风险

  • 是否触发专利反制条款（Apache/MPL/GPL v3/EPL/CDDL）
  • 是否需要购买商业专利许可
  • 是否需向公司法务报备

第四步：建立 SBOM（软件物料清单）

  • 使用 SPDX / CycloneDX 标准记录所有依赖的许可证
  • 每次发版前自动扫描许可证变化
  • 部署 FOSSA / Snyk License / Black Duck 等扫描工具

常见踩坑对照表

风险后果防范
误把 BSL/SSPL 当开源商业使用违约，面临法律索赔严格区分 OSI 批准 vs Source Available
商业产品链接 GPL 代码必须整体开源或承担版权+合同违约优先 LGPL；动态链接也传染
SaaS 部署 AGPL 修改版必须向所有用户公开修改源码评估是否真需修改；或与原项目签商业协议
未保留 LICENSE 副本违反任何开源许可证的基本义务自动化构建工具嵌入 NOTICE
在 NOTICE 文件移除原作者声明违反 Apache 2.0 第 4d 条严格保留 + 追加，不删
使用 JSON License 代码部分公司（如 IBM）内部禁止避免 JSON.org 解析器
在欧盟部署 Llama 4违反许可协议选用 Apache 2.0 模型如 Mistral
不明 GPL 传染范围衍生作品须开源，被诉讼优先 LGPL；走 IPC 通信

已经发生的合规趋势

几个不是预测、而是已经发生的事实，工程团队需要跟进：

  • 欧盟 Cyber Resilience Act 已要求 SBOM。这意味着在欧洲市场销售的软件产品，提供 SBOM 是法定义务，不是可选项。
  • 三协议组合（Source Available + AGPL）已成近两年新实践。Elastic 和 Redis 都这么干，预计后续还有公司跟进。
  • OSI 推广 OSAID，OpenRAIL 家族继续扩展。AI 模型许可证与传统开源许可证的边界会越来越清晰。
  • 企业合规自动化：FOSSA、Snyk License 这类工具正在成为研发流水线标配。

参考链接

官方权威源：

  • SPDX License List v3.28.0：https://spdx.org/licenses/
  • OSI 已批准许可证：https://opensource.org/licenses/alphabetical
  • OSI OSAID v1.0（2024-10）：https://opensource.org/ai

Source Available 许可证：

  • MariaDB BSL 1.1：https://mariadb.com/bsl11/
  • MongoDB SSPL FAQ：https://www.mongodb.com/legal/licensing/server-side-public-license/faq
  • Elastic License v2：https://www.elastic.co/es/blog/elastic-license-v2
  • Sentry FSL：https://blog.sentry.io/introducing-the-functional-source-license-freedom-without-free-riding/
  • FSL 官方：https://fsl.software/
  • Fair Source 定义：https://fair.io/about/
  • PolyForm Project：https://polyformproject.org/why-adopt-polyform

历史案例文档：

  • Apache 禁止 Facebook BSD+Patents — LWN.net：https://lwn.net/Articles/728293/
  • The SSPL is Not an Open Source License — OSI Blog：https://opensource.org/blog/the-sspl-is-not-an-open-source-license
  • Amazon Forks Elasticsearch as OpenSearch — InfoQ：https://www.infoq.com/news/2021/04/amazon-opensearch/
  • HashiCorp Licensing FAQ：https://www.hashicorp.com/license-faq
  • Redis Adopts Dual Source-Available Licensing：https://redis.io/blog/redis-adopts-dual-source-available-licensing.md

判例与 AI 许可证：

  • Artifex v. Hancom 案 — FSF：https://www.fsf.org/blogs/licensing/update-on-artifex-v-hancom-gnu-gpl-compliance-case-1
  • JACOBSEN v. KATZER 判决：https://lawcat.berkeley.edu/record/1122274/files/fulltext.pdf
  • Google v. Oracle 合理使用摘要：https://www.copyright.gov/fair-use/summaries/Google-LLC-v-Oracle-Am-Inc-141-S-Ct-1183-2021.pdf
  • RAIL Initiative FAQ：https://www.licenses.ai/faq-2
  • Shanklin, “The Case for Contextual Copyleft,” Oxford IJLIT（2026）：https://academic.oup.com/ijlit/article-abstract/doi/10.1093/ijlit/eaag003/8460592

上一篇《主流开源许可证全景：从 MIT 到 AGPL，工程师该怎么选》讲了 14 种 OSI 开源许可证的传染边界和选型逻辑；本篇把 Source Available 和 AI 这条线补上。两篇合起来，是工程团队处理开源许可证问题时的基础地图。

所属系列: 开源与工程决策系列
← 上一篇 主流开源许可证全景：从 MIT 到 AGPL，工程师该怎么选