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

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

2026-04-22 · architecture · opensource · #opensource #license #mulan #木兰 #openEuler #openGauss #OpenHarmony #PaddlePaddle #OSI #patent #Chinese-law

文章导航

分类入口
architectureopensource
标签入口
#opensource#license#mulan#木兰#openEuler#openGauss#OpenHarmony#PaddlePaddle#OSI#patent#Chinese-law

目录

木兰许可证体系概览

木兰许可证（Mulan License）是中国开源云联盟（China Open Source Cloud Alliance，COSCL）与北京大学等机构联合起草的一套开源许可证，于二〇一九年首次发布，是第一套由中国主导、同时具备中英文法律效力、并以中国法为默认管辖的开源许可证。其中的宽松版本 Mulan PSL v2 已于二〇二〇年二月通过开放源代码促进会（Open Source Initiative，OSI）认证，是继北京大学主导的另一份许可证之后，又一份获得 OSI 认可的中国本土许可证。

本文从「为什么需要」「条款如何写」「谁在用」「如何选」四个维度，对木兰宽松许可证（Mulan PSL）和木兰公共许可证（Mulan PubL）进行系统梳理，并与 Apache 2.0 做工程层面的细致对比，给出面向中国企业、政府项目、国际开源基金会三种典型场景的选型建议。

本文为工程与政策参考，讨论的是许可证文本层面的法律工程约束，不替代法律意见。涉及具体的版权归属、跨境 M&A、专利诉讼、上市合规等个案，仍需咨询专业法律顾问。

一、为什么需要国产开源许可证

1.1 历史背景：主流开源许可证的语言与法律绑定

在木兰许可证出现以前，全球主流开源许可证几乎全部以英文撰写，并且在法律表述上或多或少地带有美国法律体系（common law）的影子：

对于长期以美欧开发者为主的国际开源社区，上述安排不会造成困扰。但当开源软件进入中国企业、政府采购、关键基础设施、司法审理等场景时，语言与法律体系的错配开始显现。

1.2 中国法院对英文许可证的处理

截至目前，中国已有若干起涉及开源许可证的诉讼案件进入司法视野，包括数字天堂诉柚子（涉及 GPL）、罗盒诉风灵（涉及 GPL）、济宁罗盒与玩友（涉及 GPL）等。这些案件的裁判文书中，法官对 GPL 的法律效力一般是承认的，但在具体解释时会面临几个工程师和法律人都关心的问题：

  1. 英文的 GPL/MIT/Apache 在中国法下是否构成有效合同？
  2. 若构成合同，准据法如何确定？
  3. 合同条款中出现的如「derivative work」「distribute」「sublicense」等美式版权法概念，是否能直接映射到《中华人民共和国著作权法》下的「演绎作品」「发行」「再许可」？
  4. 专利条款（如 Apache 2.0 的 Section 3）在中国专利法下的效力与可操作性如何？

对于程序员来说，这些问题更直接的表现是：我 fork 了一个 GPL 项目、加了几行代码、只在公司内部部署，「内部部署」算不算 convey？算不算发行？触不触发 GPL 的源代码披露义务？这些解释在不同法系下可能得到不同结论。

1.3 COSCL 的动机：一份「给中国法官看得懂的许可证」

二〇一九年，中国开源云联盟（COSCL）联合北京大学法学院、华为、阿里、腾讯等机构，启动了「木兰开源许可证」项目。其动机可以归纳为三点：

  1. 语言：提供中文的正式法律文本，使合同义务在不经翻译的情况下对中国当事人具备直接可读性。
  2. 法律：默认准据法为中华人民共和国法律，纠纷在中国法院或仲裁机构解决，降低中国企业在国内纠纷中的跨法域成本。
  3. 兼容：同时保留英文文本并提交 OSI 认证，使得国际社区能够认可其「开源许可证」身份。

这是一种「国际化 + 本土化」的双重目标：对外要被承认为真正的开源许可证（OSI 认证），对内要在中国法院里经得起推敲。

1.3.1 几起典型案例对工程师的启示

以下三起涉及 GPL 的国内诉讼，是许可证工程讨论中经常被引用的案例。我们从程序员的视角概述其争点，以便理解「为什么一份中文正式文本对司法效率如此重要」。

  1. 数字天堂（北京）网络技术有限公司诉柚子（北京）移动科技有限公司案。争议焦点：被诉软件中被认为使用了原告拥有著作权的 HBuilder 相关代码，被告抗辩称原告代码基于 GPL 发布，应允许自由使用。法院最终对 GPL 许可证在中国法下的效力表达了明确的承认态度，并对具体条款的适用进行了阐释。

  2. 罗盒（广州）诉玩友（福州）案。争议焦点：VirtualApp 项目曾以 GPLv3 发布，后又调整为商业授权。法院在审理中就「GPL 条款下的再许可限制」进行分析。

  3. 济宁罗盒案的后续。围绕「GPL 分发即授予下游 GPL 许可」这一核心命题的司法表述，在国内形成了一批具有参考价值的判例。

上述案例中，法官都需要对英文 GPL 条款做法律解释。如果有一份具备中文正式文本的本土许可证（如木兰 PSL v2）摆在法官面前，整套程序的解释成本会显著降低。这就是「本土许可证」在司法工程上的价值。

1.4 从「可读」到「可执行」

一份许可证要真正在中国可执行，不是简单翻译一个 MIT 就能完成的。它需要：

Mulan PSL v2 基本上是按照这种「写一份能被中国法院直接适用的开源合同」的思路来起草的。

二、木兰宽松许可证（Mulan PSL）

2.1 Mulan PSL v1（2019）

Mulan PSL v1 于二〇一九年七月发布，是木兰许可证家族的首个正式版本。其主要特征包括：

  1. 中英双语正式文本，具有同等法律效力，出现不一致时以中文为准。
  2. 明示的版权与专利授予条款，以区别于 MIT 这种仅对版权做说明的极简许可证。
  3. 默认以中国法律为准据法，争议解决地默认在中国。
  4. 专利反制条款：被许可人如对许可人就本软件发起专利诉讼，其所获授权自动终止。

v1 发布后，社区对其条款措辞提出了一些意见，主要集中在两点：

因此，v1 并未立即提交 OSI 认证，而是作为过渡版本在国内企业圈内试用。

2.2 Mulan PSL v2（2020）——OSI 认证版

二〇二〇年二月，Mulan PSL v2 通过了 OSI 认证。这是中国主导的许可证中第二份获得 OSI 认证的（前者为北京大学提交的早期版本）。

v2 的 SPDX 标识为 MulanPSL-2.0，这是业界通用的「许可证短标识」体系，在 SCA（Software Composition Analysis）扫描工具、SBOM（Software Bill of Materials）生成中会以此字符串出现。

v2 相较 v1 的主要改进：

  1. 「专利权利要求」（Patent Claims）的范围被收紧为「覆盖本贡献的、由贡献者所有或控制的专利权利要求」；
  2. 管辖条款的措辞更接近国际惯例，保留中国法管辖，但降低了对非中国当事人的语言刚性；
  3. 中英文条款结构基本对齐，段落编号一致，便于跨语种比对；
  4. 明确了「无商标授权」这一条，避免了商业使用中品牌纠纷的模糊空间。

2.3 核心条款逐句解读

Mulan PSL v2 的中文正式文本只有大约一页半，条款结构如下。下面逐条解析。

2.3.1 第 0 条 定义

条款将 Software/软件、Contribution/贡献、Contributor/贡献者、Licensor/许可人、Patent Claims/专利权利要求等核心概念做了定义。

这种界定方式在范围上比 Apache 2.0 略窄（后者的表述是「would necessarily be infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work」），但方向一致。

