应用开发中的许可证类型及其区别

什么是软件许可证？

软件许可证是一套规则，说明他人可以如何使用应用程序或源代码。

通过许可证，应用程序创建者可以决定他人是否可以：

• 免费使用应用程序。
• 修改源代码。
• 转售应用程序。
• 将代码用于商业项目。
• 创建衍生作品。
• 修改后关闭源代码。
• 必须共享修改后的源代码。

因此，即使源代码在 GitHub 上公开可用，也不意味着代码可以不受限制地自由使用。

如果没有许可证，版权规则将自动适用。这意味着代码所有者保留所有权利，其他人基本上无权复制、修改或分发代码。

开源并不意味着无规则免费

许多人认为开源意味着源代码可以无条件地用于任何用途。实际上，每个开源许可证都有不同的规则。

一般来说，开源许可证允许使用、研究、修改和共享软件。然而，有些许可证授予非常广泛的自由，而有些则要求衍生应用程序保持开源。

软件许可证通常分为几个主要类别：

1. 宽松许可证
2. Copyleft 许可证
3. 弱 Copyleft 许可证
4. 专有许可证
5. 公共领域许可证

软件许可证对比表

许可证	类型	允许商业使用	允许修改	可以闭源	必须开源代码	专利保护	适用场景
MIT	宽松	是	是	是	否	未明确说明	库、应用程序、个人项目
Apache 2.0	宽松	是	是	是	否	是	公司项目和技术
BSD 2-Clause	宽松	是	是	是	否	未明确说明	系统、库和应用程序
BSD 3-Clause	宽松	是	是	是	否	未明确说明	需要保护创建者名称的项目
ISC	宽松	是	是	是	否	未明确说明	小型项目和 JavaScript 库
GNU GPL	强 Copyleft	是	是	衍生作品否	是，分发时	取决于版本	完全开源应用程序
GNU LGPL	弱 Copyleft	是	是	是，有条件	仅特定库部分	取决于版本	开源库
GNU AGPL	强网络 Copyleft	是	是	通常否	是，包括网络服务	AGPLv3 是	服务器、SaaS 和 Web 应用程序
MPL 2.0	文件级 Copyleft	是	是	是，针对单独文件	仅修改的 MPL 许可文件	是	混合开源和专有项目
Unlicense	公共领域风格	是	是	是	否	否	希望自由使用的简单代码
专有许可证	闭源	根据所有者许可	通常否	是	否	根据协议	内部应用程序和付费产品

1. MIT 许可证

MIT 许可证是最简单、最灵活的开源许可证之一。

该许可证允许他人：

• 使用软件。
• 复制源代码。
• 修改源代码。
• 出售软件。
• 将代码包含在付费应用程序中。
• 将应用程序转为闭源。

主要要求是版权声明和 MIT 许可证文本必须保留在软件的所有副本或重要部分中。

MIT 许可证的优点

• 许可证文本简短。
• 容易理解。
• 对商业使用友好。
• 可用于闭源应用程序。
• 广泛应用于库和框架。

MIT 许可证的缺点

• 他人可以获取代码、修改后作为闭源应用程序出售。
• 没有像 Apache 2.0 那样明确的专利保护。
• 代码所有者不能要求修改版本保持开源。

适用场景

MIT 适用于希望源代码尽可能广泛使用而不施加过多限制的开发者。

2. Apache 许可证 2.0

Apache 许可证 2.0 与 MIT 具有相似的特征。软件可以用于商业项目，可以修改、分发并包含在商业应用程序中。

主要区别在于 Apache 2.0 包含关于专利授权的条款。该许可证还要求通过 LICENSE 文件以及（如果有）NOTICE 文件提供署名声明。

Apache 2.0 的优点

• 可用于商业项目。
• 可包含在闭源应用程序中。
• 具有更清晰的专利保护和条款。
• 适用于公司项目。
• 要求用户记录所做的重要更改。

Apache 2.0 的缺点

