好多人觉得我都拿到源码本地部署了，不就是随便用吗？这真的是大错特错。
我之前遇到过一个做创业项目的朋友，自己找了个开源项目改了改就上线了，没大半年就收到了原作者的律师函。就因为那个源码用的是GPL协议，只要你基于它改了还闭源商用，直接就是违规侵权。
你可别以为这是小概率事件。我记得之前看到过一个数据，国内差不多七成的本地部署开源项目，都存在不同程度的合规问题，其中超过一半都是开发者根本没仔细看源码的许可证，稀里糊涂就用了。
哪怕你是真的无意，真的不知道这个协议的要求，该承担的责任一点都不会少。赔了钱还丢了项目，真的太亏了。
本地部署的源码，看着是一个项目，其实背地里不知道嵌了多少别人的开源组件。你自己去数，根本数不清楚。
就拿一个普通的前端项目来说吧，光依赖的npm包可能就有上百个，每个包都有自己的许可证，一个没注意就踩坑。
你得先做一轮全依赖梳理，把你的项目从底层到上层用到的所有源码、组件、补丁，全部都扒出来列清楚。
我个人觉得，别靠人工去理，太容易漏了，现在有好多自动化工具可以扫，扫完直接给你出清单，谁用什么协议，一清二楚。
哪怕你是小项目，自己手动梳理，也一定要把每个文件的来源、作者、协议都记下来，别嫌麻烦，这一步错了，后面全白搭。
不是所有开源许可证都能随便用在商用项目里的。最常见的其实就分两大类，一类是宽松许可证，比如MIT、Apache，另一类是Copyleft类型的，比如GPL系列。
宽松型的基本没问题，你改了闭源商用也没事，只要你保留原作者的版权声明就行。但GPL这种就不一样了，只要你在你的项目里集成了GPL协议的代码，并且对外发布，你的整个项目都得开源，不然就是违规。
还有更复杂的，LGPL相对宽松一点，可以动态链接不用开源，静态链接就得改协议，好多人搞不清楚，直接就用了，这不就出事了。
梳理完依赖之后，你就得把每个依赖的协议按风险等级分好：完全允许商用低风险的、需要满足特定条件才能用的、绝对不能用到你项目里的。
如果遇到同一个项目里同时有好几种不同协议的代码，你还得做兼容性检查，比如你把GPL代码和MIT代码放一块，最后整个项目都得遵从GPL的要求，这个坑真的好多人踩。
合规审查不是说你部署完做一次就完事了，得变成日常的机制，每次更新依赖、每次改代码发版本，都得查。
我有个做开发的朋友，他们公司之前就是，项目一开始查好了，后来更新版本的时候，开发偷偷换了一个更高版本的依赖，那个新版本协议改了，直接从MIT改成了GPL，上线大半年才发现，当时整个团队都傻了。
所以你得把审查嵌到你的开发流程里，比如你改完代码要合并的时候，自动跑一遍依赖扫描，新引入的组件自动做协议检查，有风险直接卡下来，不让你过。
如果你是团队开发，还得指定专门的人来管这个事，别人人都随便加依赖，加新依赖之前必须过一遍审查，确认没问题才能进项目。
哪怕你是个人开发，做个小项目准备上线卖钱，也得每次发版前扫一遍，花不了多少时间，但是能帮你避开天大的坑。
扫出来有问题，别慌，也别直接就把项目扔了，不同情况有不同的处理办法。
如果只是这个组件的协议不适合你的项目，那你看看能不能换一个功能差不多，协议更宽松的替代组件呗，现在开源圈同类型的工具不要太多，换一个成本比你出事打官司低多了。
换不了怎么办？那你得联系原作者，去买一个商业授权呀，好多开源项目都是双协议，你非商用用开源的，要商用掏钱买个授权就搞定了，也不是说完全不能用。
实在联系不上作者，也换不了替代方案，那你就得找专业的合规律师帮你评估风险了，看看这个风险你能不能接受，有没有什么整改的办法。
千万不能抱着侥幸心理，假装没看见，你越躲，最后出事亏得越多。无意侵权也是侵权，该赔的一分都少不了。
整个审查流程走完，所有的东西都得留下书面记录，你梳理了哪些依赖，每个依赖是什么协议，你做了什么审查，怎么处理的风险，全部都存好。
真到万一哪天出事了，这些记录就是你“无意”的最好证明，能帮你减轻好多责任，至少能说明你不是故意侵权的，你已经尽到审查义务了。
我个人觉得，现在这个环境，开源用起来方便，但风险也越来越多，早点搭好自己的合规审查机制，不是多余的事，是真的在给你自己的项目上保险。
你花不了多少功夫就能搭起来，真出事的时候能帮你省几十万甚至上百万的赔偿，这笔买卖怎么算都划算。
好多人总说合规麻烦，可是你想想，你辛辛苦苦做了大半年的项目，因为一个不小心的侵权就没了，那才是真的麻烦。早点把机制建起来，用得也安心，你说对吧？