2.3.2 第 1 条 授予版权许可

原文大意：许可人根据本许可证授予您「永久性的、全球性的、免费的、非独占的、不可撤销的」版权许可，用以复制、使用、修改、分发本软件，无论修改与否。

要点：

这段基本与 Apache 2.0 Section 2 等价。

2.3.3 第 2 条 授予专利许可

原文大意：许可人根据本许可证授予您「永久性的、全球性的、免费的、非独占的、不可撤销的（根据本条规定撤销除外）」专利许可，用以制造、委托制造、使用、许诺销售、销售、进口及其他处置本软件。

专利反制条款（Patent Retaliation）规定：如果您或您的关联实体直接或间接地，就本软件或本软件中的贡献向任何人（包括许可人或贡献者）发起专利侵权诉讼（包括反诉或交叉诉讼），或参与上述诉讼，那么本许可证授予您对本软件的专利许可自您起诉之日终止。

工程解读：

  1. 这不是「你不能打任何专利官司」，而是「你不能用专利打这个开源项目」。
  2. 一旦触发，只影响你已获得的专利许可，版权许可不受影响——但版权许可终止的条件见下文第 3 条。
  3. 「关联实体」通常包括母公司、子公司、兄弟公司，对大型集团意义重大。

2.3.4 第 3 条 分发限制

原文大意：您可以在任何媒介中将本软件以源程序形式或可执行形式重新分发，不论修改与否，但您必须向接收者提供本许可证的副本，并保留本软件中的版权、商标、专利及免责声明。

进一步要求：

与 Apache 2.0 的对比：

2.3.5 第 4 条 贡献

本许可证规定：您对许可人提交的任何贡献，默认以本许可证的条款授权给许可人和其他接收者，除非您明确声明以其他条款授权。

这是一种「进项默认 inbound=outbound」的规则，与 Apache 2.0 的 Section 5 基本一致。其实际效果是：PR 作者默认把自己的贡献也以 Mulan PSL v2 授权，不需要额外签 CLA（Contributor License Agreement）。但很多大型项目（如 openEuler、OpenHarmony）仍然会另外要求签署 CLA 或 DCO（Developer Certificate of Origin），是出于归属清晰与企业合规的考虑，而非许可证本身的要求。

2.3.6 第 5 条 商标

原文大意：本许可证不得解释为授予您使用许可人的商号、商标、服务标记或产品名称的权利，除非因描述本软件的来源以及复制本许可证的声明而必须使用。

这基本与 Apache 2.0 Section 6 一致。含义是：拿到代码不等于拿到品牌，你可以写「基于 openEuler 构建」，但你不能把自己的产品叫做「openEuler 企业版」除非获得另外的商标授权。

2.3.7 第 6 条 免责声明与责任限制

Mulan PSL v2 明确声明：软件「按现状」（as-is）提供，许可人不提供任何明示或默示的担保，包括但不限于商品性、适用于特定目的和非侵权的担保。在任何情况下，除适用法律另有规定或书面协议另有约定外，许可人不就任何人因使用本软件而产生的任何损失承担责任。

这里的一个微妙点是「除适用法律另有规定外」。中国《民法典》第五百零六条规定：合同中的下列免责条款无效——造成对方人身损害的；因故意或者重大过失造成对方财产损失的。因此，Mulan PSL v2 的免责条款在遇到「故意或重大过失」的情形时，是不能完全免责的。这和 Apache 2.0 在美国法下的 warranty disclaimer 也不完全一样——美式 disclaimer 在消费者保护法域里同样会被部分穿透。

2.3.8 第 7 条 许可证修改及管辖

管辖条款原文大意：本许可证以及本许可证项下的许可和争议，适用中华人民共和国法律。因本许可证产生的争议，双方应友好协商；协商不成的，任何一方均可向许可人所在地有管辖权的人民法院提起诉讼。

要点：

2.3.9 许可证结构一览（中文正式文本摘要）

为便于参照，下面以目录方式列出 Mulan PSL v2 中文正式文本的条款结构（不替代正式文本，详情以 license.coscl.org.cn 发布的文本为准）：

0. 定义
1. 授予版权许可
2. 授予专利许可
3. 无商标许可（商标条款置于第 3 条或第 5 条因版本排版略有差异，以实际文本为准）
4. 分发限制
5. 免责声明与责任限制
6. 语言
7. 适用法律与管辖

条款行文极为克制，整份许可证不到两页。相较 GPLv3 的二十余页，Mulan PSL v2 的阅读成本对项目方和采购方都更友好。

2.3.10 对比示例：一份项目 LICENSE 文件的写法

采用 Mulan PSL v2 的项目，其根目录的 LICENSE 文件典型内容结构为：

Copyright (c) 2024 Example Inc.

This software is licensed under Mulan PSL v2.
You can use this software according to the terms and conditions of the Mulan
PSL v2.
You may obtain a copy of Mulan PSL v2 at:
         http://license.coscl.org.cn/MulanPSL2
THIS SOFTWARE IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OF ANY KIND,
EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO NON-INFRINGEMENT,
MERCHANTABILITY OR FIT FOR A PARTICULAR PURPOSE.
See the Mulan PSL v2 for more details.

源文件头部常见的短声明：

/*
 * Copyright (c) 2024 Example Inc.
 * example-lib is licensed under Mulan PSL v2.
 * You can use this software according to the terms and conditions of the
 * Mulan PSL v2.
 * You may obtain a copy of Mulan PSL v2 at:
 *          http://license.coscl.org.cn/MulanPSL2
 * THIS SOFTWARE IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OF ANY
 * KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
 * NON-INFRINGEMENT, MERCHANTABILITY OR FIT FOR A PARTICULAR PURPOSE.
 * See the Mulan PSL v2 for more details.
 */

使用 SPDX 短标识的简洁声明（推荐方式）：

// SPDX-License-Identifier: MulanPSL-2.0
// Copyright (c) 2024 Example Inc.

2.3.11 与 MIT、BSD、Apache 2.0 的声明体例对比

许可证 典型文件头声明行数 是否 SPDX 常用
MIT 1 行 SPDX 或 1 段说明 常用
BSD-3-Clause 1 行 SPDX 或 3 段说明 常用
Apache 2.0 1 行 SPDX 或 5~10 行说明 常用
Mulan PSL v2 1 行 SPDX 或 10~12 行说明 常用

从文件头维护成本看，Mulan PSL v2 的长说明略繁琐；但采用 SPDX-License-Identifier: MulanPSL-2.0 一行声明后，维护成本与 Apache 2.0 一致。

2.4 中英双语效力

Mulan PSL v2 的特别之处在于其对双语效力的明示规定。中英文文本同时具有法律效力；当两者出现不一致时，以中文文本为准。

这对工程与合规带来两个实际影响：

  1. 国际贡献者如果只读了英文版本，应当意识到：在中国法院审理时，中文文本将是准据文本。建议在项目 README 中同时链接两个版本，并提醒非中文使用者注意这一条款。
  2. 如果项目 fork 自 Mulan PSL v2 项目并在海外分发，虽然可以保留原许可证不变，但分发者应当在文档中提示这一语言优先规则。

2.5 许可证头部的 SPDX 识别与工具链处理

SPDX（Software Package Data Exchange）是 Linux 基金会主导的开源软件物料清单标准。Mulan PSL v2 在 SPDX 许可证列表中的官方标识为 MulanPSL-2.0，其余家族成员的标识如下：

许可证 SPDX 标识
Mulan PSL v1 MulanPSL-1.0
Mulan PSL v2 MulanPSL-2.0
Mulan PubL v1 MulanPubL-1.0
Mulan PubL v2 MulanPubL-2.0