• 许可证文本比 MIT 长。
• 管理署名和 NOTICE 文件可能更复杂。
• 不要求衍生作品开源。

适用场景

Apache 2.0 适用于希望获得灵活许可证且需要更清晰专利保护的专业项目或公司。

3. BSD 许可证

BSD 许可证是一种与 MIT 类似的宽松许可证。它有多个版本，但最常见的是 BSD 2-Clause 和 BSD 3-Clause。

两者都允许在源代码和二进制形式下使用、修改和分发。

BSD 2-Clause

BSD 2-Clause 也称为简化 BSD 许可证。

其主要要求：

• 必须保留版权声明。
• 必须保留许可证文本和免责声明。

BSD 3-Clause

BSD 3-Clause 多了一条规则：未经许可，不得使用创建者或贡献者的名称来推广衍生作品。

BSD 许可证的优点

• 简单灵活。
• 可用于商业。
• 可包含在闭源应用程序中。
• 适用于库和系统软件。

BSD 许可证的缺点

• 不要求共享代码更改。
• 没有像 Apache 2.0 那样明确的专利条款。
• 他人可以使用代码创建专有产品。

4. ISC 许可证

ISC 许可证是一种非常简洁的宽松许可证。功能上几乎与 MIT 和 BSD 2-Clause 相同。

只要保留版权声明和许可文本，用户可以自由使用、复制、修改和分发软件。

ISC 许可证的优点

• 文本非常简短。
• 易于应用。
• 允许商业使用。
• 可用于闭源应用程序。

ISC 许可证的缺点

• 不要求修改版本开源。
• 专利条款不如 Apache 2.0 清晰。
• 当创建者希望保持衍生代码的开放性时不太适用。

ISC 在 JavaScript 生态系统的包和库中相当常见。

5. GNU 通用公共许可证或 GPL

GNU 不是单个许可证名称。GNU 有多种许可证类型，例如：

• GNU GPL
• GNU LGPL
• GNU AGPL

GNU 通用公共许可证（GPL）是一种强 Copyleft 许可证。这意味着当 GPL 软件被修改并作为衍生作品分发时，该应用程序的源代码也必须以兼容的 GPL 许可证提供。

GPL 不禁止商业使用。开发者仍然可以出售 GPL 软件。但是，软件接收者必须获得 GPL 授予的权利，包括在许可证要求的条件下访问源代码。

GNU GPL 的优点

• 保持软件及其衍生产品开放。
• 改进和开发可以反馈给社区。
• 防止他人获取代码并关闭衍生作品的源代码。
• 适用于基于社区的项目。

GNU GPL 的缺点

• 难以用于专有产品。
• 与其他许可代码结合时需要小心。
• 对于希望保持产品源代码封闭的公司不太适用。

内部代码是否需要公开？

不一定。

如果 GPL 应用程序仅在内部使用而不分发给他人，通常不需要自动向公众公开源代码。

GPL 的主要义务通常在软件或衍生作品被分发时产生。

6. GNU 宽通用公共许可证或 LGPL

LGPL 是比 GPL 更灵活的 Copyleft 版本。

该许可证通常用于库。只要符合许可条款，专有应用程序可以使用或链接到 LGPL 库。GNU 指出 LGPL 库可以与专有应用程序链接，而 GPL 对衍生作品有更强的 Copyleft 效果。

GNU LGPL 的优点

• 适用于开源库。
• 可供闭源应用程序使用。
• 对 LGPL 库的更改仍必须遵循 LGPL 规则。
• 在保留 Copyleft 保护的情况下扩大库的使用范围。

GNU LGPL 的缺点

• 集成规则比 MIT 复杂。
• 需要注意链接和分发方式。
• 对库的直接修改可能触发共享库源代码的义务。

适用场景

LGPL 适用于当你创建希望同时被开源和专有应用程序使用的库时。

7. GNU Affero 通用公共许可证或 AGPL

AGPL 是一种专门为通过网络使用的软件设计的 Copyleft 许可证，例如：

