2019云计算开源产业大会丨辛小秋：开源代码合规性测试方法

辛小秋：前面各位老师都讲了很多关于开源的事情，这里就不重复了，重点讲一下关于开源许可证。

我们认为开源许可证和闭源或商业许可证的原理是一样的，都是一种授权协议，它其实是商业许可证的简化版，只是为了让项目开放传播，就形成这样一个开源许可证。

到昨天为止，开源促进会上公布被它认可的开源许可证有82个，但是其中要求非常繁杂，每个许可证都有自己的特点，要求不一样。

如图，开源许可证分传染性和开放性。如何区分？一个分支，修改代码之后是否允许它再做闭源？如果Yes，进入到右边，如果是No，就进入左边传染性许可证。

常用许可证，包括MIT、BSD、Apache、LGPL等等，这些只是简单我们区分许可证区别的点，后来经过研究，大概有20多项的分别，以后有机会再和大家进行分享。

如图，GPL网站上为了让用户区分GPL系列，包括LGPL之间的兼容性，而做了一张表。横坐标是想使用GPL2.0或3.0来做开源项目，纵坐标把以前其他开源项目的代码放到这个项目里，是否和这个项目兼容，就这么一个图。我们想用GPL2.0开源，用GPL3.0代码放进去，是否可以？答案是No，也就是说GPL2.0和3.0本身就是不兼容的。

如图，使用外部链接库放到这个项目里是否被允许。

如图，用一张更简单的图解释一下各种不同的许可证的兼容性。

举例，有一个项目是用GPL2.0开源，里面放了一些MIT/BSD/A Apache 2.0/LGPL2.1等许可证的代码放到GPL2.0里去，是否兼容？用这个图可以一目了然看清楚，LGPL2.1有直接的路径到达GPL2.0，说明这两个许可证是兼容的。BSD/MIT有间接的路径到达GBL2.0，说明这些许可证也是兼容的。Apache 2.0，不管是直接的路径还是间接路径，都不可能到达GPL2.0，就是说GPL2.0和Apache 2.0是不兼容的。用GPL2.0开源之后，原先Apache2.0开源过项目的代码是不允许放到这个项目里来的，这就是许可证的兼容性。

开源带来的风险。

分两类：

1.合规性风险。

又分传染性、兼容性和其他类型风险。所谓合规性风险，总结来说就是当一个用户在使用开源代码或用一个许可证去开源的时候，违反了这个许可证的规定，也就是说不合规的使用造成了这样的风险，就叫合规性风险。造成比较严重的后果是别人要求你停止侵权，产品可能被召回；别人要求你必须开放项目源代码；在你的商业软件里使用GPL2.0，自由软件基金会就有权要求你整个项目代码宣布开源。

在2003年，思科收购了Linksys，它使用底层的驱动是GPL2.0的代码，思科也没有在意这个事情，2003年3月完成了对它的收购，此后一年里经受了自由软件基金会的穷追猛打，告诉他必须要开放路由器的全部代码。最后思科顶不住这种压力，为了自己的声誉，完全开放了路由器产品线，造成了这个产业链上其他竞争对手与它的差距瞬间消失，这对于它来说是一个巨大的损失。

2.安全性风险。

目前美国网站上公布的12万种安全漏洞，2/3来自于开源软件，而且多数开源许可证也不承诺为它自己项目安全性负责，这就是为什么用户引入开源软件的同时会被动引入安全漏洞的原因。

我们国内信通院、发改委这些年一直加强开源工作。

开源治理，工具先行。

开源治理分五个要素：制度、流程、人员、培训、工具。我们认为合适的工具是开源治理的一个前提。我们认为发现问题，尤其是发现存量代码和将来增量代码里开源软件使用轨迹，里面的许可证信息和安全漏洞信息是我们解决问题的前提。

开源代码扫描检测工具的应用场景。

扫描工具里目前有四种应用场景，最重要的应用场景是企业内部代码检测需求，因为企业内部分两种：

1.企业内部有开源的需求，在开源之前，一般的企业都会看一下我们自己需要开源的这部分代码是否有合规性的风险。因为一旦被别人发现这个开放代码里有这样传染性的许可证或者有兼容性的问题，等于把自己的小辫子放给别人，让别人去揪，这是非常危险的。对自己商业闭源的代码，同样对于大公司来说也有规避合规性风险的要求。

2.目前政府部门监管政策造成的，国家项目里对自主知识产权的要求越来越严，以前要求开源的成分不能超过50%，现在不能超过30%，还不能用GPL传染性许可证的要求。还有重点领域，金融领域、航空领域，每年国家都有特殊的文件，要求一些领域加强风险的防控等等。

3.国际合作里，国内公司生产的产品要出口到欧美，对方合作伙伴要求我们出示一个扫描报告，证明你的软件没有这方面合规性或安全性问题，将来一旦出了问题，人家拿这个报告要问责。

4.在企业兼并过程中，一般收购方都要求第三方进行代码评估的审计，这种审议对于收购方是非常重要的，要评估被收购方软件的资产是否有合规性风险，是否大部分都来自于开源等等。

5.目前在司法鉴定当中也同样存在代码审计的需求，因为一旦两个公司因为代码出现知识产权纠纷的话，也要用相应工具做一个设计。

开源代码合规性测试原理。

所有工具原理都是相通的，用户把自己的代码上传到扫描服务器上，扫描服务器进行Hash化，变成Hash值文件，和KB库里的Hash值进行匹配，一旦匹配成果，会把匹配结果返回到服务器上，用户确认之后，然后形成报告。一部分是用户使用所有开源组件的清单，一部分是安全漏洞的列表，第三部分是用户使用这些开源软件的许可证，包括一些其他的数据分析报表。基本上开源代码合规性测试是这样一个原理。

以FOSSID为例。

前一段时间我们给一个客户做的小测试，一个项目里扫了十几个文件，其中12个文件使用了AGPL3.0的许可证。这是金融领域的一个客户，金融领域提供的服务是互联网服务货运服务，在AGPL许可证规定里，如果使用这样的代码来提供云服务的话，理论上要把涉及使用这部分代码相关的项目其他代码都要开源，也就是说一旦用户真正使用了这样的代码去提供服务的话，存在被迫开源合规性风险的。

这个项目还扫描出来CVE（安全漏洞列表），CVE编号，这种CVE可以在美国NVD网站上查看详细信息，也可以在中国的CNNVD网站上查具体描述和补丁的信息。如果用户评估之后觉得自己的应用场景和上面描述的场景一致，用户可以做补丁的修复或安全加固的工作。

代码安全以及信息安全。

1.希望用户不能因为使用这个工具来增加新的风险，也就是说用户在安装、注册、扫描、报告、升级整个全过程中，一定要做到完全离线，因为一旦使用互联网做这个事情，就有可能造成自身代码或者自身其他信息的泄露问题。

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!