中国移动-智慧家庭运营中心 郑国忠、王雪珊

开源软件的世界里，许可证（License）就像是一张通行证，决定了代码的使用、分发和衍生方式。对于开发者、创业公司、甚至大厂来说，选错许可证就像踩进法律的雷区，轻则重构代码，重则陷入诉讼。

今天，我们聚焦宽松型开源许可证（Permissive Licenses），深入解析MIT、Apache 2.0、BSD 3-Clause、ISC、Unlicense这几大代表性协议的核心条款、版本差异、实践注意事项，以及那些让人后悔莫及的“血泪教训”。

一、什么是“宽松型”许可证？

宽松型（Permissive）：宽松授权，允许自由使用、修改、分发，允许衍生作品闭源或商业化，通常只需保留原始许可证和版权声明。例如：MIT、Apache 2.0、BSD、ISC等。这类许可证以灵活性和低合规风险著称，广泛应用于需要快速传播或商业集成的开源项目。

如果你希望最大化降低法律风险，允许代码自由流通，同时避免“传染性”限制，那么宽松型许可证是最佳选择。

二、当心！宽松≠无脑用——5大许可证暗藏致命差异

MIT、Apache 2.0这些传说中的”宽松型许可证”，就像程序界的万能通行证：

✅允许商用

✅随意魔改

✅闭源发布

但宽松就能”为所欲为”吗？

2023年，国内CEC-IDE事件引爆开发者圈[1]！这款宣称”国内首款多环境支持且有自建插件市场”的IDE工具，因未保留VSCode的MIT声明，遭940+社区声讨后公开道歉并进行整改。这再次警示我们：最宽松的协议也有致命红线！

可见每张”免死金牌”背面都刻着隐秘的江湖规矩…那么五大协议暗藏哪些”生死符”？

1. MIT License：极简主义的陷阱

MIT许可协议：即The MIT License，该许可协议之名源自麻省理工学院（Massachusetts Institute of Technology,MIT），又称“X许可协议”（XLicense）或“X11许可协议”（X11License），是相对宽松的软件许可协议。

▌关键词

超级宽松、最流行、商业友好

▌适用场景

个人项目、初创公司、教学demo、非核心模块

▌协议本质

• 允许自由使用、修改、分发，可闭源商用，商业友好度MAX
• 只需保留原始版权声明和许可文本
• 兼容所有主流开源协议
• 无专利保护！若代码贡献者起诉你专利侵权，MIT不会保护你
• 无担保声明（”as is”），开发者不承担任何责任
• 连注释里的年份都不能改！

▌使用MIT开源软件的合规建议：

1）附加符合许可证要求的版权声明：

MIT许可示范条款：

• // Copyright(c)
• // 此代码依据MIT许可证授权，详情见LICENSE文件

2）出现违反许可证要求的情况，主要包括以下几种情形：

• 无版权声明
• 将版权所有人替换为使用者本人
• 照搬版权声明示范条款

▌避坑指南

1）MIT许可的代码可以被闭源商用，如果你不希望自己的代码被某些大厂“拿去封闭”，可能要考虑更严格的协议（如GPL）

2）注释/文档/源码中的声明都是雷区

▌死亡禁区及血泪案例

1）删除/篡改版权声明

案例：

何同学视频商用事件[2]，B站千万粉丝博主何同学在商单视频中使用基于MIT协议的开源项目“ASCIIgenerator”,删除源代码中的原作者署名，并声称软件为团队独立开发，误导观众,引发开源社区对创作者合规意识的广泛讨论！

Remark：

MIT协议唯一强制要求是保留版权声明，何同学团队未遵守

2）未附带许可证文本

案例：

CEC-IDE”自主研发”暴雷事件[1]，数字广东公司推出的“CEC-IDE”软件基于MIT协议开源的VSCode代码修改，但未在版本中附带原始MIT许可证声明，被开发者社区曝光，遭940+社区声讨后公开道歉。

Remark：

3）未附带许可证文本

案例：

FBI智能合约事件[3]。其代码使用MIT协议的OpenZeppelin库，但未包含原始许可证归属信息，代码被标记为“未经许可”，引发对政府机构使用开源代码合规性的关注。

4）忽视专利风险

案例：

2017年Facebook在React的MIT协议中，新增专利反制条款（可单方面终止授权）、且未在npm包中显著提示条款变更，与Apache等基金会协议产生冲突，造成开源生态爆发“十级地震”，React最终被迫回归纯MIT协议[4]。

Remark：

MIT License

附加条款：若起诉Facebook专利侵权，自动终止React使用权

2. Apache License 2.0：大厂最爱的心机条款

Apache License 2.0（ALv2）是Apache软件基金会推出的开源协议，以专利博弈和企业级友好著称。看似比MIT宽松，实则暗藏“法律武器库”。

▌关键词