在使用工具链时，建议：

  1. reuse（FSFE 工具，检查源文件是否具备正确的 SPDX 标识）能够识别 Mulan 系列。
  2. scancode-toolkit 能识别 MulanPSL-2.0，对 v1 可能需要自定义规则。
  3. licensecheck（Debian 工具）对 Mulan 系列的识别近年在改善。
  4. 项目构建时建议在 CI 中添加「未标识许可证」检查，防止新增文件遗漏 SPDX 头。

示例：.reuse/dep5 片段

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: example-service
Upstream-Contact: dev@example.com
Source: https://gitee.com/example/example-service

Files: *
Copyright: 2024 Example Inc.
License: MulanPSL-2.0

Files: vendor/apache-commons/*
Copyright: 2010-2024 The Apache Software Foundation
License: Apache-2.0

2.6 Mulan PSL v2 与版本冻结

与 Apache 2.0 类似，Mulan PSL v2 一经发布，其文本被认为是「冻结」的（frozen text）。COSCL 不会对已发布的 v2 文本作实质性修改，任何修改需通过发布新版本（例如将来的 v3）完成。这一点是保证「v2 = v2」在十年、二十年后依然可预期解释的前提。

工程建议：

  1. 在 LICENSE 文件中明确写出「MulanPSL-2.0」而非泛泛写「MulanPSL」；
  2. 在声明中引用官方 URL（license.coscl.org.cn/MulanPSL2），但避免把整份文本混入代码库导致未来版本不一致——附带一份快照 LICENSE 文件并在 README 中链接官方页即可；
  3. 对于 SBOM 导出，务必使用带版本号的 SPDX 标识。

2.7 许可证内部一致性自检清单

若你的项目采用 Mulan PSL v2，建议定期自检：

三、木兰公共许可证（Mulan PubL）

3.1 Mulan PubL v1 与 v2 的差异

Mulan PubL（Mulan Public License）是木兰家族中的「弱 Copyleft」版本。Mulan PubL v1 于二〇一九年发布，v2 紧随 PSL v2 之后推出。截至本文写作时的公开信息，PubL v2 尚未通过 OSI 认证（OSI 对 Copyleft 许可证的审批普遍更加严格，且国际社区可替代方案较多）。

3.2 弱 Copyleft 条款的含义

「弱 Copyleft」这一术语通常描述 LGPL、MPL 这一类许可证，其核心要义为：

  1. 对「被许可软件」本身的修改需以同样许可证开源（复制传染）；
  2. 对「使用/调用」被许可软件的外部程序不产生传染（边界收窄）。

Mulan PubL v2 的传染边界大体遵循 MPL-2.0 的「文件级 Copyleft」思路：

在工程上，这种边界对企业友好：你可以用 Mulan PubL v2 的数据库驱动、中间件 SDK 去做闭源业务系统，只要你不修改 SDK 本身。

3.3 与 Mulan PSL v2 的对比

维度 Mulan PSL v2 Mulan PubL v2
类型 宽松（Permissive） 弱 Copyleft
OSI 认证 已认证 未认证
修改是否需开源 否 是（对被许可文件）
调用是否需开源 否 否
典型适用 框架、工具库、应用 基础库、内核模块、特定希望保证持续开源的组件
类比许可证 MIT、Apache 2.0 MPL-2.0、LGPL（弱传染）

3.4 什么时候选 PubL 而不是 PSL

反之，如果你希望最大化生态覆盖（比如做一个深度学习框架或云原生中间件），宽松许可证（PSL 或 Apache 2.0）更有利。

3.5 PubL 的文件级 Copyleft 工程边界示例

假设我们基于 Mulan PubL v2 发布的加密库 pubcrypto（虚构示例）来构建一个业务系统：

/app                   // 自研应用，调用 pubcrypto API
├── src/main.go        // import "pubcrypto"
└── LICENSE            // 你自选，如 Apache-2.0 或闭源

/vendor/pubcrypto      // 上游 MulanPubL-2.0 源码
├── aes.go             // 未修改，保持 MulanPubL-2.0
├── aes_fix.go         // 你新增的补丁，加入到该库
└── LICENSE            // MulanPubL-2.0

在文件级 Copyleft 的模型下：

工程建议：

  1. 修改上游 PubL 代码时，严格在上游仓库提 PR，维持许可证一致；
  2. 避免在 PubL 文件中 import 自家业务闭源模块；
  3. 发行时附带对 PubL 组件的源代码可获取路径（源分发或在线链接）。

四、中国管辖条款的工程含义

4.1 管辖权条款的法律意义

传统国际开源许可证中，常见管辖处理有三种：

  1. 完全不指定（MIT、BSD、GPL、Apache 2.0）：由实际纠纷发生时根据国际私法规则确定；
  2. 指定美国某州（MPL 指定加州）；
  3. 指定仲裁机构（某些商业源代码协议会指定 ICC 或 SIAC）。

Mulan PSL v2 明确选择了「中国法 + 中国法院」。这意味着：

4.2 对国际开源项目的影响

国际开发者在向 Mulan PSL v2 项目贡献代码时，理论上接受了中国法管辖。实务中可能出现的情形：

  1. 外国贡献者在 GitHub 或 Gitee 上提交 PR，PR 合并等价于其同意许可证。
  2. 若将来发生专利反制或版权纠纷，争议会以中国法审理。
  3. 若项目 fork 到海外并违反许可证，原许可人要去海外法院起诉，该国法院是否承认中国法管辖条款，取决于当地的冲突法规则和是否存在司法协助协议。

这也是为什么 Apache 软件基金会、Linux 基金会、云原生计算基金会（CNCF）这些国际组织，倾向于选择「不指定管辖」的许可证：降低跨境贡献者加入门槛。

4.3 与 Apache 2.0 的可操作性对比

从纯工程合规角度：

对中国公司，Mulan PSL v2 在国内纠纷中能提供更干净的起诉路径。对计划海外上市、面向海外客户、或将核心项目捐给国际基金会的公司，Apache 2.0 的中立性是优势。

4.4 跨境贡献者的合规挑战

设想这样一个场景：一家欧洲开发者公司 EuroCo 派其工程师 Alice 向某 Mulan PSL v2 项目提交了一个重大特性 PR。一年后，EuroCo 与该项目的维护企业因另一商业合作发生专利纠纷。EuroCo 在德国法院起诉该项目维护企业，主张其某专利被侵犯。

依据 Mulan PSL v2 第 2 条的专利反制规定，EuroCo 对该项目的专利许可自起诉之日自动终止。但与此同时：

  1. EuroCo 此前向项目提交的代码仍以 Mulan PSL v2 有效授权给所有下游使用者；
  2. EuroCo 自身不能继续以 Mulan PSL v2 获得该项目的专利许可；
  3. 版权许可是否同时终止，通常需要项目方基于合同违约或项目治理规则另行主张；
  4. 德国法院是否承认「适用中国法」的约定，取决于德国冲突法规则，一般在 B2B 合同中会尊重当事人意思自治，但公序良俗等例外情形仍可能介入。

由此可见，对跨境贡献者来说：

4.5 管辖与送达的技术性问题

即便许可证写明「中国法院」，具体到哪家法院也有讲究。Mulan PSL v2 采取「许可人所在地」原则，这在多贡献者项目中会产生有趣的并存局面：

实务上，项目治理方（如开放原子基金会、主导企业）一般会通过 CLA 将贡献的部分版权归集或许可给统一主体，以便于统一维权。

五、专利明示授权条款

5.1 与 Apache 2.0 专利条款的对比

Apache 2.0 Section 3（Grant of Patent 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.

Mulan PSL v2 第 2 条：

每个「贡献者」根据本许可证授予您对「贡献」的专利许可，该专利许可是永久性的、全球性的、免费的、非独占的、不可撤销的（根据本条规定撤销除外）。这里所说的专利权利要求是指「贡献者」现在或将来拥有或控制的，在其「贡献」自身或「贡献」与许可在提交「贡献」时的「软件」的结合中不可避免会被侵犯的专利权利要求。

两者异同：

维度 Apache 2.0 Mulan PSL v2
行为范围 make, have made, use, offer to sell, sell, import, otherwise transfer 制造、委托制造、使用、许诺销售、销售、进口
专利范围 贡献者可授权的、其贡献必然侵犯的专利 贡献者拥有或控制的、其贡献必然侵犯的专利
覆盖组合 贡献单独 或 贡献与作品结合 贡献自身 或 贡献与软件结合
反制范围 对任何人就 Work 起诉 对任何人就本软件或贡献起诉
反制后果 该起诉人所获专利许可终止 该起诉人所获专利许可终止

实际工程差异微乎其微。两者都限定在「必然被侵犯」的专利权利要求，不会覆盖贡献者的全部专利组合。

5.2 专利反制条款的触发场景

典型触发场景：

  1. A 公司向 Mulan PSL v2 项目提交专利诉讼，指控项目侵犯其某专利；
  2. A 公司此前从该项目（或其贡献者）获得的专利许可即刻终止；
  3. 版权许可一般不受直接影响，但许可人可能基于合同违约追究版权责任。

值得注意的是，专利反制是「自动触发」，不需要项目方主动宣布。

5.3 工程实践中的专利风险

对于华为、阿里、腾讯、百度等拥有庞大专利组合的企业，Mulan PSL v2 的专利条款实际上是一种「明示信号」：我以许可证的方式，明确放弃对被许可人就这部分贡献主张专利。对于下游企业用户来说，这份明示信号比「纯 MIT」带来的合规可预期性要高得多。

对于国有企业（SOE）或国家重点实验室开源的代码，专利明示授权条款还有一个隐含价值：避免未来可能出现的「国有资产流失」争议——因为许可证文本本身就说明了「我授权了，但我的专利反制权保留」。

5.4 专利条款的合同结构剖析

一份带专利授权的开源许可证，实质上是多份合同的复合体：

  1. 贡献者与项目之间：贡献的著作权与专利许可；
  2. 项目与下游分发者之间：整包的再许可；
  3. 下游分发者与最终用户之间：分发时再次传递许可。

Mulan PSL v2 将这三层关系简化为「一份单一合同」的多方形态：任何接收代码的人，同时与所有贡献者建立起独立的许可关系。这与 Apache 2.0 的「direct license from each Contributor」思路一致。

5.5 何为「必然会被侵犯」的专利权利要求

「necessarily be infringed」或中文的「不可避免会被侵犯」是一个技术-法律复合判断，通常需要逐项分析专利的权利要求书（claims）与代码的实现路径。工程上的判断方法：

实务中，这一判断往往由贡献者企业法务部门内部完成；开源社区很少对外披露具体被覆盖的专利清单，但 IBM、红帽等公司历史上有过公开「承诺不主张」的专利池。华为、阿里等中国厂商近年也在摸索类似的「开源承诺」机制。

5.6 工程中如何对上游专利状态做尽调

对使用 Mulan PSL v2 项目作为依赖的下游，典型的专利尽调流程：

  1. 识别上游贡献者主体（通过 CLA 名单、commit author、组织邮箱等）；
  2. 检索中国国家知识产权局（CNIPA）和美国专利商标局（USPTO）中该主体的专利组合；
  3. 对关键特性做「权利要求映射」：判断项目某模块是否落入某专利；
  4. 若高风险，评估是否可通过许可证条款获得对应专利许可；
  5. 若仍不确定，考虑替代实现路径或与权利人直接谈判。

这套流程无论对 Apache 2.0 还是 Mulan PSL v2 项目都适用，只不过 Mulan PSL v2 明示专利授权后，判断权利覆盖范围的主阵地会更接近中国专利法的司法实践。

六、使用木兰许可证的主要项目

6.1 openEuler（欧拉操作系统）

openEuler 是由华为主导开源、后捐赠给开放原子开源基金会（OpenAtom Foundation）的 Linux 发行版。

选择 Mulan PSL v2 的考量：

  1. 华为作为主要贡献者，拥有大量基础通信与操作系统专利，明示专利授权有利于消除下游顾虑；
  2. 目标客户以中国政府与大型企业为主，PRC 法管辖具备本地化优势；
  3. 与开放原子基金会的 IP 治理政策对齐。

6.2 openGauss（openGauss 数据库）

openGauss 源自华为 GaussDB 家族，面向企业关键业务场景的关系型数据库，基于 PostgreSQL 核心进行了大量企业级增强。

6.3 OpenHarmony（开放鸿蒙）

OpenHarmony 是鸿蒙操作系统的开源版本，由华为捐赠给开放原子开源基金会后形成的社区项目。

许可证结构是混合的：

混合许可证的工程挑战：

  1. SBOM 生成要能识别 MulanPSL-2.0 与上游 SPDX；
  2. 分发时要同时附带所有依赖组件的许可证文本；
  3. 下游基于 OpenHarmony 做产品（如各家 IoT 设备）需要对许可证做逐组件分析。

6.4 PaddlePaddle（飞桨）

飞桨是百度的深度学习框架，在国际社区的定位是 TensorFlow、PyTorch 的替代方案之一。

飞桨这种「以 Apache 2.0 为主，以 Mulan PSL v2 为辅」的模式，对希望兼顾两边市场的项目具有借鉴意义。

6.5 其他使用木兰许可证的项目

Gitee 作为中国最大的代码托管平台，其许可证选项中 MulanPSL-2.0 已经被作为默认选项之一。根据 Gitee 公开的统计（开源中国历次年度报告中有披露），采用木兰许可证的项目已达数千个，主要分布在：

6.6 案例深入：openEuler 的许可证治理

openEuler 作为典型 Linux 发行版项目，面临的不仅仅是「单个许可证选择」，而是整个发行版层面的许可证治理：

  1. 内核（kernel）：GPLv2，不变；
  2. GNU 工具链（gcc、glibc 等）：GPLv3、LGPL，不变；
  3. 系统服务（如 systemd）：LGPL 为主；
  4. openEuler 独有增强：MulanPSL-2.0；
  5. 第三方引入：遵守其原许可证；
  6. 发行版整体层面的分发合规：以 LICENSE 目录与 SOURCE 可获取性为核心。

openEuler 社区建立了名为「许可证兼容性矩阵」的内部文档（可在 gitee.com/openeuler 查阅），指导新 RPM 包合入时的许可证审查。典型的合入流程：

PR 提交 → SIG 维护者初审 → 自动化 SCA 扫描（SPDX 识别）
       → License Compatibility Check（矩阵比对）
       → 合并入仓

6.7 案例深入：OpenHarmony 的组件级许可证矩阵

OpenHarmony 由数百个子组件构成，许可证分布大致如下：

类别 默认许可证 占比（公开文档估计）
系统内核与服务（原创） MulanPSL-2.0 ~30%
第三方开源组件 Apache-2.0、BSD、MIT、LGPL、GPL 等 ~55%
内核组件（LiteOS / Linux） BSD-3-Clause / GPL-2.0 ~10%
文档 CC-BY-4.0 ~5%

组件级许可证的存在，使得 OpenHarmony 的下游产品（例如某品牌智能手表 OS）在合规报告中需要列出每一个组件的许可证。实务中常用的工具有：

6.8 案例深入：openGauss 与 PostgreSQL 的兼容性

openGauss 基于 PostgreSQL 做深度增强，PostgreSQL 本身使用 PostgreSQL 许可证（类 BSD）。openGauss 在 MulanPSL-2.0 下发布新增代码的同时，保留了原 PostgreSQL 代码的 PostgreSQL 许可证声明。

下游发行时需同时附带：

  1. PostgreSQL LICENSE 文件；
  2. MulanPSL-2.0 LICENSE 文件；
  3. 各第三方组件许可证（如 libxml2、OpenSSL 等）。

SPDX 表达式可近似为：

MulanPSL-2.0 AND PostgreSQL AND MIT AND BSD-3-Clause AND OpenSSL ...

6.9 案例深入：PaddlePaddle 的双许可战略

PaddlePaddle 主仓库 License 为 Apache 2.0。但在其面向中国市场的商业发行版与行业方案中，部分模块以 MulanPSL-2.0 重新授权或双许可。这种做法的工程约束：

  1. Apache 2.0 允许 re-license 为 MulanPSL-2.0（PSL 是 Apache 兼容的宽松许可证）；
  2. 但若上游存在 GPL 片段，则 re-license 不被允许；
  3. 必须准备双语合规文档。

七、适用场景与局限性

7.1 适合使用木兰许可证的场景

  1. 目标客户以中国大型企业、政府、事业单位为主；
  2. 项目方是国有企业或国家重点实验室，需要明确的国内合规路径；
  3. 项目方拥有较多中国专利，希望通过明示授权清除下游顾虑；
  4. 项目本身捐赠给开放原子开源基金会或其他国内基金会；
  5. 项目长期维护团队以中文工作为主，双语审阅成本可控。

7.2 不适合木兰许可证的场景

  1. 希望最大化国际采用、目标用户分布在欧美；
  2. 项目将捐赠给 Apache 基金会、Linux 基金会、CNCF（这些基金会通常要求 Apache 2.0）；
  3. 母公司处于海外上市筹备期，投资人对非主流许可证敏感；
  4. 项目上游依赖包含大量 GPL/AGPL 代码，需要以兼容的方式分发；
  5. 贡献者社区以非中文为主，且不希望以中国法管辖为默认。

7.3 木兰许可证的国际认知现状

认可主体 状态
OSI Mulan PSL v2 已认证；PubL 未认证
SPDX MulanPSL-2.0、MulanPSL-1.0、MulanPubL-2.0 等标识已纳入
Apache 软件基金会 Apache 2.0 与 MulanPSL-2.0 被 ASF 法律委员会评估为兼容
自由软件基金会（FSF） 未对 Mulan PSL 作正式评估
CNCF 默认仅接受 Apache 2.0，新许可证项目需单独评估
Debian / Fedora 一般按 OSI 名单处理，Mulan PSL v2 在 OSI 列表内

7.4 合规报告模板的影响

许多企业采购流程中使用 SPDX 或 CycloneDX 格式生成的 SBOM 合规报告，其中许可证字段一般具有「白名单」机制。常见的白名单：

Mulan PSL v2 作为 OSI 认证的宽松许可证，从法律特性上与 MIT、BSD、Apache-2.0 等价，理应加入「内部自用白名单」。但实际落地取决于企业合规部的政策更新速度。

建议 OSPO 在采购 Mulan PSL v2 软件时：

  1. 将 MulanPSL-2.0 明确加入白名单；
  2. 在合规文档中注明「OSI approved, permissive」；
  3. 对跨境合规做额外评估（若公司有美国、欧盟业务）。

7.5 选择许可证时的常见误解

以下几种误解在选型讨论中经常出现：

  1. 误解：Mulan PSL 只能被中国主体使用。 事实：任何主体都可以采用 Mulan PSL 发布项目；OSI 认证意味着它是通用开源许可证。
  2. 误解：用了 Mulan PSL 就不能被美国企业使用。 事实：美国企业使用 Mulan PSL v2 项目没有技术或法律障碍，但可能面临内部合规路径不熟悉的成本。
  3. 误解：Mulan PSL 等价于 MIT。 事实：Mulan PSL v2 更接近 Apache 2.0（含专利条款），而非 MIT（无专利条款）。
  4. 误解：Mulan PubL 等价于 GPL。 事实：PubL 是弱 Copyleft，更接近 MPL-2.0，而非强 Copyleft 的 GPL。
  5. 误解：选了 Mulan PSL 就表示「政治站队」。 事实：许可证是法律文本，其政治含义的解读因场景而异；工程决策应以法律与合规需求为主。

八、与 Apache 2.0 的详细对比

8.1 并列对比表

维度 Apache 2.0 Mulan PSL v2
类型 宽松 宽松
语言 英文 中英双语（以中文为准）
版权授权 永久、全球、免费、非独占、不可撤销 永久、全球、免费、非独占、不可撤销
专利授权 有，范围较宽 有，范围略窄
专利反制 有，终止全部专利许可 有，终止全部专利许可
Copyleft 无 无
NOTICE 文件 必须保留并传递 无强制独立 NOTICE 要求
改动标记 Section 4(b) 要求 无等价条款
商标 不授予 不授予
担保 无 无
责任限制 有 有，但受中国法强制规定约束
管辖 未指定 中华人民共和国法律
OSI 认证 认证
FSF-free 是 未评估
GPLv3 兼容 是（单向） 未被 FSF 明确评估；社区倾向认为与 GPLv3 单向兼容

8.2 何时选 Mulan PSL v2 优于 Apache 2.0

8.3 何时选 Apache 2.0 优于 Mulan PSL v2

8.4 双许可的选项（PaddlePaddle 模式）

双许可（dual licensing）意味着被许可人可以在 Apache 2.0 或 Mulan PSL v2 中选择一个遵守。这种模式的好处：

成本：CLA 文本更复杂；合规说明页面需要清晰描述「如何选择」；SCA 工具在识别时可能会把项目标记为「双许可」。

8.5 条款行文对比：版权授予

Apache 2.0 Section 2：

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 copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

Mulan PSL v2 第 1 条（中文）：

根据本许可证的条款和条件，每个「贡献者」特此授予您永久性的、全球性的、免费的、非独占的、不可撤销的版权许可，您可以复制、使用、修改、分发其「贡献」，不论修改与否。

二者的关键行为列表略有不同：

行为 Apache 2.0 Mulan PSL v2
复制 reproduce ✓ ✓
准备演绎 prepare Derivative Works ✓ ✓（以「修改」表述）
公开展示 publicly display ✓ 未明示
公开表演 publicly perform ✓ 未明示
再许可 sublicense ✓ 含于「分发」中
分发 distribute ✓ ✓

「公开展示」「公开表演」属于美国版权法典型权能，中国著作权法则以「信息网络传播权」「表演权」等对应。Mulan PSL v2 通过「根据本许可证」一句，实际上涵盖了通常意义上的使用行为。

8.6 NOTICE 文件的差异

Apache 2.0 明确要求在分发时保留并传递 NOTICE 文件中列明的归属信息。这一条在企业合规中影响深远：

Mulan PSL v2 没有「独立 NOTICE」的硬性要求，但要求保留源文件内的版权、专利、商标和免责声明。对混合使用 Apache 2.0 与 Mulan PSL v2 代码的项目，NOTICE 文件仍需按 Apache 2.0 要求维护。

8.7 对企业 M&A 尽调的影响

在企业并购（M&A）场景中，买方通常会委托第三方做开源合规尽调。尽调报告中的每一个许可证都会被核对：

若公司资产评估中含大量 Mulan PSL 项目，建议在数据室（data room）中提前准备解释说明，指向 OSI 认证页面、SPDX 识别、开放原子基金会治理政策等。

九、工程坑点

9.1 中英文版本冲突时的优先级

坑：当英文译本与中文原文在技术性用语上出现偏差时，例如「contribution」在中文里对应「贡献」，但贡献这个词在日常语义中含义更广，法庭解释可能出现差异。

建议：

  1. 项目代码仓中同时托管两份正式文本，并加上 README 提示；
  2. 对于关键条款（专利范围、管辖），国际贡献者应当直接请中文法律顾问做核对；
  3. 在 CLA 中复述关键条款，避免以「仅读了英文」为由否认条款效力。

9.2 与上游 Apache 2.0 项目的混合分发

Mulan PSL v2 与 Apache 2.0 兼容，意味着：

坑点：

  1. Apache 2.0 对 NOTICE 文件有严格要求，Mulan PSL v2 项目分发时仍需保留；
  2. 如果修改了 Apache 2.0 原代码，需要在修改文件中添加 modification notice；
  3. SBOM 工具应能识别混合许可证结构，避免漏报。

9.3 开放原子基金会项目的许可证治理

开放原子开源基金会（OpenAtom Foundation）要求捐赠项目进行 IP 清理（IP clearance），流程包括：

典型坑点：

  1. 遗留代码中混入了 GPL 片段（如从 Linux 内核复制函数），必须清除或单独隔离；
  2. 员工在职期间的个人项目贡献，归属需明确；
  3. CLA 签署需要企业与个人两种模板。

9.4 OSPO 合规检查工具对木兰许可证的识别

开源项目办公室（Open Source Program Office，OSPO）常用的 SCA 工具包括：

工具 Mulan 识别状态
FOSSA 支持 MulanPSL-2.0
Black Duck 支持主要 Mulan 变体
Snyk 支持 Mulan PSL 系列
ScanCode Toolkit 基于 SPDX，识别 MulanPSL-2.0 良好
OSS Review Toolkit (ORT) 通过 SPDX 识别

坑点：

  1. 非正式的 Mulan PSL v1 旧版本文本可能被识别为「unknown license」，需手动映射；
  2. SBOM 的 licenseConcluded 字段应使用 MulanPSL-2.0（而非自创标识）；
  3. 企业合规清单若仅列 Apache/MIT/BSD，会把 Mulan 项目误判为「需额外评审」。

9.5 SBOM 导出格式中的常见错误

企业在导出 SBOM 时，常见错误包括：

  1. 把 MulanPSL-2.0 写成 Mulan PSL 2.0，导致 SPDX 验证失败；
  2. 把 MulanPSL-2.0 错认为 MulanPubL-2.0；
  3. 对双许可项目只导出一个；
  4. 对未知文本直接标注 NOASSERTION 而未进一步审查。

示例：CycloneDX SBOM 中的 license 字段正确写法

{
  "name": "openeuler-core",
  "version": "22.03-LTS",
  "licenses": [
    { "license": { "id": "MulanPSL-2.0" } }
  ]
}

对双许可项目：

{
  "name": "paddle-module",
  "version": "1.0",
  "licenses": [
    { "expression": "Apache-2.0 OR MulanPSL-2.0" }
  ]
}

9.6 CLA 与 DCO 的交叉问题

开放原子基金会推行「双轨」贡献者协议模型：

Mulan PSL v2 的第 4 条已经涵盖了基本的 inbound=outbound 授权，但 CLA/DCO 仍然必要，原因是：

  1. CLA 明确了贡献者本人具备授权权限（例如职务作品的归属问题）；
  2. CCLA 明确了企业对员工贡献负责；
  3. DCO 提供了可追溯的合规签名。

典型的 DCO 签名在 commit message 尾部：

Signed-off-by: Alice Zhang <alice@example.com>

这与 Mulan PSL v2 并不冲突，反而为项目方提供了更充分的合规凭证。

9.7 CI/CD 中的许可证扫描最佳实践

一个生产级的许可证扫描流水线通常包括：

name: license-check
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run REUSE lint
        uses: fsfe/reuse-action@v2
      - name: Run ScanCode
        run: |
          pip install scancode-toolkit
          scancode -l -c -i --json-pp scan.json .
      - name: Check SPDX expression allowlist
        run: |
          python scripts/check_allowlist.py scan.json

白名单脚本示例（简化版）：

import json, sys

ALLOW = {
    "MulanPSL-2.0", "Apache-2.0", "MIT", "BSD-2-Clause", "BSD-3-Clause",
    "ISC", "LGPL-2.1-or-later", "LGPL-3.0-or-later"
}
DENY = {"AGPL-3.0-only", "AGPL-3.0-or-later", "SSPL-1.0"}

with open(sys.argv[1]) as f:
    data = json.load(f)

violations = []
for pkg in data.get("files", []):
    for lic in pkg.get("licenses", []):
        key = lic.get("spdx_license_key")
        if key in DENY:
            violations.append((pkg["path"], key))
        elif key and key not in ALLOW:
            violations.append((pkg["path"], key))

if violations:
    for v in violations:
        print("VIOLATION:", v)
    sys.exit(1)

9.8 文档与代码分开许可

常见的「文档 CC-BY-4.0 + 代码 Mulan PSL v2」组合需要在仓库中写清楚边界，示例 README.md 片段：

## License

- **Source code**: licensed under [Mulan PSL v2](https://license.coscl.org.cn/MulanPSL2)
- **Documentation** (`docs/`): licensed under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)
- **Third-party components**: see `THIRD_PARTY_LICENSES/`

文档与代码的边界一旦模糊（例如 README 中嵌入了大段代码示例），应在相应文件头或该文件所在目录的 LICENSE 文件中单独说明。

十、选型建议

下表列出几种典型场景与建议。

场景 推荐许可证 理由
中国企业基础设施，面向国内企业客户 Mulan PSL v2 中国法管辖、专利明示授权、SOE 合规友好
中国企业中间件，希望国内外都推广 Apache 2.0 或双许可 国际接受度高，双许可兼顾国内
捐给开放原子基金会 Mulan PSL v2 基金会优先许可证
捐给 ASF / CNCF / LF Apache 2.0 基金会硬性要求
国内科研项目，学术与产业结合 Apache 2.0 或 Mulan PSL v2 均可 视目标社区定位
大型国企 / 国家实验室 Mulan PSL v2 明示授权，降低国有资产争议
基础库，希望下游修改能回流 Mulan PubL v2 或 MPL-2.0 弱 Copyleft
海外上市筹备中的公司 Apache 2.0 投资人最熟悉，合规成本最低
工具链、编译器、运行时 Apache 2.0 与国际工具链生态一致
政府采购用开源产品 Mulan PSL v2 可直接引用中文合同条款

10.1 一条基本经验法则

如果你的默认直觉是「我想用 Apache 2.0」，那么改用 Mulan PSL v2 的前提至少应该是：你有一个清晰的本地化理由（中国客户、国内基金会、专利信号），并且能接受国际社区可能的迟疑。

反过来，如果你的直觉是「我想用 Mulan PSL v2」，那么改用 Apache 2.0 的前提至少应该是：你接受其管辖条款空白带来的不确定性，或者你明确希望被国际基金会接纳。

10.2 双许可的实施清单

若决定采用 Apache 2.0 + Mulan PSL v2 双许可，建议在工程上准备：

  1. 项目根目录包含 LICENSE-APACHE 与 LICENSE-MULAN 两份文本；
  2. README.md 中清晰说明「被许可人可任选其一遵守」；
  3. CLA 同时授予双许可下的必要权利；
  4. 每个源文件头部的许可声明使用 SPDX 表达式： // SPDX-License-Identifier: Apache-2.0 OR MulanPSL-2.0；
  5. SBOM 生成时保留该 SPDX 表达式；
  6. 发行包的 NOTICE 文件同时声明双许可可选项。

10.3 决策树：如何在五分钟内做出初步选型

1. 项目是否将捐给国际基金会（ASF/LF/CNCF）？
     └── 是 → Apache 2.0
2. 否 → 项目目标市场是否以国内为主？
     ├── 是 → 项目是否为中大型基础设施？
     │         ├── 是 → Mulan PSL v2（或双许可）
     │         └── 否 → Mulan PSL v2 或 Apache 2.0 均可
     └── 否 → 项目是否将主要在海外社区发展？
               ├── 是 → Apache 2.0
               └── 否 → 双许可（Apache 2.0 OR MulanPSL-2.0）
3. 是否需要「下游修改必须回流」的保证？
     └── 是 → 考虑 Mulan PubL v2 / MPL-2.0
4. 是否涉及大量专利组合并希望明示授权？
     └── 是 → 在 Mulan PSL v2 与 Apache 2.0 之间按市场选

10.4 选型后的后续工作

选定许可证只是第一步，还需要：

  1. LICENSE 文件、CONTRIBUTING 文件、CLA 模板、Security 策略；
  2. 源码文件头部的 SPDX 标识；
  3. CI 中的许可证扫描；
  4. 第三方依赖的完整许可证列表；
  5. 定期审计与更新。

10.5 常见问答（FAQ）

Q1：我可以把 Apache 2.0 项目 fork 后改为 Mulan PSL v2 吗？ A1：Apache 2.0 允许 re-license 为兼容的宽松许可证。但请注意：你只能对你自己的修改以 Mulan PSL v2 发布；原 Apache 2.0 部分仍保持 Apache 2.0 归属与声明。完全「改色」需要获得所有原作者同意，这通常不可行。

Q2：Mulan PSL v2 能与 GPL 结合分发吗？ A2：GPL 是强 Copyleft，与宽松许可证结合时，整体通常需按 GPL 分发。Mulan PSL v2 对上游 GPL 代码没有禁止，但整体项目若含 GPL 代码，仍需遵守 GPL 条款。具体请参考 FSF 对 GPL 兼容性的评估。

Q3：Mulan PSL v2 可以用于 SaaS 项目吗？ A3：可以。Mulan PSL v2 是宽松许可证，对 SaaS 场景无源代码披露要求（与 AGPL 不同）。如希望对 SaaS 场景也要求披露，应考虑 AGPL 而非 Mulan 家族。

Q4：我在 GitHub 上开源，许可证能选 Mulan PSL v2 吗？ A4：可以。GitHub 已识别 MulanPSL-2.0。但 GitHub 的「Add license」向导中默认不推荐 Mulan PSL，需要手动创建 LICENSE 文件。

Q5：Mulan PSL v2 的中文版本与英文版本如果在日后修订时不同步更新怎么办？ A5：COSCL 承诺 v2 文本冻结，不作修订。若出现分歧，以中文版为准。未来若有 v3，项目方可选择是否升级。

Q6：我公司海外上市在即，法务担心 Mulan 项目会被美国投资人质疑。 A6：Mulan PSL v2 是 OSI 认证的许可证，从投资合规角度属于「标准开源许可证」。建议在招股书「知识产权」章节中说明：项目采用 OSI 认证的 Mulan PSL v2，与 Apache 2.0 在自由使用范围上等价。

Q7：如何在 npm、PyPI、crates.io、Go modules 这些包管理器中标注 Mulan PSL v2？ A7：npm 的 package.json 使用 "license": "MulanPSL-2.0"；Python 的 setup.cfg 或 pyproject.toml 的 classifier 字段目前尚无 Mulan 条目，可使用 "License :: Other/Proprietary License" 并在 LICENSE 字段注明；crates.io 的 Cargo.toml 的 license 字段接受任意 SPDX 表达式，直接写 MulanPSL-2.0；Go modules 无许可证元数据字段，依赖仓库中的 LICENSE 文件。

Q8：员工离职后，其过往贡献在 Mulan PSL v2 下是否继续有效？ A8：是。Mulan PSL v2 的授权是不可撤销的，员工个人无权单方面撤回已经做出的开源授权。但若该员工的贡献归属于公司（职务作品），归属关系应在劳动合同与 CCLA 中预先明确。

十一、参考资料

  1. Mulan PSL v2 官方文本：license.coscl.org.cn/MulanPSL2
  2. Mulan PubL v2 官方文本：license.coscl.org.cn/MulanPubL2
  3. OSI 认证列表：opensource.org/licenses
  4. SPDX License List：spdx.org/licenses
  5. Apache 2.0 官方文本：apache.org/licenses/LICENSE-2.0
  6. 开放原子开源基金会：openatom.org
  7. openEuler 官方站点：openeuler.org
  8. openGauss 官方站点：opengauss.org
  9. OpenHarmony 官方站点：openharmony.cn
  10. PaddlePaddle 仓库许可说明：github.com/PaddlePaddle/Paddle
  11. 中华人民共和国著作权法（2020 修正）
  12. 中华人民共和国民法典（2020）第五百零六条
  13. 《GPLv3 与中国法》相关学术讨论文集
  14. Gitee 开源许可证使用统计，历年开源中国年度报告
  15. 华为《openEuler 许可证说明》公开文档

附录 A：Mulan 家族与主流许可证特性对照

维度 MIT BSD-3 Apache-2.0 MPL-2.0 LGPL-3.0 GPL-3.0 AGPL-3.0 MulanPSL-2.0 MulanPubL-2.0
类型 宽松 宽松 宽松 弱 Copyleft 弱 Copyleft 强 Copyleft 网络 Copyleft 宽松 弱 Copyleft
专利条款 无 无 有 有 有 有 有 有 有
专利反制 无 无 有 有 有 有 有 有 有
分发要保留声明 是 是 是 是 是 是 是 是 是
NOTICE 文件 无 无 要 无 无 无 无 无 无
管辖法 未指定 未指定 未指定 加州 未指定 未指定 未指定 中国法 中国法
OSI 认证 是 是 是 是 是 是 是 是 否
FSF-free 是 是 是 是 是 是 是 未评估 未评估
GPLv3 兼容 是 是 是 否 是（需配合） 自身 是 社区倾向认为单向兼容 未评估
强调中文文本 否 否 否 否 否 否 否 是 是

附录 B：Mulan PSL v2 英文精简表达（非官方，仅供工程快速复述）

Mulan PSL v2 is an OSI-approved permissive license with an explicit patent grant, a patent retaliation clause, and a PRC law governing clause. Both Chinese and English versions are legally binding; the Chinese text prevails on conflict.

附录 C：常用工程脚本

C.1 批量为源文件添加 SPDX 头

#!/usr/bin/env bash
# add_spdx.sh: add SPDX header to *.go / *.c / *.h files if missing
set -euo pipefail
YEAR=$(date +%Y)
HOLDER="Example Inc."
HEADER_GO="// SPDX-License-Identifier: MulanPSL-2.0
// Copyright (c) ${YEAR} ${HOLDER}
"

find . -type f \( -name "*.go" -o -name "*.c" -o -name "*.h" \) | while read -r f; do
  if ! head -n 2 "$f" | grep -q "SPDX-License-Identifier"; then
    tmp="$(mktemp)"
    printf "%s" "$HEADER_GO" > "$tmp"
    cat "$f" >> "$tmp"
    mv "$tmp" "$f"
    echo "Added SPDX: $f"
  fi
done

C.2 验证 LICENSE 文件存在性

#!/usr/bin/env bash
# verify_license.sh
REQUIRED=("LICENSE" "README.md" "CONTRIBUTING.md")
for f in "${REQUIRED[@]}"; do
  if [ ! -f "$f" ]; then
    echo "Missing: $f" >&2
    exit 1
  fi
done
grep -q "MulanPSL-2.0\|Mulan PSL v2" LICENSE || {
  echo "LICENSE does not reference Mulan PSL v2" >&2
  exit 1
}
echo "License files OK."

C.3 生成简单的 SPDX SBOM

#!/usr/bin/env bash
# gen_sbom.sh (very simplified)
cat <<EOF
SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: example-service
DocumentNamespace: https://example.com/spdx/example-service

PackageName: example-service
SPDXID: SPDXRef-Package-example
PackageVersion: 1.0.0
PackageLicenseDeclared: MulanPSL-2.0
PackageLicenseConcluded: MulanPSL-2.0
EOF

C.4 package.json 示例（Node.js 项目）

{
  "name": "@example/mulan-demo",
  "version": "1.0.0",
  "description": "Demo project under Mulan PSL v2",
  "license": "MulanPSL-2.0",
  "repository": {
    "type": "git",
    "url": "https://gitee.com/example/mulan-demo.git"
  }
}

C.5 Cargo.toml 示例（Rust 项目）

[package]
name = "mulan-demo"
version = "0.1.0"
edition = "2021"
license = "MulanPSL-2.0"
repository = "https://gitee.com/example/mulan-demo"
description = "Demo crate under Mulan PSL v2."

C.6 pyproject.toml 示例（Python 项目）

[project]
name = "mulan-demo"
version = "0.1.0"
description = "Demo package under Mulan PSL v2"
license = { text = "MulanPSL-2.0" }
readme = "README.md"
requires-python = ">=3.9"

C.7 Go 项目的 LICENSE 与文件头

Go 模块没有 package.json 样式的许可证字段，约定依赖仓库根目录的 LICENSE 文件。配合每个 .go 文件顶部的 SPDX 标识：

// SPDX-License-Identifier: MulanPSL-2.0
// Copyright (c) 2024 Example Inc.

package main

import "fmt"

func main() {
    fmt.Println("hello, mulan")
}

附录 D：与 Apache 2.0 混合项目的 LICENSE 目录示例

/project-root
├── LICENSE                     // 项目自身 MulanPSL-2.0
├── NOTICE                      // 若含 Apache 2.0 组件，保留 NOTICE
├── LICENSE-APACHE-2.0          // 第三方 Apache 2.0 文本副本
├── LICENSE-BSD-3-CLAUSE        // 第三方 BSD 文本副本
├── LICENSE-MIT                 // 第三方 MIT 文本副本
├── THIRD_PARTY_LICENSES/
│   ├── libfoo-1.2.3-LICENSE    // libfoo 的 LICENSE
│   └── libbar-0.5.1-LICENSE    // libbar 的 LICENSE
├── SBOM.spdx                   // 构建产出的 SBOM
└── README.md                   // 在 License 章节做清晰说明

附录 E：发布公告模板（中英双语）

# Release Notes / 发布说明

**example-service v1.0.0**

License / 许可证: MulanPSL-2.0

This release is licensed under Mulan PSL v2. See LICENSE for details.
In case of conflict between the Chinese and English versions of Mulan PSL v2,
the Chinese version shall prevail.

本版本按照 Mulan PSL v2 许可发布，详见 LICENSE。Mulan PSL v2 的中英文文本
在内容出现不一致时，以中文文本为准。

附录 F：项目治理中的许可证变更流程

实务中，一个活跃项目从 Apache 2.0 或其他许可证变更为 Mulan PSL v2（或反之）并非易事，典型流程：

  1. 治理委员会决议：评估变更动因、影响、法律意见；
  2. 通知全体贡献者：公告、邮件、ISSUE；
  3. 取得贡献者同意：对于不可联系的历史贡献者，需法律评估其贡献是否可按原许可证继续使用而未变更；
  4. 新许可证下的代码以单独 PR 提交并合并；
  5. 发布版本公告，明确新老版本的许可证差异；
  6. 更新 SBOM、产品合规文档、采购指南。

变更许可证是一项会影响商业伙伴与下游用户的重大决策，建议提前半年以上进行准备。

附录 G：开放原子开源基金会对许可证的常见指引

开放原子开源基金会（OpenAtom Foundation）作为中国最重要的开源基金会，对托管项目的许可证选择通常会提出以下指引：

  1. 原创代码优先使用 MulanPSL-2.0；
  2. 对已采用其他兼容许可证（Apache 2.0、BSD、MIT）的项目，可维持原许可证；
  3. 含 Copyleft 代码的项目应在 IP clearance 阶段审慎评估边界；
  4. 所有接受贡献的项目应采用 CLA 或 DCO；
  5. 项目的社区治理文档（Governance、Code of Conduct、Contributing）需对齐基金会模板。

上述指引非硬性条款，但在项目托管评估中会被参考。

附录 H：历次重要时间节点

时间 事件
2019-07 Mulan PSL v1 发布
2019 Mulan PubL v1 发布
2019 华为正式宣布 openEuler 开源
2020-02 Mulan PSL v2 通过 OSI 认证
2020-06 openGauss 开源
2020-09 OpenHarmony 项目发起，捐赠给开放原子开源基金会
2021-06 开放原子开源基金会接收 openEuler 捐赠
2022 openEuler 22.03 LTS 正式版发布，MulanPSL-2.0 成为默认
2023 Gitee 上 MulanPSL 项目数显著增长
2024 多家 OSPO 工具全面支持 MulanPSL-2.0 识别

附录 I：术语表

附录 J：工程 checklist（打印版）

[ ] LICENSE 文件使用 MulanPSL-2.0 并引用官方 URL
[ ] 每个源文件具备 SPDX-License-Identifier 头
[ ] 第三方依赖的原许可证文件完整保留
[ ] Apache 2.0 组件的 NOTICE 文件保留并传递
[ ] CLA / DCO 流程就位
[ ] CI 中的许可证扫描启用
[ ] SBOM 能按 SPDX / CycloneDX 正确导出
[ ] README 中声明许可证与语言优先规则
[ ] 发布公告包含中英双语许可证说明
[ ] 合规白名单包含 MulanPSL-2.0

本文为工程参考，不构成法律意见。涉及具体法律风险请咨询专业法律顾问。

上一篇：AGPL、SSPL、BSL：云厂商时代的”反云”许可证

下一篇：文档、数据、模型的许可：CC、ODbL、OpenRAIL、LLaMA 协议

同主题继续阅读

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

2026-04-22 · architecture / opensource

开源许可与版权工程

面向中国工程团队的开源许可、版权与合规系列。从 GPL、AGPL、Apache、木兰协议到中国真实案例、SCA/SBOM 工具链与出海合规，讲清楚开源在工程落地中的坑与方法。

2026-04-22 · architecture / opensource

【开源许可与版权工程】开源世界全景：从 GNU 到大模型的四十年

一篇写给中国工程团队的开源世界地图：从 1983 年 Richard Stallman 发起 GNU 项目、1998 年 OSI 成立、2018 年 MongoDB 更改 SSPL，到 2020 年开放原子开源基金会成立、再到 2024 年大模型时代的 OpenRAIL 与 LLaMA 许可，把四十年的关键事件、基金会、协议演进和中国线索串成一张可直接指导选型的全景图。

By .