删库跑路、“投毒”、改协议，开源有哪几大红线千万不能踩？( 三 ) 作者|彭慧中责编|屠敏出品|C

唐小引：邓律师是否了解木兰宽松协议，是不是能说一下它在国内的法律效力以及和其他协议有何区别？
邓超：木兰许可证和其他的开源许可证本质上没有什么不同，但是木兰许可证的意义在于它是一个中文的Licence 。
现在主流的基金会都以美国人为主。咱们程序员和法律人士在理解国外的许可时，首先会面临语言门槛。而许可协议不仅仅是个法律文件，还有很多技术性的内容，也会造成法律相关人员的理解障碍。而木兰协议作为中文的许可证，在国内更便于理解和推广。
唐小引：关于云服务的相关许可协议的争议，如SSPL为什么不被OSI认可？
郭炜：SSPL虽然允许免费随意地使用及修改产品源代码，但有一个基本要求：即如果用户基于SSPL协议下的代码做了云服务并且对外提供，则必须同时公开发布任何修改以及自己管理层的源代码。而它没有被OSI认可，是因为OSI有10个准则，其中有1条是不能歧视某类用户，因为这种情况就相当于他歧视了用开源软件而去做云服务的这拨人，所以造成了它没有被OSI认可，但这也存在争议。
邓超：其实从合同上来讲，国内对云服务下的协议也有一些误解，我个人观点是：云服务相关协议并不是一个许可协议。
譬如， GPL的触发条件是要分发代码，例如本地下载一个目标代码，或者在GitHub上拿源代码时才会触发条件，而合法使用这些代码的条件就是要获得权利人的许可。
但在云服务的语境下，它并不是一个许可你获取代码的协议。在云服务中，比如我们访问网页版的爱奇艺时，几乎所有代码的运行都在云端完成，用户并没有获得源代码，因而就不存在这种许可。用户付费获得的权利仅仅是一个访问或者接入这个服务的权利，它本质上不是一个许可，而是一个网络服务协议或者网络服务合同，就像爱奇艺的VIP会员似的。
所以说从法律性质来讲，它和传统的许可协议是两类，当然现在业内也经常说是云服务许可，但是法律上来讲它不是一个许可。
郭炜：现在国内云服务商其实不太在协议上出问题，但有一些经常打擦边球的现象。例如在ApacheLicence协议里，规定Apache这个软件名字是归属Apache基金会的，因此， Apache相关的名称是不能用于商业行为的。而云厂商对这块好像都不太在意，于是出现一些“蹭名字”、“蹭流量”的行为，这是有问题的。
唐小引：说到改名，让我想到最初Java名声很大，后来JavaScript的出现就有蹭名字的嫌疑。在技术圈改名蹭流量不是今天才有的，那么什么样的情况下是该遭到道德和法律的谴责的呢？
郭炜：名字使用问题可以回到开源协议本身。有的开源协议允许用类似名字的，如MIT协议。因此即使使用同样名字也没有问题。但像Apache协议不允许你使用它的名字，所以再去蹭该名字的流量就会有问题，这个是跟协议本身相关，而不是说所有蹭名字的行为都有问题。
唐小引：有用户提到，自己的软件公司用了一些依赖包，这些依赖包中部分是Apache协议的，部分是MIT的，部分是BSD的，还有部分是LGPL的，那么他的开源项目该如何选择许可证呢？
郭炜：按照我刚刚展示的图，开源协议的严格程度是逐级递增的，并且存在“向下兼容”的现象。例如他所提到的这四种协议，从宽松到严格分别为MIT、BSD、Apache、LGPL 。
因此，如果同时存在几种协议时，一般只能用这其中最严格的协议。比如说上述开源软件使用的最严格的协议是LGPL协议，那么你的软件也应使用LGPL协议。如果基于该软件修改了代码，就得遵循并使用LGPL协议开源出来。但如果只使用了它的类库，没有修改代码，那么就没有触发LGPL生效的条件，因此可以不开源，同时，你使用的协议可以选择更宽松一层的Apache协议。但值得注意的是Apache协议要求必须放置版权说明。