各开源协议一览

发布于:2025-04-14 ⋅ 阅读:(33) ⋅ 点赞:(0)

在 GitHub 上,开源项目通常会使用一些常见的开源协议来定义项目的使用、修改和分发规则。以下是目前 GitHub 上最常见的几种开源协议及其差异和示例说明:


TL;DR

协议 宽松程度 是否强制开源 专利保护 适用场景
MIT 最宽松 希望代码被广泛使用
Apache 2.0 宽松 希望提供专利保护
GPL 严格 希望确保代码始终开源
LGPL 较宽松 部分是 希望代码被更广泛集成
BSD 宽松 希望代码被广泛使用且简单
MPL 2.0 中等 部分是 希望代码部分开源但允许混合

协议详解

1. MIT License

  • 特点
    • 非常宽松,几乎没有任何限制。
    • 允许用户自由使用、复制、修改、合并、发布、分发、再授权甚至用于商业用途。
    • 唯一要求是保留原始版权声明和许可声明。
  • 适用场景
    • 适合希望代码被广泛使用的开发者。
    • 示例:Vue.js 使用了 MIT License 。
  • 差异
    • 相较于其他协议(如 GPL),MIT 不强制要求衍生作品也必须开源。

2. Apache License 2.0

  • 特点
    • 提供了明确的专利授权条款,保护用户免受潜在的专利诉讼。
    • 允许用户自由使用、修改和分发代码,但需要保留版权声明和许可证文件。
    • 明确限制商标使用,不允许用原作者的商标进行宣传。
  • 适用场景
    • 适合希望保护知识产权并提供专利保障的项目。
    • 示例:Apache Kafka 使用了 Apache License 2.0 。
  • 差异
    • 比 MIT 更加详细,特别是关于专利和商标的规定。

3. GNU General Public License (GPL)

  • 特点
    • 强制性开源,任何基于 GPL 代码的衍生作品也必须以 GPL 协议发布。
    • 用户可以自由使用、修改和分发代码,但必须公开源码。
  • 适用场景
    • 适合希望确保代码始终开源的项目。
    • 示例:Linux Kernel 使用了 GPL 。
  • 差异
    • 相较于 MIT 和 Apache,GPL 对衍生作品有更强的约束力。

4. Lesser GNU General Public License (LGPL)

  • 特点
    • 是 GPL 的一个变种,允许将 LGPL 代码作为库链接到闭源项目中。
    • 衍生作品如果是独立模块,可以不公开源码;但如果修改了 LGPL 库本身,则必须公开修改后的代码。
  • 适用场景
    • 适合希望代码被更广泛地集成到商业项目中的库类项目。
    • 示例:GNU C Library (glibc) 使用了 LGPL 。
  • 差异
    • 比 GPL 更宽松,但仍要求对库本身的修改保持开源。

5. BSD License

  • 特点
    • 类似于 MIT,非常宽松。
    • 分为两种主要版本:2-Clause(简化版)和 3-Clause(禁止用项目名称做广告)。
    • 要求保留版权声明和许可证文件。
  • 适用场景
    • 适合希望代码被广泛使用且不介意闭源衍生作品的项目。
    • 示例:FreeBSD 使用了 BSD License 。
  • 差异
    • 相较于 MIT,3-Clause 版本增加了对广告的限制。

6. Mozilla Public License 2.0 (MPL 2.0)

  • 特点
    • 是 BSD 系协议和 GPL 系协议的折中。
    • 要求对 MPL 覆盖的代码部分保持开源,但允许与闭源代码混合。
    • 必须保留版权信息,并公开对覆盖代码的修改。
  • 适用场景
    • 适合希望代码部分开源但允许与其他闭源代码协作的项目。
    • 示例:Firefox 使用了 MPL 2.0 。
  • 差异
    • 比 GPL 更宽松,但比 MIT 和 BSD 更严格。

7. Creative Commons (CC)

  • 特点
    • 主要用于非代码内容(如文档、图片、音乐等)。
    • 提供多种版本,包括 CC0(完全放弃版权)、CC BY(署名即可使用)等。
  • 适用场景
    • 适合非软件项目或需要灵活授权的内容。
    • 示例:Wikipedia 的部分内容使用了 CC BY-SA 。
  • 差异
    • 不适用于传统意义上的代码项目。

网站公告

今日签到

点亮在社区的每一天
去签到