用了开源代码，却不懂协议？小心“免费”变“侵权”

写代码十几年，见过太多人一看到“开源”俩字，就默认等于“随便用”。

直到某天收到律师函，或者项目被迫开源，又疑问：“不是说开源免费吗？怎么还要我公开代码？”

今天，我用最直白的大白话，把最常见的6种开源协议讲清楚。

看完这篇，你至少能避开90%的开源许可证坑。

一、先记住一个核心概念：传染性

可以把开源协议想象成“病毒”的传播方式：

没有传染性：你用了我的代码，改完可以闭源，甚至可以卖钱，只需要保留我的署名。

弱传染性：你改了我的库，那这部分必须开源；但你的主程序可以闭源。

强传染性：只要你粘了我的一点代码（甚至动态链接），整个项目必须开源，而且要用同样的协议。

下面这张表，你收藏好，后面全是用它说话：

二、6种协议逐个拆解（附真实案例）

1.MIT协议——“你想咋用就咋用，别删我名字就行”

• 一句话总结：最佛系，最宽松。
• 你必须做的事：在代码里保留原作者的版权声明和协议文本。
• 你可以做的事：随便改、随便闭源、随便商用、随便和专有软件混合。

真实案例：jQuery、React（早期）、很多Node.js模块。

如果你写了个小工具，希望被全世界采用，选MIT准没错。

坑点：没有明确专利授权。如果你

2.BSD协议——MIT的“优雅版”

跟MIT几乎一样，只是多了一句：不允许用作者的名字做商业推广。

比如你用了Google的BSD代码，不能说“本产品获得Google推荐”。

3.Apache2.0——大厂首选，专治专利流氓

比MIT多了两条核心条款：

• 明确授予专利使用权：贡献者不能回头告你用了他代码里的专利。
• 专利报复：如果你告别人侵权，你对这个项目的专利授权自动失效。

真实案例：Android、Kubernetes、Apache基金会所有项目、CRMEB开源商城系统。

适合：你希望别人用你的代码，但又担心被专利碰瓷。大厂内部开源基本首选Apache2.0。

用了大公司的MIT代码，它回头拿专利告你，协议保护不了你。

4.LGPL——“我就库开源，你用我的库写程序可以不开源”

GPL家族里最温和的一个。

它允许你的程序动态链接一个LGPL库（比如.so或.dll），你的主程序可以闭源。

但如果你修改了LGPL库本身，那这些修改必须开源。

经典案例：GNUC库（glibc）、LGPL版的FFmpeg。

坑点：如果你静态编译了LGPL库（代码打包到一起），那整个程序也得开源。

5.GPL——最著名的“传染性”协议

核心理念：你享受了我的自由，就不能剥夺别人的自由。

只要你使用了任何GPL代码（哪怕只是一小段），你的整个项目必须：

• 以GPL协议开源
• 提供完整的源码

真实案例：Linux内核、Git、WordPress。

GPLv2 vs GPLv3：

• v3增加了明确的专利授权和反Tivoization条款（不允许用硬件限制自由）。
• 很多老项目坚持用v2（比如Linux），因为Linus不喜欢v3的一些限制。

注意：GPL只在你分发软件时触发。如果只在自己公司内部使用，不对外发布，可以不用公开源码。

6.AGPL——云时代的GPL

GPL有个漏洞：我把GPL软件改一改，部署在云上作为SaaS服务，不给你分发软件，就不用公开源码。

AGPL补上了这个洞：只要通过网络和用户交互（比如Web访问），就必须提供源码。

真实案例：MongoDB（早期）、一些开源ERP和商城系统。

所以：如果你打算基于某个AGPL项目做二次开发，然后做成云服务卖钱，你必须把你的全部源码公开。很多云厂商因此绕道走。

三、我该选哪个？（直接照做）

三、我该选哪个？（直接照做）

场景1：我写了个小工具，想让人随便用

→ MIT或BSD

场景2：我在大厂，公司要求必须明确专利授权

→ Apache2.0

场景3：我写了个基础库（如数据库驱动），希望商业软件也能用，但改了我的库必须开源

→ LGPL

场景4：我就是要强制所有衍生品都开源，构建开源生态

→ GPLv3

场景5：我做了一个开源商城，不想云厂商拿去改了就跑不反馈

→ AGPL3.0

四、最常踩的三个坑（别等律师找你）

1. GitHub/Gitee上没写协议的代码，默认是“保留所有权利”

你不能随便用。没协议≠开源。

2. 动态链接≠绝对安全

有些语言（如Java的import、Go的模块）可能被法院认定为“静态链接”，最好咨询律师。

3. 混合使用不同协议要小心

• MIT/BSD/Apache可以混入GPL项目
• 但Apache2.0和GPLv2不兼容（Apache2.0代码不能放进GPLv2项目）
• GPLv2和GPLv3也不兼容（除非作者写了“orlater”）

写在最后：开源不是法外之地，而是契约精神的体现

我见过有人因为混用了GPL代码没开源，被要求下架整个产品；也见过创业公司因为选了AGPL，融资时被法务卡住。

协议不是形式主义，是你的法律责任。

如果你看完还是不确定，最简单的原则：

• 想省事，用MIT
• 想防专利，用Apache2.0
• 想让别人必须开源，用GPL/AGPL

开源协议不仅仅是冷冰冰的法律条文，它更是开源世界的“社交礼仪”。

对于使用者：遵守协议是对原作者劳动成果的尊重，也是保护自己项目不“暴雷”的底线。

对于创作者：选择正确的协议，是对你代码未来命运的掌控——是希望它被广泛传播（MIT），还是希望它回馈社区（GPL）。

在复制粘贴代码之前，花1分钟看一眼 LICENSE 文件，这不仅是技术素养的体现，更是作为一名成熟开发者的职业操守。