开源项目的许可协议怎么看：MIT、Apache、BSL 有什么区别
用开源项目的时候，很多人只看功能不看协议，直到要商用或者要二次开发才发现踩了坑。开源许可协议决定了你能怎么用这些代码，理解几个主要类型能帮你避开不少麻烦。这篇文章用尽量直白的方式讲清楚。
图片由 AI 生成
宽松型：MIT、Apache 2.0
这两类是最宽松的，也是商业使用最友好的。你可以自由使用、修改、分发，甚至可以闭源，只要保留原有的版权声明就行。
两者的主要区别在细节：Apache 2.0 额外提供了专利授权条款，明确说了贡献者不会因为你用了这份代码就来主张专利，这对企业用户更友好；MIT 则更简短直白。还有一类 BSD 协议，风格和 MIT 接近。
如果你要做一个商业产品，优先选择这类协议的依赖，最大的好处是不用担心未来某天被要求开源自己的代码。
图片由 AI 生成
传染型：GPL 系列
GPL 的核心是「传染性」——如果你用了 GPL 的代码并且对外分发，那么你的整个作品也需要以 GPL 开源。这本身不是坏事，它保证了开源生态的循环，但对商业闭源产品来说是需要避开的。
需要注意的是，AGPL 更为严格，它把「通过网络提供服务」也算作分发。也就是说，即使你只是把软件部署成在线服务、不发布二进制包，也可能触发开源义务。做 SaaS 的话要特别留意这一条。
介于两者之间：BSL 这类
近几年出现了一些「源码可用」的协议，代表就是 BSL（Business Source License）。它的思路是：代码是公开的，你可以看、可以改、可以在一定范围内用，但如果要用它提供商业服务，可能受到限制；同时，这类协议通常约定在若干年后自动转为更宽松的开源协议。
很多基础设施类项目转向这类协议，是为了在「让社区使用」和「防止云厂商直接拿来卖钱」之间找平衡。对普通用户可能没影响，但如果你要做和它类似的商业服务，就必须非常仔细地读条款。
实际使用时的建议
第一，商用项目要建立一份依赖清单，把每个依赖的协议记下来，尤其是传染型协议。第二，注意协议可能随版本变化，同一个项目不同版本协议可能不同，升级时要重新确认。第三，遇到「源码可用但非标准开源」的协议，不要想当然地按开源处理，一定读原文或者问法务。
一个常见的误解
很多人以为「代码公开在 GitHub 上就是开源，就能随便用」。这不对。公开可见不等于授权你任意使用，仓库里如果没有明确的许可文件，严格来说你是没有使用授权的。选依赖之前，先看仓库根目录有没有 LICENSE 文件，这是最基础的一步。
