你在 GitHub 上找到一个很好用的库，git clone 下来，塞进公司的商业产品里。三个月后上线，法务跑来问了一句："这个库的 LICENSE 你看过吗？"

很多人这时才发现：仓库根目录那个不起眼的 LICENSE 文件，可能决定你能不能商用、要不要开源自己的代码、甚至要不要吃官司。这篇文章讲的就是这类"软件协议"——开源许可证（Software License），以及最流行的那个：MIT。

一、先搞清楚：没有许可证，你什么都不能做

这是最容易被忽略的前提。代码一经写下，版权就自动产生，不需要注册、不需要声明。默认状态下，权利人是"保留所有权利（All Rights Reserved）"。

也就是说，一份没有 LICENSE 文件的公开代码：

  • 你可以看（浏览、学习）；
  • 但复制、修改、分发、商用在法律上都缺乏授权；
  • 它不是"公共领域"，作者随时可以主张权利。

"公开可见"≠"可以随便用"。许可证就是权利人主动让渡一部分权利的那份文件——它决定了你被允许做什么，以及在什么条件下。

二、一份许可证，其实只有三块内容

剥开法律术语，每份开源许可证都在回答三个问题：

部分回答的问题典型表述
授权（Grant）允许你干什么"免费授予使用、复制、修改、分发、再许可、销售的权利"
条件（Conditions）你要付出什么"必须保留版权声明""衍生作品须以同一许可证发布"
免责（Disclaimer）出事了谁负责"软件按原样提供，不提供任何担保，作者不承担任何责任"

授权越宽、条件越少，许可证就越"宽松"（permissive）；反过来，如果条件里要求"你的衍生作品也必须开源"，就叫著佐权（copyleft，中文常译"传染性"）。

所有许可证的差异，基本都能落在这张坐标上。

三、MIT：短到能背下来，宽到几乎不管

MIT 许可证全文只有一段，是所有主流许可证里最短的：

Copyright (c) <year> <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

拆开看，它做了三件事：

  1. 授权几乎不设限：使用、复制、修改、合并、发布、分发、再许可、销售，全都允许，包括闭源商用。
  2. 只提一个条件：所有副本或"实质性部分"里，必须保留这段版权声明和许可声明。
  3. 完全免责：软件出任何问题，作者不负责。

关于 MIT 的几个关键认知

  • 它不要求你开源自己的代码。 你用 MIT 的库做产品，产品可以闭源、可以收费、可以只发二进制——只要保留那份声明。
  • MIT 不是"放弃版权"。 作者仍然拥有版权，只是给了你极宽的许可。真正放弃权利的是 Public Domain / CC0 / Unlicense 这类。
  • "保留声明"是硬条件。 把 LICENSE 删掉、把文件头版权注释抹掉再分发，属于违约。
  • MIT 没有明确的专利授权条款。 这是它相对 Apache 2.0 的主要短板：贡献者是否默示授予了专利许可，条文里没有写，只能靠"隐含许可"理论，争议较大。
  • MIT 与"X11 许可证"基本等价，历史上常被混称。

用 MIT 的知名项目很多：React、Vue、jQuery、Ruby on Rails、以及大量 npm 包。它之所以流行，不是因为法律上最完善，而是因为短、好懂、几乎不制造摩擦——这本身就是一种生态策略。

四、BSD 家族：MIT 的近亲，多一条"别拿我背书"

BSD 许可证和 MIT 几乎同义，区别在条款数量：

变体内容备注
BSD-2-Clause保留版权声明 + 免责与 MIT 实质等价
BSD-3-Clause再加一条：不得用原作者或组织名义为你的产品背书最常见，nginx、Go、Django、Flask 都用它
BSD-4-Clause再加"广告条款"（所有广告须提及加州大学伯克利分校）已被 FSF 认定为与 GPL 不兼容，基本淘汰

对企业来说，BSD-3 和 MIT 的差别只在商标/背书这一层：你可以在宣传里说"基于 X 构建"，但不能暗示"X 官方推荐你"。

