许可·条件·限制一览
条件
- 版权与许可声明分发时必须附上许可证副本和版权声明。
限制
- 责任限制明确声明不对损害承担责任。
- 无担保明确声明不提供任何担保。
许可·条件·限制分类来源:choosealicense.com(GitHub,MIT 许可证)数据。
这是什么样的许可证
MIT 许可证是源自麻省理工学院(MIT)的宽松型(permissive)许可证。正文只有三段,易于阅读,允许使用、复制、修改、合并、出版、分发、再授权和销售。条件只有一个:在软件的所有副本或重要部分中包含版权声明和本许可声明。最后一段是免责条款,说明软件按「原样(AS IS)」提供,不作任何担保,也不对损害承担责任。
它被认为是 GitHub 公开仓库中使用最多的许可证,Node.js、Ruby on Rails、jQuery、React 等知名项目都使用 MIT。React 于 2017 年从「BSD + 专利」组合改为 MIT,也是一个著名案例。
分发时须遵守的事项
- 同时附上原有的版权声明(
Copyright (c) 年份 版权所有者)和完整的许可声明。 - 即使只分发二进制,声明义务也不会消失。通常放在应用的「开源许可」界面、说明书或随附分发的文本文件中。
- 没有公开源代码、标明修改或保持相同许可证的义务。修改 MIT 代码后放进闭源商业产品也可以。
如何应用
在仓库根目录创建 LICENSE(或 LICENSE.txt、LICENSE.md)文件并放入原文,然后将 [year] 替换为年份、[fullname] 替换为版权所有者。本站的生成器可以代劳。同时在包管理器元数据(如 package.json 中的 "license": "MIT")和源文件头中写上 SPDX-License-Identifier: MIT,工具就能自动识别许可证。
常见误解
- 「MIT 没有任何条件」 — 有声明义务。完全没有条件的是 0BSD、Unlicense、CC0。
- 「使用 MIT 代码,我的代码也必须是 MIT」 — 不是。只要保留引入部分的声明,整个产品可以按任何许可证(包括闭源)分发。
- 「完全不用担心专利」 — MIT 正文中没有关于专利的明确条款。很多人认为存在默示许可,但如果需要明确的专利许可,请考虑 Apache-2.0。
- 「以 MIT 发布,就可以把名字用于广告」 — 许可证只是对著作权的许可,并不授予商标或名称的使用权。
适用场景
非常适合希望被尽可能多的人无限制使用的库、小工具和示例代码。它便于企业采用,几乎可以放进任何其他许可证(包括 GPL)的项目,是生态兼容性最广的许可证之一。在 Rust 和 JavaScript 生态中,为弥补专利条款,也常以 MIT OR Apache-2.0 双重许可发布(双重许可指南)。
MIT 代码能放进其他项目吗?
以下是将以此许可证发布的代码合并到下列许可证的项目中一起发布时的一般判定。 在兼容性检查器中查看其他组合 →
| 目标项目 | 判定 | 备注 |
|---|---|---|
| 专有(商业)软件 | 可以 | 必须同时附上原有的版权声明和许可证文本。 |
| Apache-2.0 | 可以 | 必须同时附上原有的版权声明和许可证文本。 |
| MPL-2.0 | 可以 | 必须同时附上原有的版权声明和许可证文本。 |
| LGPL-2.1 | 可以 | 必须同时附上原有的版权声明和许可证文本。 |
| LGPL-3.0 | 可以 | 必须同时附上原有的版权声明和许可证文本。 |
| GPL-2.0 | 可以 | 必须同时附上原有的版权声明和许可证文本。 |
| GPL-3.0 | 可以 | 必须同时附上原有的版权声明和许可证文本。 |
| AGPL-3.0 | 可以 | 必须同时附上原有的版权声明和许可证文本。 |
本网站内容仅为一般信息,不构成法律意见。实际发布、合同或纠纷的判断,请咨询律师等专业人士。