宽松但带专利授权、企业友好

▌版本差异

涉及专利的企业级项目、大型开源社区、需要防御专利诉讼的商业代码

▌企业级合规建议

1）NOTICE文件的重要性

• 记录每个贡献者的版权声明（作者、年份、版权归属等）
• 涉及的专利号及授权范围（如果有）
• 第三方代码依赖清单（明确列出所使用的其他开源组件及其许可证信息）

2）专利防御三原则

• 贡献代码=自动授权专利（小心被大厂白嫖！）：根据Apache License v2的专利条款，贡献代码意味着自动授予项目和其他使用者专利许可。企业需谨慎评估潜在的专利风险
• 起诉他人专利侵权=自毁ALv2护盾：如果使用者起诉Apache项目或其他使用者的专利侵权，可能会失去对Apache项目的专利许可
• 禁用“附加限制条款”（与GPLv3不兼容）：Apache License v2明确禁止附加任何限制条款，这与GPLv3的“附加限制条款”功能不兼容

3）衍生作品标注版权归属示例

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

Modifications Copyright (c) 2023 [Your Company]

第一行明确指出软件包含Apache软件基金会开发的代码，并提供Apache官方网站的链接。

第二行声明对原始代码的修改部分的版权归属，确保企业对自身修改的权益得到保护。

▌避坑指南

如果你担心专利诉讼风险，Apache 2.0比MIT更安全，适合企业级应用。但Apache 2.0代码不能直接变成MIT代码（因为MIT没有专利条款），所以如果你希望向MIT生态靠拢，需要额外处理。

慎碰GPL：ALv2与GPLv3不兼容！混用将触发“协议核战”

代码审计红线：结合自动化工具与人工审查，定期检查NOTICE文件和许可证声明，尤其警惕GPL组件混入

▌死亡禁区及血泪案例

1）未明确标注开源组件来源、忽视衍生作品要求

案例：博云（BoCloud）违反ALv2事件[5]。

2020年，博云在推广其微服务产品“BeyondMicroservice”时，宣传视频中展示的APM监控界面与Apache顶级项目SkyWalking的UI布局、指标显示完全一致，但未在宣传材料或产品文档中声明使用了SkyWalking组件。Apache社区发起问责，博云公开道歉。

Remark：

ALv2要求衍生作品必须明确标注原项目信息，即使代码经过修改或仅使用界面设计，仍需在“显著位置”声明来源（如产品文档、宣传材料或NOTICE文件）

2）删除或篡改声明文件、混淆代码原创性

案例：

2022年火山引擎违规使用Apache SkyWalking事件[6]。字节跳动旗下火山引擎的“应用性能监控全链路版”产品基于Apache SkyWalking（Apache 2.0协议）二次开发，但在重新分发时，火山引擎的团队更改了所有软包名称，删除了Apache软件基金会的抬头，并且在重新发行时未保留Apache软件基金会、ApacheSkyWalking的LICENSE和NOTICE文件。

Remark：

基于Apache License Version 2.0的作品或衍生作品进行修改或增补，并应用到商业项目时,前提是满足以下几个条件：

需要给代码的用户一份Apache License；

如果你修改了代码，需要在被修改的文件中说明；

在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明；

如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache License。你可以在Notice中增加自己的许可，但不可以表现为对Apache License构成更改。

3. BSD 3-Clause：广告条款的深坑

BSD 3-Clause许可证：全称”BSD 3-Clause License”，起源于加州大学伯克利分校（University of California, Berkeley）的”BerkeleySoftwareDistribution”项目，是宽松开源协议的代表之一。

▌关键词

MIT变体、对商用友好、禁止背书营销、无专利保护

▌适用场景

学术界、企业合作项目

▌协议本质

• 允许自由使用、修改、分发，可闭源商用，兼容主流协议。（商业友好度与MIT相当，但需遵守额外限制）
• 必须保留原始版权声明、许可文本和免责声明。（包括源代码、二进制分发和文档中的完整声明）
• 禁止未经授权的名义背书（不得使用原作者或贡献者名称推广衍生作品（如营销标语、产品名称））
• 无专利保护！若代码贡献者起诉你专利侵权，BSD不会保护你
• 免责声明与责任限制。版权持有者和贡献者不对因使用软件引起的任何损害承担责任，要求用户自行承担因使用软件所产生的所有风险
• 连代码中的作者名都不能用！

▌版本差异

• BSD 2-Clause：仅要求保留版权声明，删除了广告条款，更适合商业化产品
• BSD 3-Clause：额外禁止用作者名义推广衍生品

▌使用BSD 3-Clause开源软件的合规建议

1）版权声明格式示例：

// Copyright (c). All rights reserved.

// 此代码使用 BSD 3-Clause 许可证授权，详情见LICENSE文件

2）BSD-3-Clause在发生派生项目时，需要注意的情况：