• Web 应用程序。
• 软件即服务（SaaS）。
• API。
• 服务器。
• 在线平台。

使用常规 GPL，公司可以修改软件并在服务器上运行而不分发应用程序。在这种情况下，GPL 的源代码分发要求可能不适用。

AGPL 增加了与网络使用软件相关的义务。通过网络与软件修改版本交互的用户必须有机会获取相应的源代码。

GNU AGPL 的优点

• 适用于保持 SaaS 应用程序开源。
• 防止他人修改服务器应用程序并关闭其代码。
• 提供更强的 Copyleft 保护。

GNU AGPL 的缺点

• 难以用于专有应用程序。
• 常常被不希望开放服务器源代码的公司回避。
• 集成需要仔细审查。

8. Mozilla 公共许可证 2.0

Mozilla 公共许可证（MPL 2.0）是一种文件级 Copyleft 许可证。

这意味着已经采用 MPL 且后来修改的文件必须保持 MPL 可用。然而，这些文件仍然可以与单个应用程序中的其他专有文件结合。

因此，MPL 介于像 MIT 这样的宽松许可证和像 GPL 这样的强 Copyleft 许可证之间。MPL 2.0 也是开放源代码促进会（OSI）认可的开源许可证。

MPL 2.0 的优点

• 比 GPL 更灵活。
• 修改后的开源文件保持开放。
• 可以与闭源代码结合。
• 适用于同时包含开源和专有模块的项目。

MPL 2.0 的缺点

• 比 MIT 或 BSD 更复杂。
• 开发者需要知道哪些文件属于 MPL。
• 如果你希望整个衍生应用程序保持开源，则不太适用。

9. Unlicense

Unlicense 用于创建者希望在法律允许的最大范围内将代码发布到公共领域。

通常，用户可以：

• 复制代码。
• 修改代码。
• 出售代码。
• 分发代码。
• 使用代码而无需署名。

Unlicense 对用户施加的条件很少。

Unlicense 的优点

• 非常自由。
• 几乎没有署名义务。
• 适用于小代码片段或示例代码。

Unlicense 的缺点

• 公共领域的概念在每个国家可能处理方式不同。
• 不适用于公司项目。
• 不提供清晰的专利保护。
• 公司贡献者可能更喜欢 MIT 或 Apache 2.0。

10. 专有许可证

专有许可证是用于闭源应用程序的许可证。软件的使用权完全由应用程序所有者决定。

用户通常只获得使用应用程序的许可，而不是拥有或修改源代码。

示例：

• 订阅应用程序。
• 内部公司软件。
• 付费收银应用程序。
• 酒店管理系统。
• 客户特定应用程序。
• 付费桌面软件。

常见规则

• 不得复制应用程序。
• 不得共享账户。
• 不得查看或修改源代码。
• 不得转售应用程序。
• 使用受设备、用户、公司或时间限制。
• 订阅停止时使用权终止。

适用场景

专有许可证适用于当应用程序是商业产品且源代码必须保密的场景。

11. 双重许可

双重许可是指为同一软件提供两种许可证选项的方法。

示例：

• 免费使用 GPL 供开源项目使用。
• 付费商业许可证供希望使用软件而不遵循 GPL 的公司使用。

这种模式允许软件创建者从开源社区受益，同时出售商业许可证。

但是，当源代码版权完全由单个公司或实体拥有时，双重许可更容易实施。如果有许多贡献者，贡献权利的管理必须明确建立。

知识共享许可能否用于源代码？

知识共享（CC）更适用于：

• 文章。
• 图片。
• 视频。
• 音乐。
• 文档。
• 学习资料。
• 设计和创意内容。

CC 建议不要对软件和硬件使用 CC 许可证，因为有专门的软件许可证更能恰当地处理源代码、分发和修改等问题。

在单个应用程序项目中，你可以使用：

• MIT、Apache 或 GPL 用于源代码。
• CC 用于文档、图片或其他材料。

确保每个部分单独说明，以免混淆用户。

