土法炼钢兴趣小组的算法知识备份

【开源许可与版权工程】专利授权与商标：Apache 2.0、GPLv3 与「兼容性」陷阱

2026-04-22 · architecture · opensource · #patent #trademark #apache2 #gplv3 #compatibility #firefox #rocky-linux #redhat #npe

文章导航

分类入口
architectureopensource
标签入口
#patent#trademark#apache2#gplv3#compatibility#firefox#rocky-linux#redhat#npe

目录

开源世界里，许可证的名字往往被当作”标签”贴在 README 上，真正让企业法务、合规官以及架构师夜不能寐的，从来不是许可证名字本身，而是它背后的两类隐性权利：专利（Patent） 与 商标（Trademark）。前者决定了谁能在法律上阻止你实施某段代码所体现的技术方案；后者决定了谁能在市场上阻止你以某个名字出售、分发、甚至讨论这段代码。两者与版权（Copyright）一起，共同构成软件知识产权（Intellectual Property，IP）的”三驾马车”，却在开源许可证文本中被处理得极不对称。

本篇是《开源许可与版权工程》系列的第五篇，承接上一篇《Copyleft 的工程边界：动态链接、容器、SaaS 算不算”分发”》对 Copyleft 动态边界的讨论，聚焦这两个最容易被工程团队忽视、却在真实纠纷中反复出现的议题。我们将从 Apache License 2.0 的第三节（§3）与 GPLv3 的第十一节（§11）出发，穿过 2006 年震动开源社区的 Microsoft-Novell 事件，回到 Linux 内核为何拒绝合并 Apache 2.0 代码这一工程现实，并在最后讨论 Firefox／IceWeasel、Rocky Linux、红旗 Linux、华为加入开放发明网络（Open Invention Network，OIN）等真实案例。

一、专利授权的基础：版权保护表达，专利保护思想

1.1 版权与专利的根本差异

在讨论任何开源许可证的专利条款之前，必须先厘清一个常被混淆的事实：版权（Copyright）与专利（Patent）保护的对象完全不同。

对开源工程师而言，这意味着一个反直觉的结论：你可能在完全合法地遵守了 MIT 许可证的版权要求的同时，被同一份代码的贡献者以专利名义起诉。因为 MIT 许可证只授予了版权层面的使用权，并未明确授予专利许可。

可以用一个对照表进一步厘清：

维度 版权（Copyright） 专利（Patent） 商标（Trademark）
保护对象 具体表达（代码、文档、图片） 技术方案（算法、流程、系统） 商业标识（名称、Logo、口号）
产生方式 创作完成自动产生 申请审查授权 申请注册或使用在先
保护期限 作者终生 + 数十年 发明专利约 20 年 可续展，理论上永续
侵权判断 实质性相似 + 接触 权利要求的字面或等同 近似 + 混淆可能性
独立创作抗辩 成立 不成立 不一定成立
开源许可证是否处理 始终处理 部分许可证处理 普遍不处理

注意最后一行：开源许可证对”三驾马车”的处理极不对称——版权 100% 覆盖，专利取决于许可证版本，商标几乎完全不覆盖。这种不对称正是本文要穿透的核心迷雾。

1.2 软件专利的特殊性

软件专利在不同司法辖区的可专利性差异极大：

软件专利在全球分布极不均匀。据 WIPO 公开的年度报告，近十年”数字通信”与”计算机技术”一直是 PCT 国际申请量最高的两个技术领域，合计占全球申请量的三分之一以上。这些专利相当一部分涉及开源社区广泛使用的技术（视频编解码、加密协议、分布式存储、机器学习）。开源代码的传播速度远快于专利检索能力——这就是为什么即便你做了”善意尽职调查”，仍可能在不知情的情况下落入专利保护范围。

1.3 开源许可证为何需要专利条款

考虑一个真实存在的风险模型：

场景一：无专利条款的许可证
---------------------------------------
Alice 是某公司的员工，公司持有专利 P。
Alice 将一段实现 P 的代码以 MIT 许可证贡献到开源项目 X。
Bob 的公司下载了项目 X，并在商业产品中使用。
Alice 的公司以专利 P 起诉 Bob 的公司。

问：Bob 有没有抗辩？
答：MIT 许可证只授予版权许可，未授予专利许可。
     Alice 的公司在理论上仍可主张专利权，
     Bob 的抗辩需要依赖"默示许可（implied license）"
     这一较弱的普通法法理，结果不确定。

这正是 Apache Software Foundation（ASF）在 2004 年将 Apache License 从 1.1 升级到 2.0 时，坚持加入专利条款的核心动机。也是自由软件基金会（Free Software Foundation，FSF）在 2007 年将 GPL 从 v2 升级到 v3 时，花费大量篇幅撰写 §11 的动机。

没有专利条款的许可证——典型如 MIT、BSD 2-Clause、BSD 3-Clause、ISC——本质上把专利风险留给了”默示许可”这一司法解释。对于商业团队而言，这是一个不应接受的默认风险敞口。

1.4 “默示许可”的法律强度

“默示许可（implied license）”是普通法系下的一种救济机制：当权利人的行为让合理的第三方相信其授予了使用权时，法院可以认定存在默示许可。在开源场景下，常见的论证是：