• 如果是开源项目派生，源代码中必须包含原项目中的BSD协议
• 如果是闭源项目派生，比如二进制类库或者商业软件，在软件的文档和版权声明中要包含原项目中的BSD协议
• 不论开源或闭源项目派生，不可以用BSD项目作者、机构或项目产品的名称做市场推广

▌避坑指南

第三条款是雷区！若闭源产品宣传中提及“基于某BSD项目开发”，需确保原作者未禁止此类使用

▌死亡条款

衍生作品的所有宣传材料必须声明”本产品包含XXX开发的软件”

4.ISC License：MIT的克隆体？NO！

ISC许可证：全称”ISC License”，源自Internet Systems Consortium，是MIT许可证的“极简进化版”。仅用5行文本覆盖核心条款。允许用户几乎无限制地使用、修改和分发代码，仅需保留原始版权声明和许可文本。

▌关键词

极简主义、兼容性之王、无存在感但实用

▌适用场景

超简洁、无额外限制的开源项目

▌协议本质

• 允许自由使用、修改、分发，可闭源商用，商业友好度MAX
• 必须保留原始版权声明和许可文本
• 无专利保护
• 无担保声明（”as is”），开发者不承担任何责任

▌使用ISC开源软件的合规建议

1）声明保留的极简操作：

• 源代码分发：在每个文件头部或独立LICENSE文件中标注：

// Copyright (c)

// 此代码依据ISC许可证授权，详情见LICENSE文件

• 二进制分发：在软件文档或安装包中注明“包含ISC协议代码，详见legal/licenses”

2）出现违反许可证要求的情况，主要包括以下几种情形：

• 未保留版权声明
• 修改或替换版权声明中的内容（如作者、年份等）
• 忽视嵌套依赖中的许可声明

3）隐藏优势：

• Node.js生态默认选择：npm初始化默认生成ISC许可证（而非MIT），因其更适应模块化分发场景。
• 律师友好型文本：ISC的免责声明明确涵盖“直接、间接、特殊、偶然或结果性损害”，法律边界更清晰。

▌避坑指南

由于去掉了部分条款，ISC可能在某些法律环境下比MIT更脆弱，但在大多数场景下影响不大。

如果你追求极简代码许可文本，ISC是最佳选择，但不要误删许可证文本！

5. Unlicense：极端自由的风险

Unlicense：诞生于2010年，由开源开发者Arto Bendiken起草，旨在通过“放弃所有版权”将软件释放到公共领域（Public Domain），是开源协议中最极端的自由派代表。

Unlicense就像把一本书放入公共图书馆并说：”这本书没有版权限制，任何人都可以复制、修改或出版它，无需任何义务。”

▌关键词

零限制、公共领域、法务雷区

▌适用场景

个人实验性项目、彻底放弃控制权的代码、学术原型、反版权倡导

▌协议本质

• 彻底放弃所有版权和专利，代码进入公共领域（Public Domain）
• 无专利保护
• 无担保声明（”as is”），开发者不承担任何责任
• 无传染性。衍生作品可自由选择许可证（包括闭源专有协议）

▌避坑指南

公共领域≠无风险：

某些国家（如德国、日本）法律不承认完全的版权放弃，代码可能仍受默认版权保护

如果你希望最大化自由，但又要确保法律有效性，可以考虑CC0（Creative Commons Zero）代替Unlicense。

三、核心条款对比：开源许可证的底层逻辑

一句话总结：

• MIT：“极简主义，闭源商用无压力。”
• Apache 2.0：“专利护盾，企业级项目的安全选择。”
• BSD 3-Clause：“学术友好，但别用我的名字打广告。”
• ISC：“MIT的极简进化版，Node.js生态默认选项。”

四、救命checklist！选许可证前灵魂四问

是否涉及专利技术？→选Apache 2.0。

是否要兼容GPL？→优先选MIT/BSD

是否会被集成到闭源产品？→选择MIT、Apache、BSD

最后无论选择哪种许可证，清晰标注版权信息并遵守许可条款，是避免法律纠纷的关键哦！

参考文献

1. https://view.inews.qq.com/k/20230830A00U0I00?no-redirect=1&web_channel=wap&openApp=false
2. https://www.guancha.cn/politics/2024_11_20_756148.shtml
3. https://www.panewslab.com/zh/sqarticledetails/0cw0r3nz.html
4. https://blog.csdn.net/qq_24520459/article/details/103014713
5. https://segmentfault.com/a/1190000022979222
6. https://www.infoq.cn/article/aZjFqGUeCoC42G6P204s

声明：本文来自信息通信软件供应链安全社区，稿件和图片版权均归原作者所有。所涉观点不代表东方安全立场，转载目的在于传递更多信息。如有侵权，请联系rhliu@skdlabs.com，我们将及时按原作者或权利人的意愿予以更正。