五、Apache 2.0：为商业场景补齐专利短板

Apache 2.0 比 MIT 长得多，因为它是被大公司反复打磨过的版本。核心增量有三条：

  1. 明确的专利授权：每个贡献者自动授予你实施其专利的许可。同时带终止条款——如果你就这个软件发起专利诉讼，你的许可立即失效。这条对甲方最友好。
  2. 商标条款：许可证不授予商标使用权，你不能用 "Apache" 品牌做宣传。
  3. 变更声明与 NOTICE 文件：修改过的文件要注明"已修改"，分发时要附带原项目 NOTICE 文件里的归属声明。

一句话总结：MIT 是"你随便用"，Apache 2.0 是"你随便用，但我把专利和商标的丑话说在前头"。

Kubernetes、Kafka、TensorFlow、Android 主体、.NET 都采用 Apache 2.0。企业法务通常最偏好它，理由就是那条专利授权。

六、GPL：自由的定义，以及"传染"的边界

GPL 是另一条路线。它的目标不是"让你随便用"，而是保证软件对所有人永远自由——包括你修改之后的版本。

GPLv2 / GPLv3 的核心要求

  • 你可以商用、可以收费、可以修改；

  • 但只要你分发了衍生作品，就必须：

    • 以 GPL 提供完整源代码；
    • 衍生作品也采用 GPL；
    • 不得附加额外限制（不能加"禁止商用"之类）。
  • GPLv3 额外补了：反 Tivoization（禁止用硬件锁限制用户替换软件）、专利授权、以及与 Apache 2.0 的兼容。

这就是"传染性"（更准确的说法是 copyleft）：它不阻止你用，但它要求下游同样开放。

边界在哪里？这是最容易踩坑的地方

  • "衍生作品"怎么算，法律上没有唯一答案。 FSF 的立场很激进：动态链接也算。多数企业法务更谨慎，会按"是否构成单一作品"来判断。
  • LGPL 就是为库场景设计的妥协版：动态链接 LGPL 库时，你的程序可以保持闭源；但一旦静态链接或修改库本身，约束就回来了。
  • AGPL 更狠：它把"通过网络提供服务"也视为分发。你改一个 AGPL 的组件拿去做 SaaS，用户远程交互时，你必须能提供源代码。
  • MPL 2.0 是"文件级 copyleft"：只有被你修改的那几个文件需要开源，新写的文件不受约束，且它明确兼容 GPL/LGPL/Apache。Firefox 用它。

一个常见误解

"用了 GPL 的软件，我的整个系统都得开源"——不准确。触发义务的是"分发"和"衍生作品"。你在公司内部自用、不分发、不对外提供服务，通常不触发源码公开义务（AGPL 除外，它把网络交互也算上）。

七、一张表看懂主流许可证

许可证类型可闭源商用是否要求衍生作品开源明确专利授权典型项目
MIT宽松✅❌⚠️ 无明文React、Vue、Rails
BSD-3-Clause宽松✅❌⚠️ 无明文nginx、Go、Django
Apache-2.0宽松✅❌✅ 有Kubernetes、Kafka、Android
MPL-2.0弱 copyleft（文件级）✅仅修改的文件✅ 有Firefox
LGPL-2.1/3.0弱 copyleft（库级）✅（动态链接）修改库本身时⚠️ 视版本Qt（LGPL 版）
GPL-2.0/3.0强 copyleft⚠️ 可商用但不能闭源分发✅ 分发即要求v3 有Linux 内核（v2）、Bash（v3）
AGPL-3.0最强 copyleft❌ 基本不适合闭源 SaaS✅ 含网络服务✅ 有Grafana、MongoDB（部分历史版本）
SSPL / BSL源码可见，非 OSI 开源❌ 有限制——MongoDB、Elasticsearch 新版本

注意最后一行：SSPL、BSL 这类"源码可见"许可证并不被 OSI 认定为开源，它们主要用来阻止云厂商"白嫖"托管服务。选型时不要把它们和真开源混为一谈。

