【开源许可与版权工程】MIT、BSD、Apache 2.0：宽松许可证的真实区别

在开源世界里，MIT、BSD、Apache 2.0 是使用频率最高的三类「宽松许可证（permissive license）」。它们常常被一并称作「随便用」许可证，但这种说法在工程实践里是危险的：三者在「专利授权（patent grant）」「NOTICE 文件义务」「再授权（sublicense）自由度」等维度上存在显著差异，而这些差异在企业合规、跨国协作、并购尽调等场景中会直接决定项目能否被采纳。

本文不是一份法律文件，而是一份「工程参考」。目标读者是：需要为团队新项目选型许可证的架构师、需要处理第三方依赖合规的 SRE/DevOps、需要审计开源代码引入风险的技术负责人。文中所有条款解读均以 SPDX、OSI、FSF 公开文本为依据，不依赖任何内部资料。

一、为什么「宽松」不等于「无义务」

1.1 开源许可证谱系回顾

开源许可证（open source license）通常按「传染性」维度划分为三大阵营：

1. 宽松许可证（permissive license）：允许在几乎任意条件下使用、修改、再分发，包括闭源商用。代表：MIT、BSD、Apache 2.0、ISC、MPL（部分文件级 copyleft，介于二者之间）。
2. 弱 copyleft（weak copyleft）：对「直接修改的文件」施加 copyleft 义务，但允许在更大工程中以链接方式与闭源代码共存。代表：LGPL、MPL 2.0。
3. 强 copyleft（strong copyleft）：要求任何包含该代码的「衍生作品（derivative work）」在分发时也必须以同样的协议开源。代表：GPLv2、GPLv3、AGPLv3。

本文聚焦于第一阵营。即便是宽松许可证，也并非「零义务」——所有主流 permissive 许可证都至少要求：

• 保留原作者的版权声明（copyright notice）。
• 保留许可证文本或其引用。
• 不得移除免责声明（warranty disclaimer）。

Apache 2.0 之上还要求保留 NOTICE 文件、显式声明对原始文件的修改，而 BSD-3-Clause 额外要求不得用原作者的名义为衍生作品背书。这些义务在源码级分发时几乎是免费的，但在「编译后的二进制分发」「前端 bundle」「容器镜像」场景里经常被无意违反。

1.2 Permissive 与 copyleft 的核心差异（一句话版）

Permissive 许可证的哲学根源可追溯到 1980 年代的 BSD UNIX 与 MIT X Window 项目。它们本身就是大学、研究机构为推广学术成果而设计的：允许任何人在任何环境下使用，只要承认这段代码的学术血统即可。

1.3 「MIT 就是随便用」这个误解从何而来

工程师在日常语境里说「这个库是 MIT 的，随便用」，通常指的是：

• 不必开源我的代码；
• 不必支付版权费；
• 不必征求原作者同意。

这些都没错。但「随便用」不等于「随便分发」。MIT 的原文只有两段话，却实打实写明了分发条件：

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

最后一句「shall be included in all copies or substantial portions」是强制义务。在实践中，最常见的违反场景是前端 bundler 在 minify 时把 LICENSE 注释剥掉后未补回，或是 Docker 镜像里只保留可执行文件、丢掉 /usr/share/doc/<pkg>/ 下的 LICENSE。

1.4 宽松许可证下真正存在的义务清单

汇总后，宽松许可证可能要求你履行的义务包括：

1. 保留版权声明（所有）。
2. 保留许可证文本（所有）。
3. 保留免责声明（所有）。
4. 保留修改声明（Apache 2.0 Section 4(b)）。
5. 保留并分发 NOTICE 文件（Apache 2.0 Section 4(d)）。
6. 不得使用原作者姓名或组织名称做背书（BSD-3-Clause、Apache 2.0 第 6 节关于商标的规定）。
7. 不得将广告必须提及原作者（BSD-4-Clause 历史条款，已废除但仍存在于部分老代码）。

真正「零义务」的许可证只有 0BSD、Unlicense、CC0 等极少数。它们的法律含义接近公有领域（public domain），但不完全等同（不同司法辖区对「主动放弃版权」的效力认定不一致）。

二、MIT 许可证（1988）

2.1 文本解读

MIT 许可证起源于 1980 年代末麻省理工学院的 X Window System 项目。其现代标准文本（SPDX 标识 MIT）如下：

MIT License

Copyright (c) <year> <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

三段文字，包含了完整的授权逻辑：

• 第一段：授权范围。「free of charge」+ 几乎所有动词（use、copy、modify、merge、publish、distribute、sublicense、sell）都被允许。sublicense 特别重要，意味着你可以把它并入一个更严格的许可证下再分发。
• 第二段：条件。只有一个条件——把这份「copyright notice」和「permission notice」包含在所有副本或「substantial portions」（实质性部分）中。什么算「substantial」？MIT 许可证没定义，但业界共识是：任何非琐碎（non-trivial）的代码片段都算。
• 第三段：免责。大写的「AS IS」是英美法系的标准免责措辞，表明作者不对软件的任何适销性（merchantability）、特定用途适用性（fitness for a particular purpose）、或非侵权性（non-infringement）做任何担保。

2.2 MIT 的变体

虽然 SPDX 只收录了一个标准 MIT，但历史上和现实中存在多种变体：

MIT-0（Zero-Clause MIT）

AWS 在 2018 年左右推广的变体，SPDX 标识 MIT-0。与标准 MIT 的唯一区别是：不要求保留 copyright notice。文本上删除了「The above copyright notice and this permission notice shall be included…」这一段。

适用场景：当你希望代码片段被复制到教学、示例、文档中，而不需要粘贴者承担保留声明的义务。AWS 用于其 aws-samples 组织下的大量示例代码。

MIT with advertising clause（历史）

极少数老项目（如早期的某些 X 相关工具）使用过带广告条款的 MIT 变体，要求「所有广告材料必须提及原作者」。这类变体与 GPL 不兼容，且大多数已经改用标准 MIT。SPDX 未单独收录此变体。

X11 License

严格来说，X Window System 使用的是「X11 License」而非现代 MIT。二者文本几乎相同，但 X11 多出一段关于「不得使用作者名字作背书」的文字，更接近 BSD-3-Clause。SPDX 将其作为独立标识 X11。实践中，很多项目把它归类为「MIT」，但做合规扫描时应当区分。

Expat License

另一个常见同义词。XML 解析库 Expat 使用的许可证就是标准 MIT，因此 FSF 有时用 Expat License 指代现代 MIT，以避免与 X11 混淆。

