开源协议避坑指南：从MIT到AGPL的5大陷阱

TL;DR

开源协议不是摆设，选错了能让你的商业软件瞬间变成”必须开源”。MIT最自由，GPL传染性最强，AGPL专治云服务白嫖。这篇文章按”从宽到严”的顺序，帮你搞清楚5-6种常用协议的坑在哪。

为什么要懂开源协议？

你想想这个场景：

你花了半年做了个SaaS产品，准备卖钱。结果客户的法务发现你用了GPL的库，要求你开源整个项目。不开源？那就等着律师函。

这不是吓唬你，是真实发生过的事。

开源协议（Open Source Licenses）繁多，但实际上常用的只有5-6种。了解它们的核心区别，主要是看“如何使用”和“如何回馈”这两个维度上的限制程度。

咱们按“限制从宽到严”（即从最自由到最严格）的顺序来分类。

一、宽松型协议：你随便用

这类协议的核心精神是：“你可以随便用，甚至可以闭源商用，只要保留我的署名就行。”

1. MIT 协议

特点：史上最简单的协议之一。

你可以任意修改、复制、商用、闭源，唯一的义务是在你的软件中包含原作者的版权声明。

坑点（风险）：

专利风险

MIT 没有明确包含”专利授权”条款。

如果原作者日后申请了相关专利，理论上可以起诉使用者侵权（虽然极少发生，但法律层面上不如Apache 2.0严谨）。

免责声明

作者完全不负责，代码跑崩了别找他。

2. BSD 协议（通常指BSD 3-Clause）

特点：和MIT非常相似，允许闭源商用。

坑点（限制）：

禁止背书

多了一个限制条款——不能利用贡献者的名字进行广告或以此来推广你的产品。

比如你用了某个大学（如加州大学伯克利分校）的BSD代码，你不能打着他们的旗号卖软件。

3. Apache 2.0

特点：允许闭源商用。

优势：比MIT/BSD多了明确的专利授权。

这意味着，贡献者一旦贡献了代码，就自动承诺不会因为你用了这些代码而起诉你专利侵权。

这也是大公司（Google、Android、Java生态）偏爱它的原因。

二、弱Copyleft协议：改了库得开源

这类协议的核心精神是：“你可以用库，但如果你修改了库本身，得把修改部分开源。”

1. MPL（Mozilla Public License）

特点：文件级开源。

如果你修改了现有的MPL协议文件，该文件必须开源；但如果你只是添加新文件或将其链接到你的程序中，你的主程序可以闭源。

坑点：混合代码管理麻烦。

如果你在一个文件中混合了MPL代码和私有代码，整个文件都得开源。

2. LGPL（Lesser GPL）

特点：它是GPL的妥协版本，主要用于类库（Library）。

坑点（链接方式）：

动态链接（Dynamic Linking）

如果你只是动态调用（如.dll或.so），你的主程序可以闭源。

静态链接（Static Linking）

如果你把它静态编译进你的程序，或者修改了它，你就必须开源你的主程序（或者提供目标文件让用户可以重新链接）。

很多移动端开发（iOS/Android）容易在静态链接上踩坑。

三、强Copyleft协议：传染性极强

这类协议的核心精神是：“用了一点点，全家都得开源。”

1. GPL（v2或v3）

特点：传染性极强。

只要你的软件使用了GPL的代码（引用、复制、修改），并且分发（Distribute）了软件，你的整个软件也必须在GPL下开源。

Linux内核使用的就是GPL v2。

坑点（大坑）：

商业软件禁区

如果你想做卖钱的闭源软件，千万别碰GPL代码。

分发的定义

传统的GPL触发条件是”分发”。

如果你只是在公司内部服务器跑，不给客户代码，理论上不需要开源（除非涉及v3的Tivoization条款）。

2. AGPL（Affero GPL）

特点：云服务杀手。

它是为了堵住GPL的漏洞而生的。

坑点（SaaS噩梦）：

网络交互即分发

即使你没有把软件卖给客户，只是把它放在服务器上通过网络（SaaS）给用户提供服务，你也必须开源。

案例

很多数据库（如早期的MongoDB）曾使用此协议，防止云厂商（如AWS）直接拿去改改就卖云服务而不回馈社区。

四、总结：常见的”坑”与避雷指南

核心建议

作为开发者

引入第三方库时，务必检查LICENSE文件。

如果看到GPL或AGPL，需请示法务或技术负责人，特别是当你在开发公司核心闭源产品时。

作为开源作者

• 想让大家随便用？选MIT。
• 想保护专利且显得正规？选Apache 2.0。
• 不想让别人白嫖去闭源赚钱？选GPL。
• 不想让云厂商白嫖？选AGPL。

就这样，开源协议的坑你应该懂了。下次引入第三方库之前，先看看LICENSE文件，别等律师函来了才后悔。