八、能不能混用？兼容性比想象中严格

把不同许可证的代码拼进同一个项目，结果取决于方向：

  • ✅ MIT / BSD / Apache-2.0 的代码可以并入 GPLv3 项目（宽松许可允许被"升级"为更严格的条件）。
  • ⚠️ Apache-2.0 与 GPLv2 不兼容（专利与附加条款冲突），但与 GPLv3 兼容。
  • ❌ GPL 代码不能被"降级"成 MIT 再闭源分发。你只能整体按 GPL 走。
  • ⚠️ GPLv2-only 与 GPLv3-only 之间也不能随意合并。

实践中的做法是：在引入依赖前先看 LICENSE 字段，而不是等法务审计时才发现某个传递依赖是 AGPL。

九、六个高频误区

  1. "GitHub 上没写 LICENSE，说明可以随便用。" —— 反了。没有许可证 = 保留所有权利，最危险。
  2. "开源就是免费，不收费。" —— 开源约束的是自由，不是价格。Red Hat、MySQL 都靠开源软件赚钱（双许可、订阅服务）。
  3. "MIT 这么宽松，声明可以删。" —— 保留声明是 MIT 唯一的条件，删了就是违约。
  4. "我改了代码，所以版权归我，可以换许可证。" —— 你只对自己新增的部分有版权，原作品仍受原许可证约束。
  5. "用了 GPL，整个项目必须开源。" —— 取决于是否构成衍生作品、是否分发（AGPL 另算）。
  6. "MIT 就等于公共领域。" —— 不是。MIT 保留了版权，只是授权极宽；真要放弃权利用 CC0/Unlicense。

另外一个法律层面的细节：开源许可证究竟算"合同"还是"单方授权"，各国判例并不统一（美国 Jacobsen v. Katzer 案倾向于认定其为可执行的许可条件）。这直接影响违约时是"侵权赔偿"还是"合同违约"——但对使用者的实际含义是一样的：条件不满足，授权就不成立。

十、怎么选、怎么合规

如果你是作者

你的目标推荐
希望被最广泛采用，包括闭源商业产品MIT（最低摩擦）
同上，但项目涉及专利、希望企业敢用Apache-2.0
希望使用者回馈社区、防止被闭源收割GPL-3.0
是库/框架，希望闭源项目也敢链接LGPL 或 MPL-2.0
做的是服务端软件，不想被云厂商白嫖AGPL-3.0（注意会劝退部分企业）
想同时卖商业授权双许可（GPL + 商业许可，MySQL/Qt 模式）

如果你是企业使用者

  1. 建立 SBOM（软件物料清单），把所有直接与传递依赖的许可证列出来；
  2. 用工具扫描：license-checker、pip-licenses、FOSSA、ScanCode 等，接入 CI；
  3. 分级管控：MIT/BSD/Apache 绿灯；MPL/LGPL 走审核；GPL/AGPL 一律上报；
  4. 保留归属文件：LICENSE、NOTICE、第三方声明页（很多产品"关于"页面就是干这个的）；
  5. 员工贡献上游时，用 CLA 或 DCO 明确权利归属，避免公司资产流失。

结语：许可证是开源的"社会契约"

开源能运转，靠的不是无私奉献，而是一套法律上可执行的互惠机制：作者用许可证让渡权利，换取采用、贡献与声誉；使用者获得自由，代价是遵守几条清晰的规则。

MIT 用一段话完成了这个交易，所以它成了世界上被采用最广的许可证；GPL 用一整份契约试图守住"自由不能被再次剥夺"，所以它撑起了 Linux 和半个服务器世界。两者没有高下，只有不同的取舍。

下次 npm install 或 go get 之后，花十秒看一眼 LICENSE——那不是一个形式文件，而是你和作者之间唯一生效的那份约定。

说明：本文为科普性介绍，不构成法律意见。具体项目选型与合规判断，请以许可证原文及专业法务意见为准。

标签: license, 许可证

添加新评论