# SPDX 标识对照表
MIT            标准 MIT / Expat
MIT-0          零条款 MIT
X11            X11 License（MIT + no-endorsement）
MIT-advertising 历史变体（GPL 不兼容）
MIT-CMU        CMU 实验室变体（与 BSD 类似）

2.3 工程影响

2.3.1 版权声明被剥离的场景

在源码分发场景下履行 MIT 义务非常简单，只要保留文件开头的 LICENSE 注释即可。但在以下场景里，声明容易被无意剥离：

1. 前端 bundler（webpack、rollup、esbuild、vite）在 production 模式下默认会删除注释。需要通过 TerserPlugin 的 extractComments 选项把注释抽出到 bundle.js.LICENSE.txt。
2. 二进制编译（如 Go 的 go build、Rust 的 cargo build --release）不会把源代码注释带进二进制。需要在发行物里单独附带 LICENSES/ 目录或 NOTICE 文件。
3. Docker 多阶段构建中，COPY --from=builder /app/binary / 这种命令只拷贝二进制，会丢失 LICENSE。推荐做法是 COPY --from=builder /app/LICENSES /LICENSES。
4. npm 包在 npm publish 时，如果 package.json 的 files 字段没列入 LICENSE，且 .npmignore 没显式包含，LICENSE 文件可能不会被打包。

2.3.2 npm 生态中的归因实践

现代 JS 工具链已经有比较完善的归因（attribution）工具：

# 生成所有依赖的许可证清单
npx license-checker --production --json > licenses.json

# 只检查不合规的
npx license-checker --production --onlyAllow "MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC"

# webpack 场景
npm install --save-dev license-webpack-plugin

license-webpack-plugin 可以在产物中自动生成 bundle.js.LICENSE.txt，把所有依赖的 LICENSE 文本聚合进去，这是满足 MIT 「保留声明」义务最简洁的方式。

2.3.3 与 GPL 的兼容性

MIT 与 GPLv2、GPLv3 都兼容。这里的「兼容」含义是：你可以把 MIT 代码并入 GPL 项目，整体以 GPL 分发（反之不行）。MIT 没有专利条款，所以也不存在与 GPLv2 之间的「显式专利授权冲突」——这是 Apache 2.0 与 GPLv2 不兼容的核心原因（详见第五节）。

FSF 在 gnu.org/licenses/license-list.html 中将 MIT/Expat 列为「GPL 兼容的宽松许可证」。

三、BSD 许可证家族的演变

3.1 Original BSD 4-Clause（1980 年代）

Berkeley Software Distribution（BSD）起源于加州大学伯克利分校计算机系统研究组（Computer Systems Research Group，CSRG）对 AT&T UNIX 的改进。1980 年代中期，伴随 BSD 4.3 的发布，形成了标准的「BSD 4-Clause」许可证文本：

Copyright (c) <year>, The Regents of the University of California.
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice,
   this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice,
   this list of conditions and the following disclaimer in the documentation
   and/or other materials provided with the distribution.

3. All advertising materials mentioning features or use of this software
   must display the following acknowledgment:
     "This product includes software developed by the University of
      California, Berkeley and its contributors."

4. Neither the name of the University nor the names of its contributors
   may be used to endorse or promote products derived from this software
   without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS" AND ...

其中第 3 条就是臭名昭著的「advertising clause（广告条款）」。

3.1.1 Advertising clause 为什么是问题

advertising clause 的字面要求是：任何提及该软件功能或用途的广告材料，都必须印出指定的致谢文字。这在今天看来已经很奇怪，但在 1980 年代，BSD 开发者希望以此获得学术界的能见度。

问题在第二阶段爆发——「contributors」这个词是复数。很多项目基于 BSD 4-Clause 派生时会把「University of California, Berkeley」替换成自己的机构名，并把新的「acknowledgment」加入第 3 条。结果是：如果你的产品集成了 N 个 BSD-4-Clause 组件，你的广告材料就得印 N 段致谢。

FSF 曾在公开材料中指出，到 1990 年代后期，一些 BSD 衍生品已经积累了超过 75 条互不兼容的 advertising acknowledgment。NetBSD 内核在全盛时期据称需要打印近百行致谢文字。这是工程和法律的双重噩梦。

更致命的是，FSF 明确判定 advertising clause 与 GPL 不兼容，因为 GPL 禁止在「本协议规定之外再附加任何限制」，而要求所有广告材料包含特定文字显然是一项附加限制。

3.2 Advertising Clause 的废除（1999）

1999 年 7 月 22 日，UC Berkeley 技术许可办公室（Office of Technology Licensing）主任 William Hoskins 签署了一封给 CSRG 所有相关方的信函，正式放弃 advertising clause 对 Berkeley 代码的约束。原文关键段落可以在 ftp 归档与多份公开转录中找到：

July 22, 1999

To All Licensees, Distributors of Any Version of BSD:

As you know, certain of the Berkeley Software Distribution ("BSD")
source code files require that further distributions of products
containing all or portions of the software, acknowledge within their
advertising materials that such products contain software developed
by UC Berkeley and its contributors.

Specifically, the provision reads: ...

Effective immediately, licensees and distributors are no longer
required to include the acknowledgement within advertising materials.
Accordingly, the foregoing paragraph of those BSD Unix files containing
it is hereby deleted in its entirety.

William Hoskins
Director, Office of Technology Licensing
University of California, Berkeley

这封信只对「Berkeley 本身拥有版权的那部分 BSD 代码」生效。它并不能自动消除所有第三方基于 BSD 4-Clause 派生代码中的 advertising clause——那些代码仍需各自的版权方单独声明放弃。这是为什么即便到今天，FreeBSD、NetBSD、OpenBSD 的 src tree 里，仍零星残存着带有 advertising clause 的第三方文件。

废除后的 BSD 就变成了「BSD 3-Clause」。FSF 也同步更新判断：BSD 3-Clause 与 GPL 兼容，BSD 4-Clause 与 GPL 不兼容。

3.3 BSD-3-Clause

SPDX 标识 BSD-3-Clause，现代标准文本：

Copyright (c) <year>, <copyright holder>
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice,
   this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice,
   this list of conditions and the following disclaimer in the documentation
   and/or other materials provided with the distribution.

3. Neither the name of the copyright holder nor the names of its contributors
   may be used to endorse or promote products derived from this software
   without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES ...

三条件：

1. 源码再分发保留版权声明。
2. 二进制再分发在文档中保留版权声明。
3. 不得用版权持有人或贡献者名义为衍生品做背书或促销。

第 3 条的「no-endorsement」在工程层面意味着：你可以在产品里使用 FreeBSD、PostgreSQL（PostgreSQL 使用类似 BSD 的 PostgreSQL License）、LLVM 的代码，但你不能说「Endorsed by FreeBSD Foundation」或「Powered by PostgreSQL team」，除非你拿到书面许可。但你可以说「This product uses PostgreSQL」这种事实陈述。