但这条论证路径有几个脆弱点：

  1. 不是所有司法辖区都承认：大陆法系（包括中国、德国、日本）对默示许可的认定更严格，通常要求明示；
  2. 范围难以确定：即使承认默示许可，其覆盖的具体专利权利要求、使用方式、衍生作品权利都需要案件级论证；
  3. 在专利诉讼实务中，默示许可抗辩的成功率远低于显式许可；
  4. 贡献者雇主的态度不确定：如果雇主声明”员工贡献仅代表个人”，则”权利人”是否知情就成了反方质疑的靶点。

也就是说，“默示许可”只是没有更好选项时的后备抗辩，而不是健壮的合规基础。Apache 2.0、GPLv3、MPL 2.0 提供的显式专利授权，就是在把这个”脆弱抗辩”替换成”条款级抗辩”。

二、Apache License 2.0 §3：显式专利授权与专利报复

2.1 条款原文结构

Apache License 2.0 的第三节标题为 “Grant of Patent License”，其核心结构可拆解为三段：

  1. 授权范围：每个贡献者（Contributor）向被许可方（Licensee）授予一项”永久的、全球性的、非独占的、免费的、免版税的、不可撤销的（但受本节限制）“专利许可。
  2. 授权内容：覆盖贡献者拥有或可以许可的、被贡献（Contribution）本身或贡献与作品（Work）的组合所”必然侵犯”的专利权利要求。
  3. 授权动作：使用（make）、使已被制造（have made）、使用（use）、提供销售（offer to sell）、销售（sell）、进口（import）、以及其他方式转让（transfer）该作品。

对应的英文原文片段如下（引自 Apache License 2.0 官方文本）：

3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted.

2.2 专利报复条款（Patent Retaliation）

§3 的第二段是工程团队最容易忽略、法务团队最敏感的部分：

If You institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.

翻译成工程语言：

如果你（被许可方）对”任何实体”提起专利诉讼，指控本作品或其中的贡献构成直接侵权或帮助侵权，那么你从本许可证获得的针对该作品的所有专利许可，在起诉之日自动终止。

这个条款有三个关键特征：

  1. 范围限定”该作品”：被终止的是你在本作品中获得的专利许可，而不是贡献者对其他所有人已经授予的专利许可。项目本身对其他用户仍然有效。
  2. 触发条件是”与作品或贡献相关的专利诉讼”：如果你因完全无关的专利起诉同一家公司，不会触发终止。
  3. 包括反诉与交叉诉讼：你不能通过被人起诉后反诉的方式规避。

这是一种”和平条款”：你可以继续使用 Apache 2.0 项目，只要你不拿项目中的技术去起诉项目的其他参与者。

2.3 “必然侵犯（necessarily infringed）”的范围

Apache 2.0 §3 中 “necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work” 这一表述非常关键，它限定了授权的专利范围：

举例说明：

假设贡献者 C 持有专利 P1（一种 KV 缓存淘汰算法）
              和专利 P2（一种 SQL 查询优化算法）

C 向 Apache 项目 X（一个缓存库）贡献了 P1 的实现。
     → §3 授予的专利许可覆盖 P1（因为 X 必然侵犯 P1）
     → §3 不覆盖 P2（因为 X 与 P2 无关）

后来 C 将 X 与自己的 SQL 引擎合并做了一个新产品，
该产品也实施了 P2。
     → 这不是"X 与其他贡献的组合"，
       而是"X 与第三方软件的组合"，
       §3 不自动扩展到 P2。

这一限定是 Apache 2.0 与 GPLv3 §11 在专利范围上的差异之一。

2.4 “have made” 的供应链含义

Apache 2.0 §3 授权中的 “have made” 字面含义是”使已被制造”，在专利法实务中指代工生产场景：

在开源软件供应链中，这意味着：

这些”代为实施”行为都在贡献者的专利授权覆盖之下，无需每一方单独与贡献者达成许可。

2.5 与 GPL 系列的专利报复比较

GPLv2 完全没有专利报复条款，甚至没有明确的专利授权条款（仅在序言中模糊提到”任何专利必须以允许所有人免费使用的方式授权，或根本不授权”）。这导致在 2000 年代中后期，大量采用 GPLv2 的项目暴露在专利诉讼风险中。

Apache 2.0（2004 年）首次在主流许可证中引入专利报复条款。GPLv3（2007 年）在此基础上设计了更复杂的 §11，包含：

可以用一个对照表总结：

许可证 专利授权 专利报复 歧视性专利协议禁止
MIT / BSD / ISC 无显式 无 无
Apache 2.0 §3 显式 §3 有 无
GPLv2 无显式（仅序言) 无 无
GPLv3 / AGPLv3 §11 显式 §11 有 §11 有
LGPLv3 引用 GPLv3 §11 同 GPLv3 同 GPLv3
MPL 2.0 §2.1(b) 显式 §5.2 有 无

三、GPLv3 §11：Microsoft-Novell 事件与”不起诉承诺”

3.1 事件始末（2006 年 11 月）

2006 年 11 月 2 日，Microsoft 与 Novell 联合宣布一项合作协议。其中最具争议的部分可以概括为：

这项协议立刻在开源社区引发剧烈反应：

3.2 FSF 的回应与 GPLv3 §11

当时 GPLv3 的起草尚在进行中（2006 年已发布多版草案）。Microsoft-Novell 事件直接促成了 GPLv3 §11 中两段关键文字的加入：

You may not convey a covered work if you are a party to an
arrangement with a third party that is in the business of
distributing software, under which you make payment to the third
party based on the extent of your activity of conveying the work,
and under which the third party grants, to any of the parties who
would receive the covered work from you, a discriminatory patent
license ...

翻译大意：

