删库跑路、“投毒”、改协议,开源有哪几大红线千万不能踩?
作者 | 彭慧中 责编 | 屠敏
出品 | CSDN(ID :CSDNnews)
开源协议是改协开源世界里的根基。根据CSDN《2021-2022 中国开发者调查报告》数据显示,议开源尽管目前已有94%的大红开发者使用开源软件 ,但近30%开发者并不了解开源协议,线千60%对于主流开源协议MIT、投毒GPL与Apache开源协议的删库区别并不清楚 。
随着开源近些年来急速发展 ,大红国内外开源违规事件也层出不穷:color.js作者删库跑路;node-ipc的线千作者以反战之名往代码里投毒;作为我国首个明确GPL3.0协议法律效力的“罗盒风灵案”,风灵公司被谴责不尊重开源规则.....种种案件均让我们愈发感受到加速推动开源合法合规的投毒形势严峻 。开源软件在追求“自由”的同时 ,不能牺牲开源工作者的利益 ,否则将会影响他们的创造激情 。
那么,开源协议的法律边界究竟在哪 ,如何避免踩雷 ?面对市面上层出不穷的开源协议开源开发者应当如何选择 ?企业使用开源软件合规风险如何规避?
本期CSDN重磅打造开源直播栏目《开源圆桌派》以“改协议、删库 、投毒 ,开源有哪几大红线千万不能踩?”为主题 ,邀请到了开源社2021理事长庄表伟、ASF Member, Apache 孵化器导师郭炜 、资深知识产权律师邓超,在CSDN《新程序员》执行总编唐小引的主持之下,带大家了解开源的红线究竟在哪 ,以及应当如何规避开源风险。
眼花缭乱的开源协议从何下手?
唐小引:目前市面上主流开源协议有哪些 ,有什么样的特点?
郭 炜 :对于哪些是真的开源协议 ,近期也有很多争议,特别是美国法院判决“未获OSI(开放源代码促进会,Open Source Initiative,简称 OSI )许可的开源是「假开源」”一事引发了热议。但通常意义上来讲,主流开源协议一般都经过OSI认可 。
主流的开源协议包括 :GPL、BSD 、MIT、Apache License等,协议中有几个重要的要素 :
第一是开源时需要负哪些责任;
第二是涉及二次传播时是否也必须开源,以及应该用什么样的名字去开源?
目前 ,我们中国的木兰宽松许可证也是被OSI认可的 ,因此,大家可以在OSI标准的网站上去选择与自己相关的开源协议。
邓 超:从法律的角度 ,中文的“开源”和英文的“Open Source”是一个公用词汇,谁都可以用,不能被任何人所垄断 。而只有OSI认证的 ,才可拥有OSI的商标。OSI可以列出10个标准 ,并按标准认证一些许可证,大家可以说这些许可证是OSI认证的 ,但是OSI不能垄断“开源”这个词 。因为“开源”就像“可乐”一词一样 ,谁都可以使用,只有涉及“可口可乐”时才算是用了其商标。
我个人不认为“开源”和“OSI”能够画等号,如果大家都认为只有OSI认证的协议才能叫开源 ,事实上相当于把“开源”这个词专有化了。
唐小引 :主流的开源协议有哪些区别,以及在使用这些License时,有哪些注意事项?
郭 炜 :这是我画的一个图 ,对常见的许可进行了分类,主要从两个维度进行切入 :一是从修改代码是否遵循开源的角度;二是使用服务是否遵循开源的角度。
从这两个角度看 ,不同的协议要求各不相同 。
总体来说 ,开源协议众多,但在选用时可以根据自身的目的来考虑。如果开发者要想实现商业化 ,那么可以选择在右侧的BSD 、MIT、Apache等协议,你可以基于这些开源软件做自己的商业软件,而不需要把你的商业软件再次开源出来。但值得注意的是,像Apache协议,是需要在修改前放置版权说明的。例如之前某大厂用了Apache Sky Walking ,并未说明使用了Apache协议,结果就被警告了。
如果开发者仅仅作为用户去使用开源软件,那么用左边的GPL等协议就好,比如说最典型的MySQL就是GPL协议的。基于MySQL把它打包在自己公司内部可以随便使用,但是你如果要把它打包成一个商业软件就必须也得开源出来。
邓 超:关于注意事项,我认为 :首先,大家需要有版权意识 。使用任何不是自己创作的内容,都要得到许可 。
譬如为什么大家可以免费且合法下载微信呢?是因为用户在下载时 ,在用户协议中点了一个“我同意” ,这就是大家最熟悉也是最陌生的合同。尽管大家每天都在签署这份合同 ,但是没有人看具体的合同内容 。实际上,点击“我同意”就是签署了一个知识产权授权条款 ,腾讯允许用户保留微信程序副本的前提是需要用户同意协议中的条款。
类比到源代码中,我们需要遵守的就是License。因此在认识上,我们应该高度重视,对于基本的这些常见许可协议应当有所了解 。
开源协议“红线”大盘点
唐小引:开源许可协议具有什么样的法律效应 ?
邓 超:尽管中国没有专门针对开源方面的法律,但是开源并不是法外之地,从软件知识产权的角度 ,都是有法可依的 。合同法、民法典都能覆盖到 。大陆法系下,开源许可证和普通软件的用户许可协议、服务协议本质上就是一个合同 ,只不过它是一种制式的 ,一种标准化的不可磋商的合同。如果你接受这份合同,就可以遵照合同要求使用,如果不接受 ,就不能使用。
郭 炜 :说到遵守协议 ,我觉得其实蛮危险的 。中国现在有多少公司将MySQL打包成自己软件里的一部分在销售 ,这似乎非常普遍,如果Oracle想要追究 ,肯定一抓一个准儿。按照协议来讲 ,如果你没有购买Oracle的License,是不能把MySQL打包成商业软件的一部分进行销售的 ,但是中国很多企业都是这么做的,他们或许根本没有了解到License的威力在哪 ,我觉得大家要逐步认识起来。
唐小引:有开发者提问,公司内网使用MySQL有什么样的规范呢?
郭 炜:公司内网用MySQL是没问题的 ,但不能将它打包成公司软件的其中一部分,并进行对外销售。
唐小引 :在公司内部开发自用时使用社区版的开源软件是合法的吗?
郭 炜:用社区版的开源软件时需要小心 ,要看清楚该社区开源软件具体使用的Licence是什么 ,仔细甄别软件各部分的来源 。
比如有一些软件,表面上使用的是Apache Licence,但它里面却用了GPL的软件包 ,所以造成这个项目并不是单纯的在Apache Licence之下 。而没注意到这些的软件作者和使用者 ,可能都没有意识到需要履行GPL协议下的义务 。所以我个人更推荐大家使用各种开源基金会下的项目 ,其实为了保证大家在使用Licence的时候比较放心 ,开源基金会下的项目是经过筛选的 ,有许多“大拿们”替小白们把关过的 。
庄表伟 :我想给企业管理者们说一个道理:绝大多数未经培训 、也不了解开源的License和开源相关的法律问题的程序员,他们为了完成自己的工作,可能会在网上随便找对应的软件包和组件,随手修改后便投入使用。一开始可能这个项目只是公司内自用。后期可能有商业化的需求后,这代码就被打包后拿去销售了。于是这当中存在非常多不知不觉的事情 ,造成了安全隐患 。
那么从企业的管理者来说 ,首先要教育自己的开发人员,日常工作中要注意开源相关的法律问题 。当然不仅仅是教育他们,还得在公司内建立开源治理的机制 ,而不是等到软件成为商品后才亡羊补牢 。在这个过程当中,企业需要付出成本,但很多企业之所以大力地拥抱开源,恰恰是因为觉得开源是零成本的 。他们没想过 ,无论是使用、修改、再分发 ,都可能会带来安全风险和法律风险,为了规避风险 ,就必须付出成本 。
唐小引 :邓律师是否了解木兰宽松协议,是不是能说一下它在国内的法律效力以及和其他协议有何区别?
邓 超 :木兰许可证和其他的开源许可证本质上没有什么不同,但是木兰许可证的意义在于它是一个中文的Licence。
现在主流的基金会都以美国人为主。咱们程序员和法律人士在理解国外的许可时,首先会面临语言门槛。而许可协议不仅仅是个法律文件,还有很多技术性的内容,也会造成法律相关人员的理解障碍 。而木兰协议作为中文的许可证,在国内更便于理解和推广。
唐小引:关于云服务的相关许可协议的争议 ,如SSPL为什么不被OSI认可 ?
郭 炜 :SSPL虽然允许免费随意地使用及修改产品源代码,但有一个基本要求 :即如果用户基于SSPL协议下的代码做了云服务并且对外提供,则必须同时公开发布任何修改以及自己管理层的源代码 。而它没有被OSI认可,是因为OSI有10个准则,其中有1条是不能歧视某类用户,因为这种情况就相当于他歧视了用开源软件而去做云服务的这拨人,所以造成了它没有被OSI认可,但这也存在争议。
邓 超:其实从合同上来讲,国内对云服务下的协议也有一些误解,我个人观点是 :云服务相关协议并不是一个许可协议。
譬如,GPL的触发条件是要分发代码,例如本地下载一个目标代码,或者在GitHub上拿源代码时才会触发条件 ,而合法使用这些代码的条件就是要获得权利人的许可。
但在云服务的语境下,它并不是一个许可你获取代码的协议 。在云服务中,比如我们访问网页版的爱奇艺时,几乎所有代码的运行都在云端完成 ,用户并没有获得源代码,因而就不存在这种许可。用户付费获得的权利仅仅是一个访问或者接入这个服务的权利 ,它本质上不是一个许可,而是一个网络服务协议或者网络服务合同,就像爱奇艺的VIP会员似的。
所以说从法律性质来讲,它和传统的许可协议是两类 ,当然现在业内也经常说是云服务许可,但是法律上来讲它不是一个许可 。
郭 炜 :现在国内云服务商其实不太在协议上出问题,但有一些经常打擦边球的现象。例如在Apache Licence协议里 ,规定Apache这个软件名字是归属Apache基金会的 ,因此 ,Apache相关的名称是不能用于商业行为的 。而云厂商对这块好像都不太在意 ,于是出现一些“蹭名字”、“蹭流量”的行为,这是有问题的。
唐小引 :说到改名,让我想到最初Java名声很大 ,后来JavaScript的出现就有蹭名字的嫌疑 。在技术圈改名蹭流量不是今天才有的 ,那么什么样的情况下是该遭到道德和法律的谴责的呢?
郭 炜:名字使用问题可以回到开源协议本身。有的开源协议允许用类似名字的 ,如MIT协议。因此即使使用同样名字也没有问题 。但像Apache协议不允许你使用它的名字 ,所以再去蹭该名字的流量就会有问题,这个是跟协议本身相关,而不是说所有蹭名字的行为都有问题 。
唐小引 :有用户提到 ,自己的软件公司用了一些依赖包,这些依赖包中部分是Apache协议的,部分是MIT的 ,部分是BSD的,还有部分是LGPL的 ,那么他的开源项目该如何选择许可证呢?
郭 炜:按照我刚刚展示的图 ,开源协议的严格程度是逐级递增的 ,并且存在“向下兼容”的现象 。例如他所提到的这四种协议 ,从宽松到严格分别为MIT 、BSD、Apache 、LGPL。
因此,如果同时存在几种协议时,一般只能用这其中最严格的协议。比如说上述开源软件使用的最严格的协议是LGPL协议,那么你的软件也应使用LGPL协议。如果基于该软件修改了代码 ,就得遵循并使用LGPL协议开源出来 。但如果只使用了它的类库 ,没有修改代码 ,那么就没有触发LGPL生效的条件,因此可以不开源 ,同时 ,你使用的协议可以选择更宽松一层的Apache协议。但值得注意的是Apache协议要求必须放置版权说明 。
邓 超:一方面,正如郭大侠所说 ,开源软件同时在严的协议和宽松的协议下,肯定得以严的协议要求为准 。
另外一方面 ,在符合要求之外 ,具体选择什么样的许可证还是要具体分析的。比如说一些内核性的软件 ,可能选GPL会好一些,例如像Linux内核。但是如果是业务端的软件或者库可能选LGPL会更好。在满足兼容性的前提下 ,是可以根据商业目的来修改许可证的。因为许可证是一个合同,当你觉得这份合同不满足你的商业需求时,也可以自己写这个合同,或委托外部律师来写。