该条款本质上是版权许可证里的一个「商标保护补丁」——它不是商标法条款，但在许可证层面提供了类似保护。

3.4 BSD-2-Clause（Simplified BSD）

SPDX 标识 BSD-2-Clause，又叫 FreeBSD License 或 Simplified BSD。与 3-Clause 的唯一区别是删除了第 3 条 no-endorsement，只保留保留声明 + 二进制文档声明。

1. Redistributions of source code must retain the above copyright notice, ...
2. Redistributions in binary form must reproduce the above copyright notice, ...

什么时候选 BSD-2-Clause：

• 你是个人或小团队，不担心有人用你的名义为产品背书（因为你的名字本就没什么商誉）。
• 你希望条款尽可能精简，接近 MIT。
• FreeBSD 项目本身推荐新代码使用 BSD-2-Clause。

什么时候选 BSD-3-Clause：

• 你是有机构品牌的组织，需要通过许可证显式禁止他人以你的名义做营销。
• 你的项目有较大社区影响力，担心「fork 并商业化后仍使用你的商标」。

3.5 0BSD（Zero-Clause BSD）

SPDX 标识 0BSD。由 Rob Landley 在 toybox 项目中提出。文本只保留了授权 + 免责两段，连「保留版权声明」都不再要求：

Copyright (C) <year> by <author>

Permission to use, copy, modify, and/or distribute this software for any
purpose with or without fee is hereby granted.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES ...

0BSD 与 CC0（Creative Commons Zero）相比：

• CC0 是「主动放弃所有版权和相邻权利（waive）」，法律效果上试图直接进入公有领域。但「waive」在很多大陆法系国家（包括德国、法国）被认为不可能，因此 CC0 自带了一个「fallback license」作为兜底。
• 0BSD 是「以许可证方式授予无限制使用权」。它不试图处置版权本身，而是绕开：无论版权在哪，使用者都已获得免费无限制许可。在大陆法系国家更可靠。

当你希望把代码「捐给人类」时，0BSD 在工程上比 CC0 更不容易出问题，尤其是跨国分发场景。

3.6 ISC 许可证

Internet Systems Consortium（ISC）在维护 BIND、DHCP 等互联网基础设施时设计了 ISC License。SPDX 标识 ISC。文本比 MIT 更短：

Copyright (c) <year>, <copyright holder>

Permission to use, copy, modify, and/or distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, ...

功能上 ISC 与 MIT 等价，条件都是「保留声明 + AS IS」。存在两个许可证只是历史原因：ISC 的律师在 1990 年代末基于 BSD 简化得出，此时 MIT 已经流行，但 OpenBSD 社区决定统一用 ISC 作为自家首选，因为它的措辞更简洁且用了单数 copyright holder（BSD 原文里的「Regents of the University of California」显然不适合普通项目）。

npm 生态中大量 node 核心组件（如 abbrev、glob 等）使用 ISC。在 SPDX 扫描时，ISC 和 MIT 的合规性可以视同等价，但记账时仍需分别记录。

OpenBSD 内部对新代码的默认要求是 ISC；如果不合适再降级到 BSD-2-Clause；仅在必须时使用 BSD-3-Clause。

四、Apache License 2.0（2004）

4.1 Apache License 1.0 / 1.1 的历史包袱

Apache 项目最早（1995 年前后）使用的许可证脱胎于 BSD 4-Clause，因此也继承了 advertising clause。Apache 1.0 的第 3 条是：