如果你是某项安排的当事方，该安排的对方是分发软件业务的第三方，你根据分发本作品的规模向其付费，且该第三方向你下游的部分接收者授予了”歧视性的专利许可”（即只给你的客户、不给所有用户），那么你不得继续分发本作品。

这正是针对”Microsoft 只给 Novell 客户不起诉承诺”这种模式的定向约束。注意这段条款还有一个追溯性条款：

... unless you entered into that arrangement, or that patent
license was granted, prior to 28 March 2007.

即 2007 年 3 月 28 日之前签订的协议不溯及——这被社区戏称为”Novell 特赦条款”。

3.3 §11 的下游保护链

GPLv3 §11 除了”反 Novell 条款”外，还要求：

用一张图可以更直观地理解这个”专利保护链”：

专利授权条款与兼容性关系

图中可以看到：

四、GPLv2 与 Apache 2.0 的兼容性陷阱

4.1 历史判断：FSF 如何看待冲突

GPLv2 的兼容性规则见于其 §7：被许可方不得接受任何”进一步的限制（further restrictions）“。FSF 在 2004 年对 Apache License 2.0 的初始评估中认为：

这个判断至今仍然写在 FSF 的许可证兼容性说明页上。虽然在纯法律解读上有争议（Apache Software Foundation 自身的立场更温和），但在实践中几乎所有严肃项目都采信 FSF 的判断，以保守策略处理。

4.2 GPLv3 与 Apache 2.0 的兼容

GPLv3 在起草过程中主动放宽了”附加限制”的定义。GPLv3 §7 明确列出了”允许的附加条款”，其中包括：

c) Prohibiting misrepresentation of the origin of that material,
   or requiring that modified versions of such material be marked
   in reasonable ways as different from the original version; or

d) Limiting the use for publicity purposes of names of licensors
   or authors of the material; or

...

更重要的是，GPLv3 §11 的专利报复机制与 Apache 2.0 §3 的机制在设计时互相协调，FSF 在 GPLv3 发布时明确声明：

Apache License 2.0 is compatible with GPLv3 (but not GPLv2).

这是 GPLv3 相对于 GPLv2 最重要的兼容性升级之一。

4.3 工程后果：Linux 内核为什么不能合并 Apache 代码

Linux 内核采用的是 GPLv2-only（仅限 v2，不允许”or later”升级），这一决定由 Linus Torvalds 在 1990 年代中期明确做出，并延续至今。这带来一个直接后果：

这一限制在 Android 项目中有清晰的体现：

这不是偶然选择，而是 Google 在 2008 年前后为规避 GPL 病毒性传染而精心设计的架构（详见《Copyleft 的工程边界》中关于动态链接与进程边界的讨论）。

4.4 一个可落地的兼容性判定表

对于绝大多数企业内部代码仓库，可以用下面这张表作为快速判定：

上游许可证 下游许可证（你的项目） 是否兼容 说明
MIT / BSD / ISC GPLv2 / GPLv3 / AGPLv3 兼容 宽松许可证向强 Copyleft 单向兼容
Apache 2.0 GPLv2-only 不兼容 FSF 明确判定
Apache 2.0 GPLv2-or-later 兼容（走 GPLv3 路径） 可自动升级到 GPLv3
Apache 2.0 GPLv3 / AGPLv3 兼容 GPLv3 §11 与 Apache §3 协调
GPLv2-only GPLv3 不兼容 两者均为 Copyleft，许可证条款互相要求优先
GPLv3 AGPLv3 兼容（单向） AGPL 是 GPLv3 的超集
MPL 2.0 GPLv2+ / GPLv3 / AGPLv3 兼容（MPL 2.0 §3.3） MPL 2.0 专门设计为可与 GPL 组合

更多细节参见本系列《开源许可证分类学》与后续的《MIT、BSD、Apache 2.0：宽松许可证的真实区别》《GPL 与 LGPL：什么是真正的 Copyleft》。

五、商标条款：开源许可证管不到的独立 IP

5.1 版权与商标的分离

开源许可证几乎无一例外地只管理版权（以及可能的专利），不管理商标。最典型的是 Apache License 2.0 §6：

6. Trademarks. This License does not grant permission to use
the trade names, trademarks, service marks, or product names of
the Licensor, except as required for describing the origin of the
Work and reproducing the content of the NOTICE file.

GPLv3 在 §7 允许分发者附加”限制对商标名称用于宣传的额外条款”。也就是说：即使你完全合法地使用了开源代码，也不意味着你有权使用该项目的名字、Logo、或相关品牌。

这是企业团队最容易踩的坑。下面是几个最具教育意义的案例。

5.2 Firefox 与 Debian IceWeasel 事件

Mozilla Firefox 采用 MPL 2.0（早期为 MPL 1.1 + GPL + LGPL 三重许可），代码完全开源。但 Mozilla 对 “Firefox” 这一名称和狐狸地球 Logo 持有商标权，并通过《Mozilla Trademark Policy》约束使用。

Mozilla 的商标政策要求：

Debian 的政策（Debian Free Software Guidelines，DFSG）则要求：

结果是 2006 年 Debian 将其 Firefox 分支重命名为 IceWeasel（冰鼬），Logo 也替换成冰雪色调的白鼬。这一分裂持续了约十年。2016 年 2 月，Debian 与 Mozilla 达成新协议，Debian 在遵守修改后的商标政策（允许发行版适配的合理修改）前提下恢复使用 “Firefox” 名称，IceWeasel 合并回 Firefox。

这件事的工程与合规教训非常清晰：

