开源项目中的禁忌：哪些红线绝对不能触碰？

开源协议是开源世界里的根基。根据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会更好。在满足兼容性的前提下，是可以根据商业目的来修改许可证的。因为许可证是一个合同，当你觉得这份合同不满足你的商业需求时，也可以自己写这个合同，或委托外部律师来写。

如何严防掉进开源的陷阱？

唐小引：前段时间，color.js作者删库跑路被GitHub封号的事件，以及node-ipc作者以反战之名往开源代码里投毒事件都引发了大家的热议。那么各位对“删库”、“投毒”此类事件怎么看呢？

庄表伟：首先无论是“删库”还是“投毒”，在社区里都是非常恶劣的行为，但是目前现在好像还没有特定的法律去制约它，除非“删库”或“投毒”真正造成了人员或者是经济的损失，那么就可以直接去起诉，但在此之前确实拿他没办法。

我们能够看到的例子通常停留在谴责层面，如删库开发者被GitHub封号。node-ipc作者的账号到目前为止尽管还没有被封，但是他私生活已被全部曝光。原因就在于他激起了众怒，使得他在整个社交网络和开源圈子里“社会性死亡”，这是非常可悲的一件事情，虽然在现实生活中大家没办法拿他怎么样，但是在社交网络里面他已经无地自容了。

郭 炜：大部分的开源Licence中都有一条免责条款，即：使用该代码如果造成了任何损失，跟开源原作者没关系。因此从法律上来讲，我们没有办法对这个作者追责。从道德层面，这个作者肯定是不对的。使用者应当如何避免出现这种问题，我还是提倡用基金会的顶级项目，或者找贡献者较多的、且有知名贡献者参与的项目，最好它的项目运行时间也比较长。谨慎选择少数一两人控制的项目，那是具有较大风险的。如果你懒得做功课，可以直接找基金会项目，但如果你有一些鉴别能力，就要仔细去研究项目贡献者的背景。

邓 超：“投毒”行为可能需要负刑事责任，因其可能存在非法获取个人信息，或是破坏计算机系统罪。目前，可能公安系统在开源领域还涉足不深，但是随着公安技术侦查科的逐渐强大，我觉得这是有判定其需负刑事责任的可能的。尽管现在虽然没有类似的案子，但如果将来有影响比较大的事件发生，还是有承担刑事责任的风险的。

郭 炜：我想请教邓律师一个问题，因为开源Licence当中有免责条款来保护作者，那么以之前特别火的Log4j的漏洞为例，这个漏洞并非有人故意为之，但假设其造成了某家公司被攻击，从而产生了巨大损失，倘若这个开源软件的作者也是中国人，那么会因为在Licence里面有保护条款而免责吗？

邓 超：开源Licence当中的免责条款只是一个民法上的概念。作为一个合同，它只对于相对人，即作者和使用者有约束力，与其他人无关。可一旦该行为危害社会造成严重损失则可能涉及刑法犯罪，那么合同里的约定则不能在刑法上构成免责。但是刑法需满足主客观一致的条件。比如“走私”毒品则需要本人具有“走私”毒品的意愿。倘若是我在飞机上被别人把毒品塞到我的包里，本人根本不知情，哪怕客观上是由我走私的毒品，在刑法上也不能追责。所以说该漏洞如果不是作者本意，就只是一个Bug，即使造成严重损失，也没有刑法上的责任。

唐小引：当面对这些开源红线的时候，有什么建议可以给到开发者们？

庄表伟：我原来看过一本书是讲开发者社区的成长历程，这本书在讲到早期的开源社区中有很多开源的爱好者，在开源协议萌芽之初就开始去研究法律条款，于是发现程序思维和法律思维有非常类似的地方。

因此，我非常建议程序逻辑思维很强的开发者们也去学习一下法律知识，法律不仅有趣还对大家的工作很有帮助。

郭 炜：开源不等于免费，在使用过程中一定看清楚开源的License。如果属于“小白”的开发者，建议去找基金会的项目上手是比较稳妥的。如果是比较专业的开发者，建议去看清楚软件每一个目录下的License，这样才知道应当如何使用这个软件。

开源人才观

唐小引：中国开源发展的背后需要各种角色。在今天的开源世界中，需要什么样的人才？大家对开源人才有什么样的建议？

庄表伟：一方面，我认为任何方面的知识都可以活学活用到开源中来，比如我最近在研究社会学、人类学、经济学、法学等等，这些都可以用在开源里，开源需要各个方面的人才。

另外一方面，开放式协作是开源的精髓。当你用开放式的方式来协作时，通常比封闭式协作或者是单干要做得更好。开放式协作是可以在任何一个领域去协作的，在这过程中一定会产生很多的可能性并带来很多收获。

郭 炜：中国有特别优秀、勤奋的开发者做了各种各样的创新和迭代，我觉得这是中国开源的优势所在。不过，在开源领域我们目前仍然也有比较匮乏的人才：

• 第一类是能找到痛点的项目Leader。现在的开源人才太过偏向技术，而开源项目背后的产品想法和需求点才是开源项目的灵魂。然而，能够既懂技术、具备产品思维，还能够有领导力的项目Leader是最缺的一类人才。

• 第二类是布道师。当开源软件已经开发出来后怎样更好地被推广起来，则需要一个理解产品本身还能够讲出这个产品的优点，最后还能够组织好社区的人才，即布道师。

• 第三类是产品人才。目前的开源圈中缺很多具有产品思维的人。目前的开源社区主要以技术论英雄，而产品人才就不太会被开源社区所认可，因而这一类人也比较缺乏，我们也应当注意起来。

邓 超：我认为还需要一些国际化的人才，从而帮助中国在国际上建立开源的影响力。

以上就是本期《开源圆桌派》的全部内容，看了各位专家的讨论，相信各位也能意识到开源治理已经到了刻不容缓的时刻。了解开源协议的法律边界既能帮助开源贡献者捍卫自己的权利，同时也能让开源使用者意识到需要遵循协议下义务的必要性。只有明确好了边界，开源生态才会朝健康、阳光的方向前进。

回放链接详见：https://live.csdn.net/room/csdnnews/oj9jFoKJ

成就一亿技术人