3. The end-user documentation included with the redistribution, if any,
   must include the following acknowledgment:
     "This product includes software developed by the Apache Software
      Foundation (http://www.apache.org/)."
   Alternatively, this acknowledgment may appear in the software itself, ...

与 BSD 4-Clause 一样，这条后来被证明与 GPL 不兼容，且给整合带来麻烦。

Apache 1.1（2000 年）对此做了部分清理：把「必须出现在广告中」改为「可以出现在软件自身或文档中」，缓解了广告场景的麻烦。但保留了另一条限制——第 4、5 条对「Apache」这个名字的使用作了严格规定，禁止在未获许可的情况下以「Apache」命名衍生产品。

即便如此，Apache 1.1 与 GPL 的关系仍是「部分兼容、部分不兼容」，让 ASF 以外的项目集成时非常痛苦。

2004 年 1 月，ASF 发布 Apache License 2.0，彻底重写了文本。2.0 与 1.x 基本不共享文字。

4.2 Apache 2.0 的核心条款

Apache License 2.0 是目前 permissive 阵营中最长、最工程化的许可证文本，约 200 行。核心条款按 section 编号：

• Section 1：术语定义（Definitions）。License、Licensor、You、Contribution、Contributor、Derivative Works、Source、Object 等都有严格定义。
• Section 2：版权许可授予（Grant of Copyright License）。永久、全球、非独占、免费、不可撤销。
• Section 3：专利许可授予（Grant of Patent License）。同上，且附带专利反诉条款。这是 2.0 最重要的创新。
• Section 4：再分发条件（Redistribution）。
• Section 5：贡献提交（Submission of Contributions）。任何贡献默认以 Apache 2.0 条款提交，除非贡献者显式另行约定。
• Section 6：商标（Trademarks）。不授予对 Licensor 商标的使用权。
• Section 7：免责（Disclaimer of Warranty）。
• Section 8：责任限制（Limitation of Liability）。
• Section 9：接受担保或支持（Accepting Warranty or Support）。下游分发者可以自行提供支持承诺，但责任归自己。

Section 4 规定了再分发必须满足的四项条件：

You may reproduce and distribute copies of the Work or Derivative Works
thereof in any medium, with or without modifications, and in Source or
Object form, provided that You meet the following conditions:

(a) You must give any other recipients of the Work or Derivative Works
    a copy of this License; and

(b) You must cause any modified files to carry prominent notices stating
    that You changed the files; and

(c) You must retain, in the Source form of any Derivative Works that You
    distribute, all copyright, patent, trademark, and attribution notices
    from the Source form of the Work, excluding those notices that do not
    pertain to any part of the Derivative Works; and

(d) If the Work includes a "NOTICE" text file as part of its distribution,
    then any Derivative Works that You distribute must include a readable
    copy of the attribution notices contained within such NOTICE file, ...

其中 (d) 就是 NOTICE 文件义务的来源。

附录（APPENDIX）给出了如何在自己项目里应用 Apache 2.0 的标准样板：

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

这段通常放在源文件顶部注释里。

4.3 专利授权条款（Section 3）

Apache 2.0 Section 3 的完整原文：

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. 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.

这条分成两半：

4.3.1 显式专利授权（Patent Grant）

每个贡献者（contributor）对自己的贡献中「必然被侵犯的专利权利要求（patent claims necessarily infringed）」授予所有使用者永久、全球、免费、不可撤销的许可。换言之：如果你给一个 Apache 2.0 项目提交了代码，且该代码依赖你公司持有的某项专利，那么你公司就默认地把这项专利授权给了所有使用者，限定在「运行该代码所必需」的范围内。

这解决了 MIT/BSD 时代的一个重大法律不确定性：版权许可不等于专利许可。一家公司可以以 MIT 分发代码，然后再以专利起诉用户。Apache 2.0 直接堵上了这个后门。

4.3.2 专利反诉条款（Patent Retaliation）

Section 3 的后半段规定：如果你对该项目发起专利侵权诉讼（包括反诉、交叉诉讼），你从所有贡献者处获得的专利许可立即终止。

这是一个「核威慑」条款，防止受益于开源项目的公司反过来用专利攻击其他使用者。典型应用场景：甲公司使用了 Apache 2.0 的 A 项目，同时又起诉乙公司对 A 项目做了专利侵权，那么甲公司对 A 项目的所有贡献者的专利许可立即失效——这意味着甲公司自己也暴露在专利风险中。

4.3.3 为什么 MIT / BSD 没有专利条款

MIT、BSD 的文本成型于 1980 年代，当时软件专利在美国尚未普及（真正的软件专利爆发是在 1998 年的 State Street Bank 判决之后）。那个时代的许可证设计者没有把「专利授权」纳入视野。

从法律解读看，目前主流意见是：MIT 和 BSD 隐含（implicitly）授予了「为使用软件所必需的专利许可」，因为许可证明示授权「use、copy、modify、distribute」，若贡献者试图以专利阻止这些行为，将违反许可证精神（contract-law 意义上的 estoppel 原则）。但这仅是学界与实务共识，没有像 Apache 2.0 那样写进文本。在重视合规可验证性的大企业法务看来，「隐含」和「显式」差距巨大。

4.3.4 实际影响：企业法务为什么偏好 Apache 2.0

在大型企业的开源依赖审查（Open Source Review Board，OSRB）流程中，许可证通常按风险等级划分：

• 绿色（直接批准）：Apache 2.0、MIT、BSD-2/3-Clause、ISC。
• 黄色（需审查）：LGPL、MPL、EPL 等弱 copyleft。
• 红色（禁用或特批）：GPL、AGPL（除非产品本身开源）。

在绿色列表内，Apache 2.0 的「审查成本」最低，因为：

1. 显式专利条款消除了专利不确定性。
2. 条款文本由 ASF 律师撰写，语言严谨，跨司法辖区一致性强。
3. NOTICE 机制把归因义务标准化，工具链（FOSSA、Black Duck、ScanCode）都能自动处理。
4. 在并购（M&A）尽调中，Apache 2.0 依赖几乎不产生额外问题。

4.4 NOTICE 文件的工程义务

Section 4(d) 原文关键部分：

(d) If the Work includes a "NOTICE" text file as part of its distribution,
    then any Derivative Works that You distribute must include a readable
    copy of the attribution notices contained within such NOTICE file,
    excluding those notices that do not pertain to any part of the
    Derivative Works, in at least one of the following places: within a
    NOTICE text file distributed as part of the Derivative Works; within
    the Source form or documentation, if provided along with the Derivative
    Works; or, within a display generated by the Derivative Works, if and
    wherever such third-party notices normally appear. The contents of the
    NOTICE file are for informational purposes only and do not modify the
    License.

4.4.1 NOTICE 应当包含什么

Apache 2.0 规定 NOTICE 只能是「attribution notices」——归因性信息。具体不外乎：

Apache Kafka
Copyright 2012-2024 The Apache Software Foundation.

This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).

NOTICE 不能含增补性许可条款。如果你写「by using this software you agree to …」这样的条款进 NOTICE，实际上无效，Apache 2.0 明确说「The contents of the NOTICE file are for informational purposes only and do not modify the License」。

4.4.2 如何在衍生作品中履行 NOTICE 义务

当你分发包含 Apache 2.0 组件的衍生作品时，你必须选择以下至少一种方式把归因信息呈现给使用者：

1. 在衍生作品的根目录放一个 NOTICE 文件，包含合并后的所有归因文字。
2. 在源码或文档中展示。
3. 在衍生作品的 UI 里显示（例如桌面应用的「关于」对话框、网站的 /legal 页面）。

合并 NOTICE 的一个典型例子——Apache Superset 的 NOTICE 可能长这样：

Apache Superset
Copyright 2016-2024 The Apache Software Foundation

This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).

-----

Portions of this product include software developed by:

- Apache Kafka (Copyright 2012-2024 The Apache Software Foundation)
- Apache Calcite (Copyright 2012-2024 The Apache Software Foundation)
- Apache Commons Lang (Copyright 2001-2024 The Apache Software Foundation)

4.4.3 前端 bundler 剥离 NOTICE 的问题

这是 JavaScript 生态里最容易踩的坑。以 webpack 为例：

// webpack.config.js
const TerserPlugin = require('terser-webpack-plugin');
const LicenseWebpackPlugin = require('license-webpack-plugin').LicenseWebpackPlugin;

module.exports = {
  optimization: {
    minimizer: [
      new TerserPlugin({
        extractComments: true, // 把 /*! ... */ 注释抽到 .LICENSE.txt
      }),
    ],
  },
  plugins: [
    new LicenseWebpackPlugin({
      perChunkOutput: false,
      outputFilename: 'third-party-licenses.txt',
      // 关键：对 Apache-2.0 依赖同时输出 NOTICE
      renderLicenses: (modules) => {
        return modules.map(m => {
          const notice = m.packageJson.licenseNotice
            || '(no NOTICE file)';
          return `${m.name}@${m.version}\n${m.licenseText}\n\nNOTICE:\n${notice}`;
        }).join('\n\n---\n\n');
      },
    }),
  ],
};

rollup 有对应的 rollup-plugin-license，esbuild 在插件生态里有 esbuild-plugin-license。Vite 可以复用 rollup 插件，因为其底层打包是 rollup。

对于移动端与桌面端（React Native、Electron、Tauri），在「关于」页嵌入一个从构建期抓取的 third-party-licenses.txt 是最稳妥的方式。

4.4.4 合规工具链

常见扫描与报告工具：

# ScanCode Toolkit（开源，最权威的许可证检测）
pip install scancode-toolkit
scancode --license --copyright --package --json-pp result.json ./src