5.3 Red Hat、CentOS 与 Rocky Linux：代码可开源，商标不可用

Red Hat Enterprise Linux（RHEL）长期以来的商业模式建立在一个精细的设计上：

CentOS 在最初（由 Gregory Kurtzer 等人于 2004 年前后创建）的做法是：

  1. 从 Red Hat 发布的 SRPM（Source RPM）下载源码；
  2. 剥离所有 Red Hat 商标、Logo、品牌元素；
  3. 重新编译并以 “CentOS” 名义发布。

这种做法完全合法，因为 Red Hat 并未在许可证上施加”不得重新编译”的限制，只要求不得使用其商标。这也是”下游克隆版”（downstream rebuild）模式的由来。

2014 年，Red Hat 收购 CentOS 项目；2020 年底宣布 CentOS 8 将在 2021 年底结束维护，CentOS 的未来形态转为 CentOS Stream（RHEL 的上游滚动版本，而非下游稳定版）。这引发了大规模社区反弹，并直接催生两个替代项目：

2023 年 6 月，Red Hat 宣布限制 RHEL 源代码的获取，仅订阅客户可通过 Red Hat Customer Portal 访问 SRPM。这一政策调整直接影响了 Rocky Linux 与 AlmaLinux 的”从 SRPM 下游克隆”模式：

注意贯穿整个事件的一条主线：代码的许可证没有变，商标的态度变了。Red Hat 并没有（也无法）通过修改 GPL 来阻止下游克隆，但可以通过商标政策、订阅协议、容器镜像分发条款等”非许可证手段”调整博弈格局。更完整的技术与合规分析见本系列《CentOS→CentOS Stream 与 Rocky Linux 案例》。

5.4 红帽商标政策要点

Red Hat 的商标政策（Trademark Guidelines）对开源工程团队特别需要注意的几点：

六、中国案例：红旗 Linux 与国内商标实务

6.1 红旗 Linux 的历史

红旗 Linux（Red Flag Linux）是中国最具标志性的本土 Linux 发行版之一。其主要发展节点（均为公开资料可查证）：

对这段历史，对当代工程团队的启示有三：

  1. 开源许可证不能保证一个发行版在商业上存续。源码的永续性与商业实体的存续性是两回事；
  2. 商标权的转让可以让”同一个名字”在不同主体间漂移。企业在采购或引用”国产操作系统”时，应核查当前商标持有主体、实际研发团队、以及与历史品牌的法律关联；
  3. 底层仍然是 Linux + 大量开源组件，GPL、LGPL、Apache、MIT 的合规要求并不会因为壳是”国产”就消失。

6.2 CentOS 商标在国内的使用注意事项

在国内，不少云厂商、一体机厂商历史上以”CentOS 兼容”、“基于 CentOS”为卖点。2023 年 Red Hat 调整 RHEL 源码获取政策后，国内有几个实务变化值得留意：

七、专利流氓（NPE）对国内开源使用的潜在风险

7.1 什么是 NPE

NPE（Non-Practicing Entity）是指不从事实际生产经营、主要依靠持有专利并通过诉讼或许可谈判获取收入的实体，俗称”专利流氓（Patent Troll）“。典型特征：

7.2 开源许可证对 NPE 无效

必须强调一个容易被误解的事实：

也就是说，即使你严格遵守了 Apache 2.0 的一切要求，使用了代码、留下了 NOTICE、附加了许可证文本，一家持有相关专利、但从未参与过该项目的 NPE，仍然可以在美国或其他司法辖区对你提起专利侵权诉讼。

7.3 Open Invention Network（OIN）

Open Invention Network（OIN，开放发明网络）成立于 2005 年，由 IBM、Sony、Philips、Red Hat、Novell 等公司联合发起。其核心机制是：

OIN 的”Linux System Definition”是一个动态列表，历年来不断扩充，已覆盖 Linux 内核、主要发行版、Android AOSP、大部分 Apache 基金会顶级项目、OpenJDK、Kubernetes 等。

国内企业加入 OIN 的代表性事件：

这些企业加入 OIN 的商业动机可以从多个角度理解：

  1. 防御性措施：OIN 成员池的专利互授，降低被其他成员起诉的风险；
  2. 出海合规信号：向欧美市场与开源社区表明在 Linux 相关技术上不采取攻击性专利策略；
  3. 社区信任：成为贡献者身份之外的”开源生态参与者”信号。

加入 OIN 不解决 NPE 问题（NPE 很少是 OIN 成员），但确实降低了”大厂互相起诉 Linux”的系统性风险。这也是出海企业在专利策略中的基础动作之一，具体与出口管制、合规的关系见后续《出口管制与开源合规》。

八、工程坑点与代码示例

8.1 SPDX 许可证标识的精确写法

在企业仓库中，许可证标识的模糊会直接导致兼容性判定失败。推荐使用 SPDX License Expression 规范：

// SPDX-License-Identifier: Apache-2.0
// SPDX-License-Identifier: GPL-2.0-only
// SPDX-License-Identifier: GPL-2.0-or-later
// SPDX-License-Identifier: GPL-3.0-or-later
// SPDX-License-Identifier: (Apache-2.0 OR MIT)
// SPDX-License-Identifier: (GPL-2.0-or-later WITH Linux-syscall-note)

需要特别注意：

8.2 CI 中的许可证扫描

一个基于 FOSSA / ScanCode / REUSE 的 CI 工作流示例（GitHub Actions）：

name: license-compliance

on:
  pull_request:
  push:
    branches: [main]

