我问答网上周帮刚做独立开发的学弟改项目合同，他差点因为用了个开源的图片压缩工具赔20万。我当时看着他手机里的GPLv3许可证截图，后背都凉了。
踩坑的人，90%都是根本没点开过许可证
很多人对开源软件的认知，还停留在“免费、随便用、不用给钱”的层面。下个工具，扔自己项目里，改两行代码就上线卖，谁会特意点开那个藏在根目录的LICENSE文件啊？
真的别不信❗ 前两年有个做独立笔记软件的开发者，就是因为用了个MIT协议的图片处理库，没在关于页面保留原作者的版权声明，被原作者找上门要了5万块赔偿。
不同开源许可证的规则，差得能有十万八千里。MIT是真的宽松，你随便改、随便商用、随便卖，只要在软件的某个角落附上原作者的版权声明就行，连跳转链接都不用放，就是一行小字的事。但GPL系列的规则完全是另一个极端——你要是把GPLv3的代码整合进自己的商用软件里，那你整个软件的所有源码，都得按GPL的要求全部公开，不然就是实打实的侵权。
太冤了。
学弟当时就是踩了这个坑。他做的电商小程序模板卖999一套，本来已经谈好几个客户了，结果用的那个图片压缩组件是GPLv3的，真要是上线收钱，他不仅要把自己写了三个多月的小程序源码全免费放出来，还要赔人家侵权损失。
别被“大厂背书”骗了，开源坑从来不分大小
很多人觉得，只要是谷歌、阿里、字节这些大厂放出来的开源项目，随便用肯定没问题。
错。
前两年有个做跨境独立站的小团队，用了谷歌开源的一个图片渲染组件，搭完站跑了大半年，突然收到律师函。人家说这个组件虽然是Apache2.0协议的，但是里面附带的第三方专利条款写得明明白白，商用请求量超过10万次就要交专利授权费，他们当时已经跑了37万次请求，算下来要掏十几万的专利费。我听他们老板说这事的时候，都替他肉疼。
还有种坑更隐蔽。很多开源项目看着是完全开放的，但是核心的企业级功能、技术支持、商用交付权限，都是要单独收费的。你自己搭着玩没问题，要是把这些开源组件整合到你卖给客户的企业服务里，人家的商务团队分分钟找过来，说你用的是社区版，不允许商用交付，要补买几万块的企业授权才能继续用。
💡 真的，别觉得大厂做开源是来做慈善的。人家背后的商业化布局，算得比谁都精。之前Redis改许可证那事还记得不？多少小团队之前免费搭的缓存服务，要么掏真金白银买授权，要么折腾半个月换替代品，鸡飞狗跳的。
真要避坑，其实根本不用背完所有许可证
我知道很多人一听到BSD、MPL、LGPL这些缩写就头大，条款翻来覆去全是法律术语，看着就犯困。
其实哪有那么复杂。我自己做独立开发快6年，踩过好几次坑，总结出来三个根本不会出错的实操原则，新手照着做就行。
第一，只要是用来做商用售卖的项目，优先选MIT、Apache2.0、BSD这三个许可证的组件。这三个是业内公认的最宽松的协议，只要你保留好原作者的版权声明，基本不会有侵权问题。遇到GPL、AGPL开头的组件，直接绕路走，别碰，哪怕那个功能再好用，花十分钟找个同功能的替代就行，不然指不定哪天就给你整个大的。
第二，别光看项目根目录的LICENSE文件，一定要顺着依赖列表翻一遍所有嵌套组件的许可证。很多人下了个开源项目，看根目录写的是MIT，就直接放心用，结果里面嵌套的某个几KB大小的小工具是GPL协议的，直接触发许可证传染——哪怕你自己写的代码全是原创的，只要带了那个GPL组件，整个项目都得按GPL的要求开源。我有个朋友之前写了三个多月的博客系统，本来打算靠这个卖付费主题的，就是因为引了个GPL协议的代码高亮插件，直接不敢商用了，差点把刚租的服务器退了。
第三，拿不准的，直接给项目维护者发邮件问。别觉得人家不理你，大部分开源项目的维护者都很乐意回复的。你就大大方方说自己是独立开发者，打算把包含这个组件的项目做商用售卖，会不会有许可证层面的问题，人家一般都会给你明确的答复。提前问清楚的成本，比等人家找上门要赔偿的成本，低了不知道多少倍。
哦对，不过话说回来，开源软件本身真的是个好东西。我之前用的那个开源笔记软件，提了个bug说M系列芯片下导出PDF会乱码，三天就有维护者提了修复PR，响应速度比我之前买的某付费笔记软件快了不知道多少倍。说白了，开源本来就是一帮技术人凑在一起，把自己写的好用的代码拿出来共享的好事，别因为自己的疏忽，把好事变成了自己的亏心事。
上次学弟听完我讲的这些，当场把那个GPL的图片压缩工具换成了MIT协议的替代组件，现在他的小程序模板已经卖了27份了，昨天还请我喝了杯28块的冰美式。