# licensecheck（轻量）
pip install licensecheck
licensecheck --using requirements

# Node 生态
npx license-checker --production --summary

# 商业 SaaS（CI 集成）
# - FOSSA (fossa.com)
# - Black Duck (Synopsys)
# - Snyk License Compliance
# - WhiteSource / Mend

4.5 再授权权利

Apache 2.0 本身不允许完全再授权（sublicense）——它允许你以 Apache 2.0 条款再分发衍生作品，但 Section 4(a) 明确要求必须把 Apache 2.0 License 的副本随作品一起分发。

那么「Apache 2.0 → MIT 再授权」到底可不可行？常见问题分解：

4.5.1 Apache 2.0 → MIT

可以，但有限制。你不能简单地「把协议文件改成 MIT」，因为 Apache 2.0 要求 (a)(c) 保留原许可证与归因。正确做法是双重持牌（dual licensing）：在衍生作品中，原始 Apache 2.0 组件仍按 Apache 2.0 条款存在（含其 LICENSE、NOTICE、代码内 copyright 头），而你新增的原创部分可以以 MIT 发布。整体作品对使用者来说「部分 Apache 2.0、部分 MIT」。

你不能做的是：声称整个衍生作品都是 MIT——这会删除 Apache 2.0 Section 4 要求的保留义务，构成违约。

4.5.2 Apache 2.0 → GPL

• Apache 2.0 与 GPLv3 兼容。你可以把 Apache 2.0 代码合并进 GPLv3 项目，整体以 GPLv3 分发。
• Apache 2.0 与 GPLv2 不兼容。原因是 Apache 2.0 的专利反诉条款（Section 3 后半段）被 FSF 解读为 GPLv2 所禁止的「附加限制」。GPLv3 专门设计了与 Apache 2.0 兼容的兜底措辞（Section 11 of GPLv3），因此兼容。
• 这意味着：Linux 内核（GPLv2-only）理论上不能合并 Apache 2.0 代码。实务中经常通过把 Apache 2.0 文件以「用户空间库」形式保留而非内联进内核来绕过。

4.5.3 Apache 2.0 → 闭源商业

完全允许。只需在分发中保留 LICENSE、修改声明、NOTICE。这是 Apache 2.0 成为企业友好标准的根本原因。

五、三者条款对比矩阵

5.1 权利与义务矩阵

下表汇总 MIT、BSD-2、BSD-3、ISC、Apache 2.0 在各维度上的差异：

5.2 GPL 兼容性矩阵

「兼容」这里的方向是「可以合并进 GPL 项目并以 GPL 分发」，反之不成立（GPL 是强 copyleft，不能降级到宽松协议）。

5.3 工程选择速查

六、工程坑点

6.1 BSD advertising clause 的历史包袱

6.1.1 老包里的 4-Clause 文本

进入 2020 年代，多数主流项目已经切换到 BSD-3-Clause 或 BSD-2-Clause，但大量古老的代码片段仍在代码库里携带 4-Clause 文本。典型来源：

• 从 4.4BSD-Lite 分支继承的加密、网络、文件系统代码。
• 1990 年代第三方工具（如早期的 Kerberos、sendmail 部分文件）。
• 某些硬件厂商的驱动代码（sun、sgi 等）遗留下来的文件头。

这些文件即使出现在今天的 FreeBSD、NetBSD、OpenBSD 源码树里，如果未经过版权方正式放弃 advertising clause，就仍受 4-Clause 约束。与其合并进 GPL 代码时会产生冲突。

6.1.2 SPDX 标识与实际文本不一致

工程团队常犯的错误：看到 LICENSE 文件写着「BSD License」就认为等于 BSD-3-Clause。真正的判断方法是读源文件头部注释——很多库的 LICENSE 是整体描述，但单个文件的 header 可能声明为 4-Clause。

正确做法：

# 用 scancode 扫描每个文件的 license detect
scancode --license --only-findings -i --json-pp out.json ./src

# 或用 licensee（GitHub 使用的工具）
gem install licensee
licensee detect ./path/to/repo

# 快速 grep（只做初筛，不能替代工具）
grep -r "All advertising materials" --include="*.[ch]" ./

6.1.3 继承老 BSD 代码的实务处理

如果你 fork 了一份含 4-Clause 的老代码，可行的路径：

1. 联系版权方请求以书面形式放弃 advertising clause（参考 Berkeley 1999 的做法）。
2. 如无法联系，保留 4-Clause 文本并在你自己的 LICENSE 中明确标注该文件受 4-Clause 约束。不与 GPL 代码合并。
3. 重写该文件的全部实现（clean-room），以自家许可证发布；原文件作为参考而非依赖。

6.2 重新分发时忘写 copyright notice

6.2.1 最常见的违规

根据业界合规审计的一般观察，宽松许可证下最频发的违规是「二进制分发时未保留版权声明」。具体表现：

• Docker 镜像只打包了可执行文件，没有附带 LICENSE 目录。
• 静态编译的 Go 二进制分发时没随附 LICENSES/THIRD-PARTY.txt。
• 前端产物只有 app.min.js，没有 app.min.js.LICENSE.txt。
• 嵌入式固件刷入设备后，LICENSE 文本从未对终端用户可见。

违规的后果通常是：被合规组织（如 Software Freedom Conservancy）或社区个人发现后，发邮件要求在 X 天内补救，否则采取法律行动。实际走到诉讼的极少，但警告信对品牌形象和企业客户采购都是不小的麻烦。

6.2.2 「保留声明」在编译产物中的可接受形式

对于二进制产物，普遍接受的形式包括：

1. 一个独立的文本文件（如 LICENSES.txt、THIRD-PARTY-NOTICES.txt）随产物一同分发。
2. 一个可通过命令行访问的内嵌信息（如 --licenses flag）。Kubernetes 的 kubectl version --licenses 就是这种做法（早期版本）。
3. 在 GUI 应用的「关于」对话框或专门的法律页面展示。
4. 附带一个「如何获取源代码与完整声明」的书面 offer，同时在 URL 提供。

6.2.3 Android 的 NOTICE.html

Android 系统为处理数以千计的第三方许可证，采用了一个工程上比较极致的方案：把所有第三方 LICENSE 文本聚合成一个巨大的 NOTICE.html，在设置→关于手机→法律信息中打开。这个 HTML 常常有几万行。

Android 的构建系统（Soong 以及更早的 Make）会在构建期自动：

1. 扫描每个被链接进系统镜像的模块的 LICENSE 文件。
2. 抽取其版权段与许可证文本。
3. 合并去重后生成 out/target/common/obj/PACKAGING/systemimage_NOTICE.html。
4. 放入系统镜像，供 Settings 应用读取。

