开源协议有哪些你知道吗？
前两天有个读者在后台问我，说他们公司用了某个开源组件做项目，结果收到律师函了，说违反了开源协议。我当时心里一紧，这种事其实挺常见的，很多开发者压根不知道自己用的那些库到底有什么限制。
想起来我刚开始做运维那会儿，也是一脸懵。那时候领导让我搭建个内部代码仓库，我就直接把公司代码往上一推，后来才知道有些依赖包是不能随便用的。好险没出大问题。
今天就聊聊开源协议这事儿，说实话，很多人干了几年开发运维，对这个还是一知半解。特别是那个让无数SaaS公司闻风丧胆的AGPL，后面我会专门讲到。
开源协议到底是啥玩意
说白了，开源协议就是一套规则，告诉你这个代码你能怎么用、能怎么改、能不能商用。就像你去别人家做客，主人得跟你说清楚哪些房间能进，哪些东西能碰。
很多人有个误区，觉得开源就是免费的，想咋用咋用。这想法挺危险的。开源不等于免费，也不等于没有约束。代码开源了，作者还是拥有著作权的，只是给了你一些使用权而已。
我记得有次跟同事争论，他说开源代码随便用，公司项目里直接复制粘贴都行。我当时就提醒他，你看看那个项目的 LICENSE 文件写的啥。结果一看，GPL 协议，这下尴尬了。
为啥要有这东西
这事儿得从上世纪 80 年代说起。
那时候有个叫 Richard Stallman 的程序员，他在 MIT 人工智能实验室工作。有次打印机坏了，他想修改打印机的驱动程序，结果发现厂商不给他源代码。这事儿让他很不爽，他觉得软件应该自由，用户应该有权利修改自己用的软件。
于是 1983 年，他发起了 GNU 项目，1985 年成立了自由软件基金会（FSF）。这个人挺有意思，为了理想，放弃了不少东西。他创造了一个概念叫 copyleft，跟 copyright（版权）对着干。
说到这儿，我得插一句。很多人分不清自由软件和开源软件。其实这俩不完全一样。自由软件强调的是用户的自由权利，开源软件更强调开发模式的开放性。不过日常交流中，大家经常混着用。
主流开源协议大盘点
现在主流的开源协议有好几种，每种都有自己的脾气。我一个个说。
MIT 协议
这个最宽松，基本上就是"你想咋用咋用，只要保留我的版权声明就行"。
具体来说，你可以：
- 随便用，商业用途也行
- 随便改，改完可以闭源
- 随便分发
限制就一条：保留原作者的版权声明和许可声明。
我见过不少项目用 MIT，比如 React、Vue.js 这些。选择 MIT 的好处是传播广，坏处是别人拿你的代码去赚钱，你也没话说。
Apache 协议 2.0
这个比 MIT 稍微复杂点，但也很友好。
主要特点：
- 可以商用，可以闭源
- 修改后需要说明修改了什么
- 保留版权声明
- 如果有专利，自动授予专利许可
这个专利授权挺重要的。有些公司开源项目，可能会涉及专利问题。Apache 2.0 就明确说了，我开源这代码，专利权也给你用了，不能以后拿专利来告你。
Android 系统就是用的 Apache 2.0，这也是为什么那么多厂商能基于 Android 做自己的系统。
BSD 协议
这个有好几个版本：BSD 2-Clause、BSD 3-Clause 等。
BSD 2-Clause 跟 MIT 差不多，就是允许自由使用，保留版权声明就行。
BSD 3-Clause 多了一条：不能用原作者的名义来做广告。这条挺实用的，避免有人打着原作者的旗号搞事情。
GPL 协议
这个是开源协议里的刺头，也是争议最大的。
GPL 的核心思想是传染性。什么意思呢？如果你用了 GPL 协议的代码，那你的项目也得开源，而且得用 GPL 协议。
这就像病毒一样，会传染。所以很多商业公司对 GPL 很警惕，生怕一不小心就中招了。
GPL 有两个主要版本：GPL v2 和 GPL v3。
GPL v2 是最经典的，Linux 内核就是用的这个。Linus Torvalds 到现在还坚持用 v2，不用 v3。
GPL v3 更严格，加了一些反 DRM 的条款。简单说就是，如果你的设备上运行的是 GPL v3 的软件，你得让用户能修改这个软件。这主要是针对 TiVo 这种设备的，TiVo 用了 Linux，但不让用户修改，所以 FSF 在 v3 里专门加了这条款。
LGPL 协议
这个是 GPL 的弱化版，主要给库文件用的。
如果你把 LGPL 的库链接到你的程序，你的程序不需要开源。但如果你修改了这个库本身，那修改的部分得开源。
很多底层库用 LGPL，比如 glibc。这样商业软件也能用，不用担心被传染。
MPL 协议
Mozilla Public License，Mozilla 基金会搞的。
这个比较折中，文件级别的 copyleft。就是说，你修改了某个文件，这个文件得开源。但你新增的文件不需要开源。
Firefox 就是用的这个协议。
AGPL 3.0 - SaaS 公司的噩梦
这个协议我得专门拿出来说，因为这几年太重要了，也是很多公司容易踩坑的地方。
AGPL 全称是 GNU Affero General Public License v3，是 GPL 的一个变种，而且是个狠角色。
为什么会有 AGPL
这事儿得从 GPL 的一个"漏洞"说起。
GPL 规定，如果你分发了二进制代码，就得提供源代码。但问题是，如果你通过网络提供服务，不分发二进制呢？
举个例子，你用 GPL 的代码搭建了一个网站，用户通过浏览器访问你的服务，但你没有把代码给用户。这种情况下，GPL 不要求你开源。
很多公司就钻了这个空子。拿 GPL 的代码改改，做成 SaaS 服务，赚钱了，但不用开源。这事儿让 FSF 很不爽。
于是 2007 年，AGPL v3 出来了，专门堵这个漏洞。
AGPL 的核心要求
AGPL 的核心就一句话：通过网络提供服务，也算分发，也得开源。
具体来说：
- 如果你用 AGPL 的代码做了 SaaS 服务
- 用户通过网络访问你的服务
- 你就得提供源代码给你的用户
这跟 GPL 不一样。GPL 只在你分发软件的时候要求开源，AGPL 是你提供服务就要求开源。
AGPL 的传染性
跟 GPL 一样，AGPL 也有传染性。而且更强。
如果你的 SaaS 服务后端用了 AGPL 的组件，整个后端都得开源。前端如果跟后端紧密耦合，可能也得开源。
这个"紧密耦合"怎么界定，其实挺模糊的，容易扯皮。所以很多公司干脆一刀切，禁止用 AGPL 的代码。
哪些项目用 AGPL
一些数据库、云原生项目用 AGPL，比如：
- MongoDB（早期版本，后来改成 SSPL 了）
- InfluxDB
- Grafana（部分组件）
- Mattermost
这些项目为什么要用 AGPL？因为不想被云厂商白嫖。我辛辛苦苦开发的开源软件，你拿去做成云服务赚钱，还不回馈社区，这谁受得了。
MongoDB 以前用 AGPL，后来觉得 AGPL 还不够，改成了 SSPL（Server Side Public License）。SSPL 要求更严格，提供服务的整个技术栈都得开源，包括你写的那些管理工具、自动化脚本。OSI 不承认 SSPL 是开源协议，但 MongoDB 还是坚持用了。这说明什么？开源和商业利益之间，有时候就是有冲突。
AGPL 和 GPL 的区别
我整理个对比：
| 方面 | GPL v3 | AGPL v3 |
|---|---|---|
| 分发二进制 | 需要开源 | 需要开源 |
| 本地使用 | 不需要开源 | 不需要开源 |
| 网络服务（不分发） | 不需要开源 | 需要开源 |
| 传染性 | 有 | 更强 |
| 适用场景 | 传统软件 | SaaS/云服务 |
简单说，AGPL = GPL + 网络服务条款。
真实案例
说几个我知道的。
案例一：某公司用 AGPL 组件做内部工具
有个公司，运维团队用了一个 AGPL 的监控组件，部署在内网。后来法务审核，发现这个组件是 AGPL 的。
内部工具要不要开源？严格来说，内部员工也算"用户"，如果他们通过网络访问这个服务，理论上应该开源。
最后这个公司选择把这部分代码开源了，省得麻烦。
案例二：云厂商和 AGPL
AWS、Google Cloud 这些大厂，对 AGPL 很谨慎。一般禁止在云服务中使用 AGPL 的代码。
为什么？因为一旦用了，可能就得把整个服务栈开源。这对商业公司来说，是不可接受的。
公司如何应对 AGPL
如果你是做 SaaS 的，我的建议：
策略一：坚决不用
最简单的办法，直接禁止引入 AGPL 的依赖。很多公司都是这么干的。
策略二：隔离使用
如果非要用，做好隔离。比如用 API 调用，而不是直接引入代码。但这个"隔离"够不够，法律上还有争议。
策略三：购买商业许可
很多 AGPL 的项目提供商业许可，花钱买就完事了。MongoDB 就是这样，既开源又卖商业版。
策略四：开源
如果你的商业模式不依赖代码保密，那就开源呗。现在很多公司就是开源+商业服务的模式。
各种协议到底限制了啥
我整理个表格对比一下，把 AGPL 也加进去，不过先说清楚，这只是一般情况，具体还得看协议原文。
| 协议 | 能否商用 | 能否闭源 | 网络服务是否需要开源 | 传染性 | 专利授权 |
|---|---|---|---|---|---|
| MIT | ✓ | ✓ | ✗ | 无 | ✗ |
| Apache 2.0 | ✓ | ✓ | ✗ | 无 | ✓ |
| BSD | ✓ | ✓ | ✗ | 无 | ✗ |
| GPL v3 | ✓ | ✗ | ✗ | 有 | ✓ |
| LGPL | ✓ | ✓ | ✗ | 弱 | ✓ |
| AGPL v3 | ✓ | ✗ | ✓ | 更强 | ✓ |
这里有个坑要注意，GPL 和 AGPL 的商用是允许的，但前提是你得开源。所以很多公司直接一刀切，禁止用 GPL 和 AGPL 的代码。
历史上那些著名的开源协议事件
说几个真实的案例。
MySQL 和 GPL
MySQL 是 GPL 协议的，但 MySQL AB 公司还提供商业许可。什么意思呢？如果你不想开源你的项目，你可以花钱买商业许可。
这种双许可模式挺聪明的，既保证了开源，又能赚钱。后来 Oracle 收购了 MySQL，这套模式还继续用着。
BusyBox 和 GPL 诉讼
BusyBox 是个嵌入式 Linux 工具集，GPL 协议。有好几家公司因为用了 BusyBox 但不开源，被起诉了。
2007 年，Monsoon Multimedia 被起诉，最后和解了，同意开源相关代码。还有几起类似的诉讼，都是 GPL 违规。
这事儿告诉我们，GPL 是认真的，不是开玩笑的。
React 许可证风波
2017 年，Facebook 的 React 项目用的不是标准协议，而是 BSD + 专利授权。这个专利授权条款有争议，说如果用户起诉 Facebook 专利侵权，Facebook 可以撤销 React 的专利授权。
Apache 基金会直接宣布禁止在 Apache 项目中使用 React。后来 Facebook 妥协了，把 React 改成了 MIT 协议。
这事儿闹得挺大，也让大家意识到开源协议的法律问题有多重要。
我踩过的坑
说说我自己的经历。
坑一：没看 LICENSE 文件
有一回，我在项目里用了一个开源工具，做日志分析。当时觉得挺好用的，直接就上了生产环境。后来要给客户交付，法务审核的时候发现，那个工具是 GPL v3 协议的。
这下麻烦了，要么我们整个项目开源，要么换工具。最后只能连夜换工具，加班加点重新搞。
从那以后，我养成了习惯，引入任何依赖，先看 LICENSE。
坑二：以为开源就是免费
有个项目用了某个开源数据库，觉得开源的嘛，随便用。后来才知道，商业使用需要付费，或者得开源你的项目。还好那个项目本身就是要开源的，没出问题。
但这个教训我记住了，开源不等于免费商用。
坑三：修改了代码没说明
用了 Apache 2.0 的项目，改了里面的代码，但没在文件里说明修改了什么。严格来说，这是违反协议的。虽然没人追究，但合规意识得有。
坑四：SaaS 服务用了 AGPL 组件
这个是我同事踩的坑。他们团队用了一个 AGPL 的库做后端服务，后来法务审核才发现。那个库的功能挺核心的，换掉成本很高。
最后没办法，只能跟对方谈商业授权，花了一笔钱。从那以后，公司就把 AGPL 列入黑名单了。
怎么选择开源协议
如果你要开源自己的项目，怎么选协议？
我的建议是：
想传播得广，不在乎别人拿去赚钱，选 MIT 或 BSD。
想传播得广，但有专利问题，选 Apache 2.0。
想保证代码永远开源，不想被别人拿去闭源商用，选 GPL。
写的是库文件，想让商业软件也能用，选 LGPL 或 MIT。
如果你做的是云服务相关的项目，不想被云厂商白嫖，可以考虑 AGPL，但要做好传播受限的准备。
说实话，大多数情况下，MIT 或 Apache 2.0 就够了。GPL 虽然理想主义，但确实限制了传播。AGPL 更是双刃剑，用之前要三思。
公司里怎么管理开源协议风险
这个话题展开说能说一整篇，简单讲几点。
建立内部的开源组件审核流程。引入新的依赖，必须经过审核，看看协议是什么，有没有风险。
维护一个白名单和黑名单。白名单里的协议可以直接用，黑名单里的坚决不用，灰名单里的需要审批。一般来说，MIT、Apache 2.0、BSD 在白名单；GPL 在灰名单，需要审批；AGPL 直接进黑名单。
用工具扫描。有些工具能自动扫描代码库，识别用了哪些开源组件，协议是什么。比如 Black Duck、FOSSA、Sonatype 这些。
培训开发人员。很多时候问题出在开发人员不懂，随手就引入了有问题的依赖。定期培训，讲讲开源协议知识，很有必要。
一些常见误区
说几个我经常听到的错误认识。
误区一：开源就是公有的
错。开源软件是有版权的，作者只是给了你使用权。你不遵守协议，就是侵权。
误区二：没写 LICENSE 就是随便用
错。没写 LICENSE，默认是版权所有，你没有任何使用权。联系作者，让他明确授权。
误区三：GPL/AGPL 不能商用
错。GPL/AGPL 可以商用，只是要求开源。很多公司靠 GPL 软件赚钱，比如 Red Hat。
误区四：用了开源代码，只要开源就行
不一定。有些协议要求保留版权声明，有些要求说明修改内容，有些要求用同样的协议。光开源不够，还得按规矩来。
误区五：内部使用不用管协议
也不对。AGPL 对内部使用也有要求，而且内部使用如果涉及分发，GPL 也会触发。
实用工具推荐
最后推荐几个工具，帮你看懂开源协议。
choosealicense.com - GitHub 官方的，帮你选择协议。
tldrlegal.com - 用通俗语言解释各种法律条款，包括开源协议。
SPDX License List - 标准化的协议标识符列表，方便识别。
GitHub 上也有协议识别功能，项目里有 LICENSE 文件，会自动显示协议类型。
license-checker - npm 包，能扫描项目的依赖协议。
写在最后
开源协议这事儿，说复杂也复杂，说简单也简单。核心就一点：尊重原作者的意愿，按规矩来。
我见过太多因为不懂开源协议惹麻烦的了。有的是无心之失，有的是心存侥幸。不管哪种，最后都得付出代价。
特别是现在 SaaS 和云服务这么普及，AGPL 这种协议越来越常见。做运维和开发的，必须得搞清楚这些协议的区别，不然哪天踩坑了都不知道怎么回事。
做技术这么多年，越来越觉得，技术能力是一方面，法律意识、合规意识同样重要。你可以不懂法律的细节，但得有这个意识，知道什么时候该咨询专业人士。
开源社区给了我们这么多好东西，我们也应该尊重规则，回馈社区。这样生态才能良性循环。
希望这篇文章能帮到大家。如果觉得有用，点个赞，转发给更多人看到。有什么问题，评论区留言，我看到都会回复。
公众号：运维躬行录
个人博客：躬行笔记