jobs:
  reuse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: REUSE compliance
        uses: fsfe/reuse-action@v3

  scancode:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"
      - name: Install ScanCode Toolkit
        run: pip install scancode-toolkit
      - name: Scan
        run: |
          scancode --license --copyright --package \
            --json-pp scan-result.json \
            --processes 4 \
            --timeout 600 \
            ./
      - name: Upload report
        uses: actions/upload-artifact@v4
        with:
          name: scancode-report
          path: scan-result.json

这个工作流的作用是：

8.3 NOTICE 文件自动生成

Apache 2.0 §4(d) 要求在分发时保留 NOTICE 文件的内容。对于 Java 项目，Maven 的 license-maven-plugin 配置如下：

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>license-maven-plugin</artifactId>
  <version>2.4.0</version>
  <executions>
    <execution>
      <id>aggregate-third-party-report</id>
      <phase>generate-resources</phase>
      <goals>
        <goal>aggregate-add-third-party</goal>
      </goals>
      <configuration>
        <outputDirectory>${project.build.directory}/generated-notice</outputDirectory>
        <thirdPartyFilename>THIRD-PARTY.txt</thirdPartyFilename>
        <useMissingFile>true</useMissingFile>
        <failOnMissing>true</failOnMissing>
        <includedLicenses>
          <includedLicense>Apache-2.0</includedLicense>
          <includedLicense>MIT</includedLicense>
          <includedLicense>BSD-3-Clause</includedLicense>
          <includedLicense>BSD-2-Clause</includedLicense>
          <includedLicense>ISC</includedLicense>
          <includedLicense>MPL-2.0</includedLicense>
          <includedLicense>EPL-2.0</includedLicense>
        </includedLicenses>
        <excludedLicenses>
          <excludedLicense>GPL-2.0-only</excludedLicense>
          <excludedLicense>GPL-3.0-only</excludedLicense>
          <excludedLicense>AGPL-3.0-only</excludedLicense>
        </excludedLicenses>
      </configuration>
    </execution>
  </executions>
</plugin>

对于 Node.js 项目，使用 license-checker-rseidelsohn：

npx license-checker-rseidelsohn \
  --production \
  --onlyAllow "MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC;MPL-2.0;CC0-1.0" \
  --excludePackages "some-internal-pkg" \
  --json > third-party-licenses.json

这段配置的效果是：一旦引入一个 GPL 依赖（例如某个无意间被传递依赖拉入的包），npm run build 会直接失败，从源头拦截专利 / Copyleft 风险。

8.4 对 “GPLv2-only” 的处理

Linux 内核、Busybox 等关键项目采用 GPLv2-only。如果你的项目是：

则必须确保项目中任何链接进同一可执行文件 / 内核模块的代码不得以 Apache 2.0、GPLv3、MPL 2.0 等与 GPLv2 不兼容的许可证发布。推荐在 SBOM（软件物料清单，Software Bill of Materials）扫描中设置以下规则：

# policy.yaml (示意)
rules:
  - id: no-apache-in-kernel-module
    match:
      component_type: kernel-module
      license: Apache-2.0
    action: fail
    message: "Apache-2.0 is not compatible with GPL-2.0-only kernel"

  - id: no-gpl3-in-kernel
    match:
      component_type: kernel-module
      license: [GPL-3.0-only, GPL-3.0-or-later, AGPL-3.0-only]
    action: fail
    message: "GPL-3.0 is not compatible with Linux kernel's GPL-2.0-only"

8.5 商标使用的自检清单

在发布任何基于开源项目的产品前，用下列清单自检：

[ ] 产品名称是否包含上游项目商标？（如 "Kubernetes"、"Kafka"、"RedHat"、"CentOS"、"Firefox"）
[ ] 产品 Logo 是否复用了上游 Logo 的图形元素？
[ ] 官网、文档、控制台 UI 中是否有可能误导用户以为是上游官方产品的表述？
[ ] 是否使用了 "Official"、"Enterprise"、"Certified" 等易引起授权关系误解的修饰词？
[ ] 容器镜像名、Helm Chart 名、npm / PyPI 包名是否包含上游商标？
[ ] 是否在合同、招投标材料中承诺了实际上依赖于上游商标持有者的能力？

任何一项为 “是”，都应请法务介入评估。

8.6 专利报复条款的触发案例推演

下面用一段伪代码展示 Apache 2.0 §3 专利报复的触发逻辑，帮助工程团队建立直觉：

class PatentRetaliationChecker:
    """Apache 2.0 §3 专利报复条款状态机"""

    def __init__(self, licensee, work):
        self.licensee = licensee
        self.work = work
        self.patent_license_active = True

    def evaluate_lawsuit(self, plaintiff, defendant, claim):
        """
        判断一次专利诉讼是否触发 §3 专利许可终止
        """
        # 必须是被许可方作为原告
        if plaintiff != self.licensee:
            return "不触发：被许可方不是原告"

        # 包括交叉诉讼与反诉
        is_direct_suit = claim.type in (
            "direct_complaint",
            "counterclaim",
            "cross_claim",
        )
        if not is_direct_suit:
            return "不触发：非专利诉讼类型"

        # 必须指控本作品或其中贡献构成侵权
        target = claim.alleged_infringement_target
        if not self._is_about_this_work(target):
            return "不触发：与本作品无关"

        # 构成直接侵权或帮助侵权指控
        if claim.infringement_type not in (
            "direct_infringement",
            "contributory_infringement",
        ):
            return "不触发：非直接/帮助侵权类型"

        # 触发！
        self.patent_license_active = False
        return "触发：自起诉之日起，该被许可方的专利许可终止"

    def _is_about_this_work(self, target):
        return (
            target == self.work
            or target in self.work.contributions
        )