这是大规模分发场景下 MIT/BSD/Apache 2.0 声明保留义务的参考实现。

# Android 源码中相关构建模块
build/make/tools/generate-notice-files.py
build/soong/android/notices.go

6.3 NOTICE 文件被前端 bundler 剥掉

6.3.1 问题示例

假设你的前端应用依赖 apache-commons-echarts-integration（假设名），该库使用 Apache 2.0 并随带一个 NOTICE 文件：

# node_modules/apache-commons-echarts-integration/NOTICE
Apache Commons EChartsIntegration
Copyright 2021-2024 Apache Software Foundation.

This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).

Portions derived from ECharts (Copyright 2017 Baidu Inc., Apache-2.0).

直接 webpack --mode=production 生成的 main.js 里，所有 /* ... */ 形式的注释会被 Terser 删除。NOTICE 文件本身也不在 JS 代码里——它是 package 根目录下的独立文本文件，默认不会被 bundler 打包。

结果：你的产物里完全看不到这段归因信息。如果你把这份 JS bundle 分发给客户（例如嵌入到桌面应用里），你已经违反了 Apache 2.0 Section 4(d)。

6.3.2 修复方案

最简洁的做法是使用 license-webpack-plugin，它会扫描所有进入 bundle 的 package，提取其 LICENSE 和 NOTICE：

// webpack.config.js
const { LicenseWebpackPlugin } = require('license-webpack-plugin');

module.exports = {
  // ...
  plugins: [
    new LicenseWebpackPlugin({
      outputFilename: '[name].third-party-notices.txt',
      perChunkOutput: true,
      addBanner: true, // 在 bundle 顶部加一行引用
      licenseTypeOverrides: {
        // 对 SPDX 识别不出来的包手动指定
        'some-legacy-package': 'MIT',
      },
      renderLicenses: (modules) => {
        return modules.map(m => {
          const parts = [`Package: ${m.name}@${m.version}`];
          parts.push(`License: ${m.licenseId}`);
          if (m.licenseText) parts.push(`\n${m.licenseText}`);
          // 关键：读取 NOTICE 文件
          const fs = require('fs');
          const path = require('path');
          const noticePath = path.join(m.directory, 'NOTICE');
          if (fs.existsSync(noticePath)) {
            parts.push(`\nNOTICE:\n${fs.readFileSync(noticePath, 'utf8')}`);
          }
          return parts.join('\n');
        }).join('\n\n' + '='.repeat(80) + '\n\n');
      },
    }),
  ],
};

构建后产物目录：

dist/
├── main.js
├── main.js.LICENSE.txt         # 来自 TerserPlugin.extractComments
└── main.third-party-notices.txt # 来自 license-webpack-plugin

你还需要确保部署脚本把 main.third-party-notices.txt 也上传到 CDN，并在应用内提供一个可访问的链接（例如 /legal 页面或「关于」菜单）。

6.3.3 vite / esbuild 场景

Vite 底层用 rollup，可直接引用 rollup-plugin-license：

// vite.config.js
import license from 'rollup-plugin-license';

export default {
  plugins: [
    {
      ...license({
        thirdParty: {
          output: {
            file: 'dist/third-party-notices.txt',
            template: (deps) => deps.map(d =>
              `${d.name}@${d.version} — ${d.license}\n${d.licenseText || ''}\n${d.noticeText || ''}`
            ).join('\n\n---\n\n'),
          },
        },
      }),
      apply: 'build',
    },
  ],
};

esbuild 没有官方插件，但社区有 esbuild-plugin-license。如果你用 tsup、unbuild 这类包装器，仍可通过底层配置注入。

6.4 专利授权的不对称风险

6.4.1 MIT/BSD 的隐含专利许可边界

前文提过，MIT/BSD 被学界解读为「隐含授予专利许可」。但以下几点边界值得注意：

1. 隐含许可只覆盖「为实现许可证明示权利所必需」的专利。如果贡献者持有一项不是实现软件所必需的相邻专利，MIT/BSD 不一定覆盖它。
2. 隐含许可的范围通常限于贡献者自己的贡献，不覆盖合并后的整体。Apache 2.0 Section 3 明确把授权范围描述为「Contribution(s) alone or by combination of their Contribution(s) with the Work」。
3. 在某些司法辖区（尤其是大陆法系国家），「隐含许可」理论本身的适用性有争议。

对依赖宽松许可证库的企业而言，这意味着：采用 MIT/BSD 库不能完全消除来自贡献者公司的专利风险。

6.4.2 专利反诉条款的连锁效应

Apache 2.0 Section 3 的专利反诉条款有一个设计得非常巧妙的连锁效应：

1. 甲公司起诉乙公司，主张乙公司对 Apache 2.0 项目 A 的使用侵犯了甲的专利。
2. 该诉讼行为触发 Section 3 后半段：甲公司对 A 的所有贡献者的专利许可立即终止。
3. 这意味着：甲公司自己使用 A 时，现在暴露在 A 的所有其他贡献者的专利风险之下。
4. 如果甲公司恰好是 A 的深度使用者（比如在生产环境跑 A 多年），它突然失去了专利护伞，面临被任何一个贡献者反诉的风险。

这种「核威慑」设计让大公司非常审慎地对待对 Apache 2.0 项目的专利诉讼。

6.4.3 给企业库维护者的建议

如果你在公司里维护一个将作为外部依赖分发的库：

1. 默认选 Apache 2.0。它为你的下游用户提供最清晰的专利立场。
2. 如果必须用 MIT/BSD（例如与某些纯学术生态保持一致），考虑在 README 里显式声明一段「Patent Grant」，本质上是手写一个 MIT + 专利许可的 dual license。但这样做会偏离标准 MIT，可能让扫描工具告警。
3. 建立内部 CLA（Contributor License Agreement）或 DCO（Developer Certificate of Origin）流程，确保贡献者在提交代码时对专利权有明确态度。

七、中国案例：大厂内部为何推荐 Apache 2.0

本节内容均基于公开渠道信息：GitHub 仓库、官方网站、Apache 软件基金会新闻稿、各公司技术博客。不涉及任何内部资料。

7.1 阿里巴巴的协议策略

阿里巴巴是 Apache 软件基金会捐赠项目数量最多的中国公司之一。公开可查的 ASF 顶级项目（TLP）中由阿里主导捐赠的包括：

阿里在 ASF 之外开源的其他基础组件（如 Nacos、Sentinel、Seata、Higress、Spring Cloud Alibaba、Druid 数据源等）也普遍采用 Apache 2.0。这些项目的 GitHub 仓库 LICENSE 文件是公开可验证的。

