做开发必须知道的开源协议，一篇文章帮你分清楚！

用了开源代码，却不懂协议？小心“免费”变“侵权”写代码十几年，见过太多人一看到“开源”俩字，就默认等于“随便用”。直到某天收到律师函，或者项目被迫开源，又疑问：“不是说开源免费吗？怎么还要我公开代码？”今天，我用最直白的大白话，把最常见的6种开源协议讲清楚。看完这篇，你至少能避开90%的开源许可证坑。一、先记住一个核心概念：传染性可以把开源协议想象成“病毒”的传播方式：没有传染性：你用了我的代码，改完可以闭源，甚至可以卖钱，只需要保留我的署名。弱传染性：你改了我的库，那这部分必须开源；但你的主程序可以闭源。强传染性：只要你粘了我的一点代码（甚至动态链接），整个项目必须开源，而且要用同样的协议。下面这张表，你收藏好，后面全是用它说话：二、6种协议逐个拆解（附真实案例）1.MIT协议——“你想咋用就咋用，别删我名字就行”一句话总结：最佛系，最宽松。你必须做的事：在代码里保留原作者的版权声明和协议文本。你可以做的事：随便改、随便闭源、随便商用、随便和专有软件混合。真实案例：jQuery、React（早期）、很多Node.js模块。如果你写了个小工具，希望被全世界采用，选MIT准没错。坑点：没有明确专利授权。如果你用了大公司的MIT代码，它回头拿专利告你，协议保护不了你。2.BSD协议——MIT的“优雅版”跟MIT几乎一样，只是多了一句：不允许用作者的名字做商业推广。比如你用了Google的BSD代码，不能说“本产品获得Google推荐”。3.Apache2.0——大厂首选，专治专利流氓比MIT多了两条核心条款：明确授予专利使用权：贡献者不能回头告你用了他代码里的专利。专利报复：如果你告别人侵权，你对这个项目的专利授权自动失效。真实案例：Android、Kubernetes、Apache基金会所有项目、CRMEB开源商城系统。适合：你希望别人用你的代码，但又担心被专利碰瓷。大厂内部开源基本首选Apache2.0。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——云时代的GPLGPL有个漏洞：我把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 文件，这不仅是技术素养的体现，更是作为一名成熟开发者的职业操守。