这段伪代码的逻辑映射到 §3 条款文字：

8.7 SBOM 中的专利元数据

SPDX 2.3 及以上版本支持在 SBOM 中表达专利相关信息。以下是一个示例片段（JSON 格式）：

{
  "spdxVersion": "SPDX-2.3",
  "SPDXID": "SPDXRef-DOCUMENT",
  "name": "example-product-1.2.3",
  "packages": [
    {
      "SPDXID": "SPDXRef-Package-Apache-Kafka",
      "name": "kafka-clients",
      "versionInfo": "3.6.0",
      "licenseConcluded": "Apache-2.0",
      "licenseDeclared": "Apache-2.0",
      "supplier": "Organization: Apache Software Foundation",
      "downloadLocation": "https://repo1.maven.org/maven2/org/apache/kafka/kafka-clients/3.6.0/",
      "attributionTexts": [
        "Apache Kafka, Copyright 2014-2023 The Apache Software Foundation",
        "This product includes software developed at The Apache Software Foundation (http://www.apache.org/)."
      ]
    }
  ],
  "hasExtractedLicensingInfos": [],
  "relationships": []
}

对企业 SBOM 治理的建议：

8.8 容器镜像与多层许可证

容器镜像是典型的”多层组件组合”，其许可证处理需要分层看：

# 基础层：Debian（多种许可证），Alpine（主要 MIT/BSD）
FROM alpine:3.19

# 中间层：运行时（JRE / Python / Node）
# OpenJDK 是 GPLv2+CE (Classpath Exception)
# CPython 是 PSF License (类 BSD)
# Node.js 是 MIT
RUN apk add --no-cache openjdk17-jre

# 应用层：企业自己的代码（任意许可证）
COPY target/app.jar /opt/app.jar

# 配置与元数据
LABEL org.opencontainers.image.licenses="Apache-2.0"
LABEL org.opencontainers.image.source="https://github.com/example/app"
LABEL org.opencontainers.image.vendor="Example Inc."

ENTRYPOINT ["java", "-jar", "/opt/app.jar"]

合规要点：

九、选型建议

9.1 新项目的默认推荐

对于新启动的企业开源项目，选择许可证时的基线建议：

9.2 企业内部代码的选择

9.3 商标策略

9.4 专利策略

十、工程检查清单

最后给一个可以直接粘进企业内部 Wiki 的检查清单：

10.1 开源引入阶段

[ ] 组件的许可证是否在白名单内？
[ ] 是否是 GPLv2-only？是否会与项目主许可证冲突？
[ ] 是否是 AGPLv3？是否会被网络服务触发？
[ ] 许可证是否包含专利条款？（Apache 2.0 / GPLv3 / MPL 2.0 / MIT+patent-grant 补丁）
[ ] 项目是否有商标政策？是否允许重新分发时修改？
[ ] 组件的主要贡献者是否来自竞争对手？是否加入了 OIN？

10.2 发布分发阶段

[ ] 是否保留了所有上游的 LICENSE、NOTICE、COPYING 文件？
[ ] 是否在产品"关于"页、文档中披露了第三方组件？
[ ] 是否生成并发布了 SBOM（CycloneDX / SPDX 格式）？
[ ] 分发物的名称、Logo 是否避开了上游商标？
[ ] GPL 类组件是否同步提供了完整对应源码（含构建脚本）？
[ ] 是否在容器镜像的 OCI annotations / Labels 中标明了许可证？

10.3 跨境与合规阶段

[ ] 目标市场是否对加密组件有出口管制？（详见出口管制专篇）
[ ] 目标市场是否有针对本项目所用技术的 NPE 活跃诉讼？
[ ] 是否加入了防御性专利联盟（OIN / LOT Network）？
[ ] 企业自身的专利组合是否授权给了开源社区？
[ ] 合同中是否对 GPL 类组件的"客户再分发"义务有明确安排？

十一、延伸话题：从条款到治理

11.1 贡献者许可协议（CLA）与 DCO 的专利含义

除了项目本身的许可证，真正决定”贡献者授予了什么”的，常常是贡献者许可协议（Contributor License Agreement，CLA） 或 开发者原创证书（Developer Certificate of Origin，DCO）。这两套机制在专利处理上差异很大。

Apache Software Foundation 的个人贡献者许可协议（ICLA）第 3 条复刻了 Apache 2.0 §3 的专利授权，并在第 4 条要求贡献者声明其有权授予该许可。这意味着：

- 贡献者在贡献前已经获得雇主的书面授权，或
- 贡献内容与雇主业务无关且不使用雇主资源，或
- 雇主签署了 Corporate CLA（CCLA），代表公司整体授予专利许可。

Google 的 CLA（适用于 Android、Kubernetes 早期等）、CNCF 的 DCO+CLA 混合模式、Linux 基金会的 DCO 单一模式，各自对专利授权的深度不同：

对企业而言，这意味着为员工贡献外部项目设置审批流程时，CLA 比 DCO 在专利维度上”授出的更多”，审批也应当更谨慎。

11.2 企业内部的 “Outbound / Inbound” 许可证策略

成熟的企业通常将开源合规拆分为两条独立的策略：

经典的 “inbound == outbound” 模型（如 Linux 内核的 DCO + GPLv2）简单但授权深度有限；“inbound > outbound” 模型（如 ASF 的 CLA 授出更广的权利）给基金会更灵活的再许可能力。企业需要根据项目性质选择：