从公开可见的模式推断，阿里基础技术开源的选型倾向是：

• 基础设施类（middleware、数据库、消息队列、RPC）→ Apache 2.0。
• 内部工具捐赠给 ASF 后，许可证自动由 ASF 统一为 Apache 2.0。
• 专有数据集、训练模型等不走开源代码许可证路径（例如通义千问的模型有单独的使用条款）。

7.2 腾讯与字节跳动的做法

7.2.1 腾讯

腾讯在 GitHub Tencent 组织下的主要开源项目，其许可证分布可以直接从仓库 LICENSE 文件核实。公开可见的 Apache 2.0 项目包括（但不限于）：

• TarsCloud（微服务框架体系，含 TarsCpp、TarsGo、TarsJava 等，大部分是 BSD-3-Clause 或 Apache 2.0，视具体子项目）。
• TNN（神经网络推理框架，Apache 2.0）。
• ncnn（高性能神经网络推理框架，BSD-3-Clause）。
• MMKV（轻量级键值存储，BSD-3-Clause）。
• wepy / omi 等前端项目（MIT）。

腾讯的选型不像阿里那样「几乎一水 Apache 2.0」，存在 BSD-3-Clause 和 MIT 与 Apache 2.0 并存的现象。从工程角度看，这可能与不同业务线（IEG、CSIG、PCG）内部开源治理策略差异有关。

7.2.2 字节跳动

字节跳动在 GitHub bytedance 组织下的主要开源项目大多使用 Apache 2.0，例如：

• Kitex（高性能 Go RPC 框架，Apache 2.0）。
• Hertz（Go HTTP 框架，Apache 2.0）。
• CloudWeGo 系列（Apache 2.0）。
• Volcano（Kubernetes 批调度器，现为 CNCF 毕业项目，Apache 2.0）。
• BytePS（参数服务器训练框架，Apache 2.0）。

字节的开源节奏比腾讯更统一一些，新项目默认 Apache 2.0。

7.2.3 为什么「专利保护比名义保护更重要」

把上面三家的选型统一起来看，能看出一个一致的取舍：

• BSD-3-Clause 的「no-endorsement」条款保护的是组织品牌（不能声称「Endorsed by Tencent」）。
• Apache 2.0 的专利条款保护的是技术资产（防止专利诉讼链）。

对大型互联网公司而言，组织品牌的法律保护可以通过「商标注册 + 外部使用协议」另行解决，不必在开源许可证里实现。而专利风险则是开源许可证能且必须解决的——因为一旦库被广泛使用，后续再追溯谈判专利协议几乎不可能。

7.3 工程团队视角

7.3.1 采购与法务审查

在典型的大型企业采购流程中，引入新的开源依赖通常经过：

1. 技术团队提交依赖说明（名称、版本、许可证、用途）。
2. OSRB 扫描仓库，确认许可证与义务。
3. 法务审查：读许可证文本、评估与产品商业模式的冲突。
4. 批复或要求调整。

在这个链路中，Apache 2.0 依赖几乎总能一路绿灯通过，因为：

• 文本由 ASF 律师写，语义在各主要司法辖区内都被反复审视过。
• 显式专利条款让法务可以一目了然地评估专利风险。
• NOTICE 机制让合规履行标准化，不需要每次都定制流程。

相比之下，GPL 依赖在产品中嵌入时几乎都会触发专项评估。

7.3.2 国际互操作性

ASF 下的项目本身都是 Apache 2.0。如果你的项目要：

• 向 ASF 捐赠。
• 与 ASF 项目代码互相引用。
• 被 ASF 项目作为上游采纳。

那么 Apache 2.0 是默认且唯一的选择。这对希望「走向国际基金会治理」的中国开源项目尤为重要——阿里 Dubbo、RocketMQ 的捐赠路径本质上就预设了 Apache 2.0 基础。

7.3.3 并购尽调中的专利风险

在 M&A（并购）场景中，买方的法务会对目标公司代码库做 FOSS（Free and Open Source Software）尽调。核心关注点之一是「是否存在未明确授权的专利风险」。

使用 Apache 2.0 依赖的代码库在此环节几乎无风险。使用 MIT/BSD 依赖时，尽调方可能会要求：

• 列出所有主要贡献者的专利持有情况。
• 评估是否有来自贡献者公司的专利主张风险。
• 在交易条款中加入相应的陈述与保证（R&W 保险）。

这些额外工作的成本会直接转化为交易延迟或估值折扣。

八、选型建议

8.1 按项目类型选择

8.2 决策流程图

以下是一个简化的决策路径：

你的代码会被外部使用吗？
├── 否 → 不需要 open source license。内部代码通常适用公司专有条款。
└── 是
    │
    ├── 你希望强制下游也开源吗？
    │   ├── 是 → 选 GPL 系（本文未覆盖，下一篇详述）。
    │   └── 否 → 继续。
    │
    ├── 你或你的贡献者持有与该代码相关的专利吗？
    │   ├── 是/可能 → 强烈推荐 Apache 2.0（显式专利授权 + 反诉条款）。
    │   └── 否 → 继续。
    │
    ├── 你有品牌需要保护吗（防止被盗用名义）？
    │   ├── 是 → BSD-3-Clause 或 Apache 2.0。
    │   └── 否 → 继续。
    │
    ├── 你希望完全放弃保留声明的义务吗？
    │   ├── 是 → 0BSD 或 MIT-0。
    │   └── 否 → MIT 或 ISC。
    │
    └── 默认：MIT（最简洁）或 Apache 2.0（最工程化）。

8.3 几个典型决策案例分析

8.3.1 一个新的 Go RPC 框架

• 面向企业用户、希望被大规模采纳。
• 开发团队来自持有专利的科技公司。
• 希望未来可能进入 CNCF 或 ASF。

结论：Apache 2.0。理由：专利、基金会路径、企业接受度，三个维度都指向 Apache 2.0。

8.3.2 个人维护的一个命令行工具

• 单人维护，100~500 行代码。
• 功能简单，不涉及专利。
• 希望最大化被复制、被嵌入。

结论：MIT 或 0BSD。如果希望完全免除归因义务，选 0BSD；否则 MIT。

8.3.3 一个学术实验室的算法库

• 由教授与研究生维护。
• 希望工业界能引用，但不希望被「包装后声称 Endorsed by ××大学」。
• 组件间算法可能有专利待申请。

结论：BSD-3-Clause（no-endorsement）+ 在 README 里显式说明待申请专利的状态。如果专利状态已经明朗，Apache 2.0 更合适。

8.3.4 一个被写入工业标准的参考实现

