← 返回文章列表
知识分享

常见开源许可证速览：都在约束什么，该怎么选

你在 GitHub 上点「开源」时，仓库里通常会有一份 LICENSE（或许可证）文件。它不是在「装正式」，而是在用法律语言说明：别人可以怎么用、改、再分发你的代码，以及你要不要承担担保、专利纠纷大致怎么算。选错许可证，轻则协作摩擦，重则和商业产品、公司合规打架。

下面按「宽松 / 著佐权 / 公有领域」三类，介绍最常见的许可证各自特点，并给一些选型思路。重要声明：本文是技术向科普，不是法律意见；涉及并购、合规审计、专利布局时，请咨询专业律师。

为什么要在意许可证？

没有许可证时，默认情况下他人没有被你授予明确的权利，复制与修改都存在版权风险。显式选择许可证，等于告诉全世界：在哪些条件下你可以自由使用这份作品。同时，许可证也会反过来约束你使用别人代码的方式——把 GPL 代码嵌进闭源 App 里，往往就会踩雷。

宽松许可证（Permissive）：「随便用，保留声明即可」

这类许可证的核心是：允许闭源商用、修改、再分发，通常只要求保留版权声明和许可全文，有的还排除担保责任。对希望最大传播面、最少法律摩擦的项目最友好。

MIT

**极简、极常见。**大意是：你可以几乎任意使用、复制、修改、合并、出版、再许可、出售，只要在副本里带上原版权声明和 MIT 许可全文。专利问题在条文里不如 Apache-2.0 那样单独展开，实务上仍被广泛视为对商业友好。

适合：库、工具、示例项目、希望被各大公司无痛集成的代码。

Apache License 2.0

同样对商业友好，但条文更长、更「工程化」：

  • 明确 专利授权：若你贡献代码，一般理解为在许可范围内授予必要专利使用权（具体以全文为准）。
  • 对 贡献与 NOTICE 文件有更清晰约定，大型企业法务更熟悉这一套。
  • 若修改了文件，通常需要标明变更（not a legal summary — 以许可证为准）。

适合：进入企业供应链的框架、基础设施、云厂商常接触的组件；团队希望专利表述更「落地」时。

BSD（2-Clause / 3-Clause 等）

与 MIT 精神接近：保留版权声明、免责声明。3-Clause BSD 多了一条：不得用贡献者名字做推广背书。不同条数版本细节不同，选型时要看具体是哪一版 BSD。

适合：与 MIT 类似，历史上在学术与系统软件圈很常见。

ISC

条文非常短，意图接近 MIT / BSD 2-Clause，极简。npm 生态里不少包用 ISC。

适合：想少写字、语义清晰的小型项目。

宽松许可证之间怎么挑？

  • 只想最简单：MIT 或 ISC。
  • 面向大厂、长期维护、在意专利表述：Apache-2.0 往往是更「标准答案」的那一个。
  • 若你混用依赖，还要关心 SPDX 标识与与 GPL 混用的兼容性（见后文）。

著佐权许可证（Copyleft）：「改了我的，分发时要继续开放」

Copyleft 的核心是：衍生作品在分发时，须沿用同类开放条件，从而保证后续用户仍能拿到源码。强度从「整个程序」到「某个文件」「通过网络提供服务也要开放」不等。

GNU GPL（v2 / v3）

强著佐权。若你的程序链接或组合了 GPL 代码并以二进制等形式分发，整体上常需按 GPL 提供源码并允许继续修改（具体边界是律师业务，「动态链接算不算」等争议历史上很多）。

GPLv2 与 GPLv3 在专利、Tivo化（锁定硬件）、与 Apache-2.0 兼容等细节上不同；不能默认二者随便混。

适合：操作系统组件、希望强制下游保持开源的完整应用或明确愿意接受 GPL 义务的库作者。

GNU LGPL