场景 推荐策略 理由
开源库，接受社区 PR Apache 2.0 + DCO 低门槛，专利由 §3 覆盖
开源产品，接受企业共建 Apache 2.0 + CCLA 明确公司授权，方便基金会托管
内部项目可能转开源 Apache 2.0 + 内部 CLA 预留未来捐赠基金会空间
已捐赠基金会 遵循基金会规则 ASF / CNCF / Linux 基金会规则不同

11.3 许可证变更（Relicensing）的专利难题

一个项目一旦开源，更换许可证在法律上非常困难。历史上几次典型事件：

这些事件对专利维度的影响：

  1. Apache 2.0 → SSPL：SSPL 保留了 §11 类似的专利授权，但报复条款边界有变化；
  2. BSD → SSPL：从无专利条款变为有专利条款，但同时增加了”提供整个服务栈源码”义务；
  3. fork 合法性：只要遵守原许可证，任何人都可以继续维护原许可证版本——这是 Valkey、OpenTofu（对 Terraform 的 BSL 切换的回应）、Nomad → OpenBao 等 fork 的法律基础。

工程上的教训是：选择采购基础组件时，评估”供应商会不会突然改许可证”的风险。采用基金会托管的项目（Kubernetes、etcd、Kafka 等）在这方面风险最低，因为基金会通常要求代码可再许可的权利分散在所有贡献者之间，而不是集中在单一公司。

11.4 “Pseudo-open-source” 与 Source Available 的边界

近年出现了一批”看起来开源但不是开源”的许可证，典型代表：

这些许可证在专利维度上通常保留了 Apache 2.0 风格的条款，但商标政策往往更严格。例如 HashiCorp 在切换 BUSL 的同时，强化了对 “Terraform”、“Vault” 等商标的保护，并在 OpenTofu fork 出现后反复强调这些商标不得被再发行版使用。

工程选型时需要明确区分：

开源（OSI-approved）        : Apache 2.0, MIT, BSD, GPL, LGPL, MPL, EPL, ...
源码可见（Source Available）  : BUSL-1.1, Elastic v2, SSPL, Confluent CL, ...
专有（Proprietary）          : 未公开源码的商业软件

很多采购合同、企业合规政策把”开源”定义为”源码可见”，这是一个容易引入合规风险的误解。

十二、深入案例：Android 如何规避 GPL 与 Apache 的兼容性冲突

Android 项目在架构上是开源界最大的”兼容性陷阱绕行”案例。Google 在 2008 年开源 Android 时面临的问题：

解决方案是一整套架构分层：

┌─────────────────────────────────────────────┐
│   应用层 Apps (Apache 2.0 / 闭源)            │
├─────────────────────────────────────────────┤
│   应用框架 Framework (Apache 2.0)            │
├─────────────────────────────────────────────┤
│   原生库 Native Libraries (Apache 2.0 / BSD) │
│   Bionic libc (BSD) ← 替代 GNU libc (LGPL)   │
├─────────────────────────────────────────────┤
│   HAL 硬件抽象层 (Apache 2.0, 明确接口)       │
├─────────────────────────────────────────────┤
│   内核空间 ─── Binder IPC ──── 用户空间       │
├─────────────────────────────────────────────┤
│   Linux Kernel (GPLv2-only)                 │
└─────────────────────────────────────────────┘

关键设计决策：

  1. Bionic libc：Google 自研的 C 库，采用 BSD 许可证，刻意避开 GNU glibc 的 LGPL（LGPL 要求动态链接时提供可替换机制，对 Android 的静态打包模式不便）。
  2. HAL 抽象层：硬件厂商的驱动、闭源库通过 HAL 接口与系统通信，HAL 本身是 Apache 2.0，厂商实现可闭源。
  3. Binder IPC：用户空间与内核空间的通信通过 Binder 驱动（内核侧 GPLv2）+ libbinder（用户空间 Apache 2.0）实现，天然形成”进程边界”，避免代码链接进同一可执行文件。
  4. userland 与 kernel 的严格分离：Android 的任何闭源组件都在用户空间，通过系统调用访问内核。Linux 内核的 syscall 接口明确标注了 Linux-syscall-note 异常，允许非 GPL 用户态程序合法调用。

这套架构既规避了 GPLv2 × Apache 2.0 的兼容性冲突，又保留了硬件厂商闭源 BSP 的商业空间，是工程架构受许可证约束塑形的教科书案例。关于”动态链接是否构成分发”、“IPC 是否切断了 Copyleft 传染”的深入讨论，见本系列《Copyleft 的工程边界》。

十三、深入案例：Oracle vs Google 的 Java API 版权纠纷

虽然不是”专利案件”，但 2010—2021 年持续十余年的 Oracle v. Google 诉讼对开源专利与版权议题影响深远：

这个案子的专利与开源启示：

对工程团队的实务提示：

十四、工程师常问的若干问题（FAQ）

14.1 我在公司写的代码，用 MIT 许可证开源到 GitHub，有问题吗？

有。若公司与你签订的劳动合同约定”职务作品归公司所有”（中国大陆《著作权法》第十八条相关规定的常见约定方式），你没有权力单方面将其以任何许可证开源，无论 MIT 还是 Apache 2.0。即使你以个人账号上传，也可能被公司主张职务作品。正确流程是：先获得公司书面授权（或使用 CCLA 机制），再开源。

14.2 我用 Apache 2.0 的库作为依赖，需要改动我的主许可证吗？