• 标准组织要求参考实现「开源、不限制使用」。
• 需要跨厂商使用，不能偏向任何一家。
• 标准本身涉及成员的 RAND 专利声明。

结论：Apache 2.0。理由：标准组织需要稳定的专利授权机制，Apache 2.0 的专利条款与 RAND（Reasonable and Non-Discriminatory）声明体系最匹配。

8.4 常见反模式

工程实践中经常看到一些不合适的许可证选择，列举几种反模式供参考：

8.4.1 反模式一：仓库根放 LICENSE=MIT，代码文件头却写 GPL

常见于多人协作但缺乏许可证治理的项目。某些贡献者复制粘贴的代码片段带着原始 GPL 头注释，维护者未统一处理。结果是：法律上整个项目可能被认定为 GPL（因为 GPL 的传染性），或者处于「许可证冲突」的灰色地带。

修复方式：

# 统一扫描文件头
scancode --license --json-pp scan.json ./
jq '.files[] | select(.licenses | length > 0) | {path, licenses: [.licenses[].spdx_license_key]}' scan.json

# 对每个带不一致头注释的文件，重写或移除引入的 GPL 代码

8.4.2 反模式二：自制许可证

偶尔有维护者出于「MIT 不够严谨」的想法自己写一份许可证，比如「XXX Fair Use License」。这几乎总是一个坏决定：

• 不在 SPDX 列表中，扫描工具会标记为 unknown，大多数企业 OSRB 直接拒绝。
• 没有经过律师多轮审阅，措辞可能产生歧义。
• 与主流许可证的兼容性不明。

如果现有许可证无法满足需求，优先考虑 dual licensing（例如 MIT + 商业许可），而不是自造协议。

8.4.3 反模式三：把 Apache 2.0 改头换面

有人会把 Apache 2.0 的文本复制过来，把「Apache Software Foundation」替换成自己的公司名，就作为「公司版本许可证」发布。这一般会产生两个问题：

1. 修改后的文本不再是 Apache 2.0，也不在 SPDX 列表中。
2. Apache License 2.0 本身对 ASF 商标与名称的保护条款（Section 6）被移除后，法律稳健性反而下降。

正确做法是直接用 Apache 2.0，把「Licensor」定义为你自己的公司，不改协议本身。Apache 2.0 的附录样板（APPENDIX）本来就是这么设计的。

8.5 许可证变更的风险与路径

当一个项目已经发布过 N 个版本，希望改换许可证，实务上面临几个问题：

1. 已发布版本的许可证不可撤销。使用者依据旧许可证获得的权利永久有效。
2. 如果代码有多位贡献者，许可证变更通常需要所有贡献者同意，或重写其贡献。
3. 变更为更严格的协议（例如 MIT → GPL）意味着老 fork 可能独立存续。
4. 变更为更宽松的协议通常更容易。

历史上知名的许可证变更案例：

• OpenSSL 在 2018 年从「OpenSSL License + SSLeay License」（双重、与 GPL 不兼容）迁移到 Apache 2.0。整个过程持续多年，联系了数千位历史贡献者。
• Elasticsearch 在 2021 年从 Apache 2.0 改为 SSPL + Elastic License（非 OSI 认证），引发 AWS fork 出 OpenSearch。这不是典型的「宽松内部变更」，而是从开源变成源码可见。
• MongoDB 2018 年从 AGPL 改为 SSPL，类似情形。

如果你的项目尚未有大量外部贡献者，在早期锁定合适的许可证比事后变更要容易得多。这也是本文一再强调「新项目选型要认真」的原因。

九、参考资料

以下为公开可访问的权威文本与分析页面。具体 URL 可能随时间变化，建议搜索标题定位最新版本。

1. SPDX License List：spdx.org/licenses/。包含所有许可证的标准文本、标识符、OSI/FSF 兼容性标记。
2. Open Source Initiative License 页面：opensource.org/licenses/。OSI 批准的许可证列表。
3. FSF License Compatibility：gnu.org/licenses/license-list.html。FSF 对各许可证与 GPL 兼容性的权威判断。
4. Apache License 2.0 全文：apache.org/licenses/LICENSE-2.0。
5. Apache License FAQ：apache.org/legal/src-headers.html 与 apache.org/legal/resolved.html。
6. Berkeley 1999 advertising clause 废除信函：原始 ftp 归档可在 ftp.cs.berkeley.edu 找到，也可在 OpenBSD cvsroot 历史中查阅。
7. FreeBSD Copyright 页面：freebsd.org/copyright/，包含 BSD-2-Clause 的官方推荐样板。
8. OpenBSD 许可证策略：openbsd.org/policy.html。描述 ISC 在 OpenBSD 中的默认地位。
9. Apache Software Foundation Legal Affairs：apache.org/legal/。
10. ScanCode Toolkit 文档：github.com/nexB/scancode-toolkit。开源的许可证自动识别工具。
11. license-webpack-plugin：github.com/xz64/license-webpack-plugin。
12. Android Open Source Project，Notice 生成：源码位于 build/make/tools/generate-notice-files.py 与 Soong 相关部分。

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

十、附录：实务工具与样板

10.1 如何给新项目添加 Apache 2.0

标准步骤：

# 1. 在仓库根目录放 LICENSE 文件（Apache 2.0 全文）
curl -o LICENSE https://www.apache.org/licenses/LICENSE-2.0.txt

# 2. 创建 NOTICE 文件
cat > NOTICE <<'EOF'
<Your Project Name>
Copyright 2026 <Your Company or Name>

This product includes software developed by
<Your Company or Name> (https://example.com/).
EOF

# 3. 在每个源文件头部添加标准 header（Python 示例）
cat > header.py <<'EOF'
# Copyright 2026 <Your Company or Name>
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
EOF

# 4. 批量为源文件添加头（使用 addlicense 工具）
go install github.com/google/addlicense@latest
addlicense -c "<Your Company or Name>" -l apache -y 2026 ./**/*.py

10.2 MIT 的最小模板

MIT License

Copyright (c) 2026 <Your Name>

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

10.3 CI 集成建议

在 CI 流水线里加一个 license-scan job，防止新引入的依赖带入意外的许可证：

# .github/workflows/license-check.yml
name: License Check
on: [pull_request]
jobs:
  license:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - name: Check licenses
        run: |
          npx license-checker --production \
            --onlyAllow "MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC;0BSD" \
            --excludePrivatePackages

这个配置会在发现任何非白名单许可证时让 CI 失败，迫使 PR 作者走一次 OSRB 流程。

上一篇：专利授权与商标：Apache 2.0、GPLv3 与「兼容性」陷阱

下一篇：GPLv2、GPLv3、LGPL：Linux 内核为什么停在 v2