一篇带你了解所有 GitHub License

2 min read

在 GitHub 上开源项目时，选择合适的 License（许可证）往往是一个重要但容易被忽视的步骤。不同的开源许可证对用户修改、传播、合并与商业化用途都有各自的要求和限制。本文将带你了解最常见的几种 GitHub 许可证，帮助你在开源项目中做出合适的选择。

1. MIT License

关键词：宽松、简洁、允许商业化

  • 特点：
    • 使用者可以自由地复制、修改、合并、出版、分发、再授权以及出售软件及其副本
    • 唯一要求是保留原始的版权声明和许可证声明
  • 适用场景：
    • 希望自己的项目被广泛使用和传播
    • 不介意他人将项目闭源或商用时保留修改细节

MIT License 是在开源社区里最受欢迎且最简单的许可证之一，对商业使用基本没有限制，只需保留原始作者信息即可。

2. Apache License 2.0

关键词：专利授权、商用友好、贡献者声明

  • 特点：
    • 包含了对专利权的明文授权与保护
    • 如果出现专利诉讼，授权自动终止
    • 要求保留许可证和版权声明，修改后需在 NOTICE 文件中说明变更内容
  • 适用场景：
    • 项目涉及一定专利风险，想获得明确的专利授权保护
    • 希望使用者在分发软件时公开对源文件的修改

Apache 2.0 对专利权有更清晰的阐述，比 MIT 略为繁琐一些，但依旧保持了宽松和商用友好的特点。

3. GNU GPL 系列

3.1 GPL（GNU General Public License）

关键词：强制开源、Copyleft、商业不禁止

  • 特点：
    • 要求任何基于 GPL 代码的衍生作品必须也以 GPL 方式开源
    • 可以商业化使用，但必须在发行或发布时公开源代码
  • 适用场景：
    • 对开源社区共享精神要求高，希望任何衍生项目也必须保持开放
    • 不介意严格的“强制开源”限制

GPL 被称为具有“传染性”或“强制性”的许可证（Copyleft），对代码衍生物做出了严格的开源要求。

3.2 LGPL（GNU Lesser General Public License）

关键词：库/组件、弱Copyleft

  • 特点：
    • 主要用于库、插件或依赖组件
    • 允许软件在与非（L）GPL 代码组合时保持闭源，但对改动库本身的部分仍要求开源
  • 适用场景：
    • 项目主要以“库/框架”等形式被集成使用
    • 希望方便商业软件进行链接，同时保持对库本身的保护

LGPL 提供比 GPL 更灵活的方式，特别适合函数库或组件，在一定程度上减轻了对整个软件“传染”的影响。

3.3 AGPL（GNU Affero General Public License）

关键词：网络服务、SaaS、强制开源

  • 特点：
    • 是 GPL 的延伸，针对网络服务场景
    • 如果你对外提供基于 AGPL 软件的网络服务（比如 SaaS），也需要对外开放服务端源码
  • 适用场景：
    • 对“网络部署”场景有严格的开源要求
    • 希望阻止他人基于开源项目做成封闭式的云服务

AGPL 常见于基于服务器端的软件、Web 应用或云端组件，进一步加固了“Copyleft”概念。

4. BSD License（2-Clause、3-Clause）

关键词：简洁、宽松、版权说明

  • 特点：
    • 2-Clause BSD 称为简化版 BSD（仅要求保留版权和免责声明）
    • 3-Clause BSD 额外加入了“不得使用贡献者或组织名义背书衍生项目”的限制
  • 适用场景：
    • 和 MIT 类似，既希望开源，又不想对他人使用方式做过多限制
    • 只需对使用者提出最少的义务（如保留版权声明等）

BSD 与 MIT 一样是非常宽松的许可证，与 MIT License 非常相似，细微差别在于 BSD 对名义背书有更多约束。

5. MPL 2.0（Mozilla Public License 2.0）

关键词：文件层级、混合开源许可

  • 特点：
    • copyleft 范围只限于被修改过的文件自身
    • 允许与其他许可证的代码混合分发，但需要将 MPL 代码部分保持在 MPL 协议之下
  • 适用场景：
    • 想在单个文件级别施加“开源”义务，而不是整个项目
    • 希望代码可以和其他开源或闭源许可证进行混合

Mozilla 公共许可证相对灵活，特别适合那些希望部分文件强制开源，部分不受限制的项目。

6. EPL（Eclipse Public License）

关键词：企业领域、商业机构、专利条款

  • 特点：
    • 同样包含专利授权条款，对专利纠纷较为友好
    • Copyleft 范围主要作用在修改过的源码或混合后形成的整体
  • 适用场景：
    • 常用于 Eclipse 基金会及企业级项目
    • 重视专利纠纷保护，适合大型商业组织

EPL 在企业界相对常见，与 IBM、Eclipse 生态关系紧密，是很多企业选择的开源许可证之一。

7. Unlicense

关键词：公有领域、无版权

  • 特点：
    • 意在将软件贡献至公共领域，几乎没有任何使用限制
    • 使用者可随意复制、修改、发布、出售
  • 适用场景：
    • 彻底放弃版权，最大化分发与自由度
    • 并不关心日后对修改或分发做任何要求

Unlicense 处于极致开放的另一端，几乎没有任何限制，作者自愿放弃版权。

8. CC0、All rights reserved 及其他

  • CC0：常用于内容（图片、文字作品），也可视为放弃版权的行为。但对于代码场景，通常会选择 MIT/Unlicense 等更合适。
  • All rights reserved：即保留所有权利，不属于开源许可证，不建议在开源项目中使用。

小结

  1. 宽松许可证（MIT、BSD、Unlicense）：允许代码被自由地商用、闭源，只需保留版权声明。
  2. 专利友好（Apache 2.0、EPL）：提供额外的专利保护或约束，适合企业和有专利需求的项目。
  3. 强制开源（GPL、LGPL、AGPL、MPL）：具有“Copyleft”的约束，要求衍生代码也须保持相同或兼容的开源方式，具体范围因许可证而异。

在 GitHub 项目中，选择合适的许可证能够让你的项目最大化地发挥价值，既能保护开发者权益，也能方便他人使用与合作。希望这篇文章能帮助你快速了解常见的开源许可证，并在下一次新建仓库时顺利做出正确的选择！

参考链接