不需要。Apache 2.0 是宽松许可证，你只需：

14.3 我用了一个 GPL 库，客户要 SaaS 部署，要公开我的所有代码吗？

取决于许可证版本与部署方式：

14.4 我只是用了 Kubernetes，需要考虑它的许可证吗？

需要评估，但通常风险很低。Kubernetes 采用 Apache 2.0：

14.5 我们公司是否应该加入 OIN？

如果满足以下任一条件，建议评估加入：

加入流程简单（签署 License Agreement 即可），成本为零。对已持有大量专利的公司而言，需要接受”Linux System 相关专利互授”这一代价；但对大多数公司，这并不意味着失去实际商业筹码。

十五、与其他合规议题的关系

专利与商标的合规不是孤立事件，与本系列其他主题存在紧密交叉：

十六、总结

专利与商标是开源许可证文本之外的”第二层合规地图”。代码可以开源，专利不一定授权；代码可以自由修改，名字和 Logo 不一定能用。Apache 2.0 §3 与 GPLv3 §11 通过显式的专利授权与报复机制，在贡献者与下游用户之间建立起一条可验证的信任链，但这条信任链对第三方 NPE 不延伸。GPLv2 与 Apache 2.0 的兼容性陷阱在 Linux 内核不能合并 Apache 代码这一事实上得到了最硬的工程体现，也是 Android 架构分层的根本成因之一。

而商标，则是一套几乎独立于版权与专利的权利体系。Firefox / IceWeasel 的重命名、Rocky Linux 的崛起、Red Hat 对 RHEL 源码访问的调整、红旗 Linux 商标的漂移，都在反复提醒我们：开源给出的是代码自由，不是品牌自由。

对工程团队而言，真正可落地的做法是把许可证、专利、商标三件事放进同一张合规地图里，用 SPDX 标识 + CI 扫描 + SBOM + 商标自检清单这样一整套工程手段持续校验，而不是把所有风险留给法务在发布前一个月才”突击 review”。

接下来的《MIT、BSD、Apache 2.0：宽松许可证的真实区别》将进一步拆解三大宽松许可证在条款细节、专利处理、合规成本上的差异，为本篇的专利话题补全”宽松侧”的完整图景。

十七、参考资料

  1. Apache Software Foundation. “Apache License, Version 2.0.” 2004. https://www.apache.org/licenses/LICENSE-2.0
  2. Free Software Foundation. “GNU General Public License, Version 3.” 29 June 2007. https://www.gnu.org/licenses/gpl-3.0.html
  3. Free Software Foundation. “Frequently Asked Questions about the GNU Licenses: Is GPLv3 compatible with Apache License 2.0?” https://www.gnu.org/licenses/gpl-faq.html#apache2
  4. Free Software Foundation. “Various Licenses and Comments about Them.” https://www.gnu.org/licenses/license-list.html
  5. Richard Stallman. “Transcript of opposition to software patents.” FSF. https://www.gnu.org/philosophy/patent-reform-is-not-enough.html
  6. Microsoft & Novell. “Microsoft and Novell Announce Broad Collaboration on Windows and Linux Interoperability and Support.” Press Release, 2 November 2006.
  7. Software Freedom Law Center. “Analysis of the Microsoft-Novell Deal and its GPL Implications.” 2006.
  8. Mozilla Foundation. “Mozilla Trademark Policy.” https://www.mozilla.org/foundation/trademarks/policy/
  9. Debian Project. “Debian Mozilla Team – Iceweasel FAQ / Firefox in Debian.”
  10. Rocky Enterprise Software Foundation. “Rocky Linux Origin.” https://rockylinux.org/
  11. Red Hat, Inc. “Red Hat Trademark Guidelines.” https://www.redhat.com/en/about/trademark-guidelines-and-policies
  12. Red Hat, Inc. “Furthering the evolution of CentOS Stream.” 21 June 2023.
  13. Open Invention Network. “License Agreement and Linux System Definition.” https://openinventionnetwork.com/
  14. Open Invention Network. “Huawei joins Open Invention Network.” Press Release, October 2015.
  15. SPDX Workgroup, Linux Foundation. “SPDX License List.” https://spdx.org/licenses/
  16. FSFE. “REUSE Specification.” https://reuse.software/spec/
  17. ScanCode Toolkit Documentation. https://scancode-toolkit.readthedocs.io/
  18. 中华人民共和国《专利法》及《专利法实施细则》现行有效文本（国家知识产权局官网）。
  19. European Patent Convention, Article 52. European Patent Office. https://www.epo.org/
  20. Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014).

本文所述法律与案例内容基于公开资料整理，仅作工程合规参考，不构成任何形式的法律意见。具体纠纷与交易请咨询具备对应司法辖区资质的专业法律顾问。条款引用以官方发布版本为准。

上一篇：Copyleft 的工程边界：动态链接、容器、SaaS 算不算”分发”

下一篇：MIT、BSD、Apache 2.0：宽松许可证的真实区别

返回目录：开源许可与版权工程系列｜开源格局全景｜开源许可证分类学

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2026-04-22 · architecture / opensource

【开源许可与版权工程】木兰许可证与国产开源许可

深入解读木兰宽松许可证 v2（OSI 认证）与木兰公共许可证 v2（弱 Copyleft）的条款：专利明示授权、中英双语法律效力、中国管辖条款；openEuler、openGauss、OpenHarmony、PaddlePaddle 的使用情况；以及与 Apache 2.0 的对比选择建议。

By .