宽松许可证与 Copyleft 的区别

方面	宽松许可证	Copyleft 许可证
示例	MIT、Apache 2.0、BSD、ISC	GPL、AGPL
商业使用	允许	允许
代码修改	允许	允许
可以闭源	通常允许	通常不允许衍生作品
必须共享更改	否	是，在某些条件下
限制程度	较简单	较严格
适用于公司	非常适合	取决于商业模式
适用于开源社区	适合	非常适合
代码开放性保护	低	高

你应该选择哪种许可证？

使用 MIT 的情况

• 你想要一个简单的许可证。
• 你希望代码被尽可能广泛地使用。
• 你不介意代码被用于闭源应用程序。
• 你在创建库或个人项目。

使用 Apache 2.0 的情况

• 你想要 MIT 的自由。
• 你需要更清晰的专利条款。
• 你在创建公司项目。
• 你计划接受大量贡献。

使用 BSD 的情况

• 你想要一个简单的宽松许可证。
• 你在创建系统软件或库。
• 你不希望创建者的名字被用于推广衍生作品。

使用 GPL 的情况

• 你希望衍生应用程序保持开源。
• 你不希望公司获取代码并关闭其源代码。
• 你在创建社区项目。

使用 LGPL 的情况

• 你在创建库。
• 你希望库可以被专有应用程序使用。
• 你希望库的修改保持开放。

使用 AGPL 的情况

• 你在创建 SaaS 或服务器应用程序。
• 你希望通过网络使用的更改被共享。
• 你不希望公司在服务器上私下运行修改版本。

使用 MPL 2.0 的情况

• 你希望部分代码保持开放。
• 你仍然希望将代码与专有模块结合。
• 你需要 MIT 和 GPL 之间的中间地带。

使用专有许可证的情况

• 源代码不能开放。
• 应用程序为商业目的而制作。
• 你想要限制软件的使用。
• 应用程序通过许可证或订阅系统出售。

GitHub 上的许可证应用示例

通常，许可证文本存储在以下文件中：

LICENSE

或者：

LICENSE.md

该文件放在仓库的主目录或根目录中。GitHub 还建议将许可证文件直接包含在仓库中，以便在克隆、下载或分发项目时可用。

项目结构示例：

app-name/
├── app/
├── public/
├── src/
├── README.md
├── LICENSE
└── package.json

还可以在 README.md 中添加简短信息：

## 许可证

本项目使用 MIT 许可证。
有关详细信息，请参阅 LICENSE 文件。

选择许可证前需要检查的事项

在决定许可证之前，请考虑以下几点：

1. 应用程序是否可以用于商业？
2. 他人是否可以修改源代码？
3. 修改后是否需要共享？
4. 衍生作品是否可以闭源？
5. 应用程序是否用作 SaaS？
6. 项目是否使用了第三方库？
7. 每个依赖项的许可证是否兼容？
8. 是否有其他贡献者的代码？
9. 是否需要专利保护？
10. 应用程序是否将出售给客户？

不要仅仅因为某个许可证流行就选择它。根据项目目标以及应用程序的使用方式选择许可证。

结论

每种软件许可证都提供不同的权利和义务。

MIT、BSD 和 ISC 适用于希望给用户广泛自由的项目。Apache 2.0 提供类似的自由，但具有更清晰的专利条款。

GPL 适用于保持衍生应用程序开源。LGPL 更适用于库，而 AGPL 为 Web 应用程序、服务器和 SaaS 提供了额外保护。

MPL 2.0 可以作为一个中间选择，因为它只要求某些文件保持开放。同时，专有许可证更适用于源代码必须保密的商业应用程序。

许可证选择应在开发初期进行。除了保护应用程序创建者外，清晰的许可证还有助于用户和贡献者了解哪些是允许的，哪些是不允许的。

注意： 本文提供了一般性解释，并非法律建议。对于大规模商业应用、大量使用依赖项或有许多贡献者的项目，请咨询了解知识产权法的人士以获取许可证选择建议。