相对 GPL 更宽松一些，设计初衷常是作为库被专有程序调用时，在特定用法下不必把整个专有程序 GPL化——但 LGPL 不是「随便闭源嵌库」的免死金牌，边界同样要读条文或问律师。

适合：希望库被广泛接入、但仍想对「改库本身」保留一定开放义务的 C/C++ 类库场景（需个案判断）。

Mozilla Public License 2.0（MPL-2.0）

文件级著佐权：通常理解为对 MPL 覆盖的源文件的修改，在分发时要保持开放；不必然要求你整个项目开源，但工程上要把边界划清楚。

适合：想部分保护自家文件、又不愿一上来就 GPL「全家桶」的团队。

GNU AGPL v3

在 GPLv3 思路上，额外关注通过网络提供服务的情形：用户通过网络用你的修改版，也可能触发提供对应源码等义务（通俗说：「SaaS 也要小心」那一类）。

适合：强烈希望闭源托管服务无法白嫖改代码却不回馈的作者；不适合多数默认要闭源商业托管的创业公司随手当依赖。

公有领域与「放弃版权」表述：Unlicense、CC0

有人希望最大限度放弃权利，让别人无需附带冗长声明也能用。CC0 与 Unlicense 在各国法域下是否「完全等同公有领域」存在讨论，但社区里确实常见。注意：CC0 一般不推荐用于软件的单一方案时，要读 Creative Commons 对软件场景的说明；不少项目仍选 MIT 求稳。

适合：小工具、演示代码、明确想「别来问我」的作者——但仍建议了解雇主/学校对著作权归属的要求。

实际选型：「我该用哪一个？」

可以按目标倒推：

  1. 希望被最大范围使用（含闭源产品）：MIT 或 Apache-2.0（企业场景更偏后者）。
  2. 整个应用都希望「一改再分就要开源」：GPLv3（或 AGPL，若你特别在意网络服务形态）。
  3. 库：想强制下游开源：往往选 GPL 会显著减少商业采用；要想被广泛集成，多用 MIT / Apache-2.0；中间路线看 LGPL / MPL。
  4. 文档、图标、字体：不一定套「软件许可证」；Creative Commons 系列更常见，且要区分 NC/ND 是否允许商业使用与改编。

团队内部还要统一：贡献者协议（CLA）要不要、雇主知识产权归属、是否包含非代码资产（商标、数据、模型权重另议）。

混用依赖时的提醒

  • 兼容性：例如 Apache-2.0 与 GPLv3 可兼容合并到 GPLv3 项目，但反向不一定成立；GPLv2 与 Apache-2.0 经典上被认为不兼容（细节冗长，集成前务必查证）。
  • 遵守 NOTICE：Apache系项目常带 NOTICE 文件，你的产品文档或发行物里可能要保留。
  • 「传染性」焦虑：不必听到 GPL 就恐慌，但要分清你只是使用独立进程的工具，还是把代码编进同一个分发物——这是合规团队常看的边界。

如何「正式」挂上许可证？

常见做法：在仓库根目录放 LICENSE 文本（与 SPDX 所选名称一致），README 里写一行 SPDX-License-Identifier（若适用），并在发布包中携带声明。GitHub/GitLab 的许可证选择器可生成标准文本，不要自己瞎改条款里的几个字——那可能造成歧义。

小结

类型代表一句话印象
宽松MIT、Apache-2.0、BSD、ISC易商用、再分发门槛低；Apache 对专利/NOTICE 更细。
著佐权GPL、LGPL、MPL、AGPL保护「后续仍开放」；AGPL 对网络服务更敏感。
放弃权利CC0、Unlicense（软件场景慎选）意图最大化公共化；注意法域与雇佣关系。

没有放之四海皆准的「最好许可证」，只有与你的分发方式、社区目标、商业计划相匹配的选择。不确定时：优先 Apache-2.0 或 MIT 对多数开源软件是稳妥起点；一旦涉及 GPL 家族，把依赖树和分发形态理清再动手。

延伸阅读