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

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

到昨天为止，开源促进会上公布被它认可的开源许可证有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.希望用户不能因为使用这个工具来增加新的风险，也就是说用户在安装、注册、扫描、报告、升级整个全过程中，一定要做到完全离线，因为一旦使用互联网做这个事情，就有可能造成自身代码或者自身其他信息的泄露问题。

2.用户扫描一定要提高精确度，因为用户使用开源软件，不但要用整个组件或整个文件，有可能调用的是其中一小段代码，叫做代码片断。当使用代码片断放到我们自己商业代码里时，扫描工具检测或匹配不出来，就造成了误报或漏报，将来有一些风险可能提示不出来，会给我们造成一定的损失。

3.许可证的信息检测一定要详细、完整。因为在国内有很多聪明的企业为了能够实现既不公开代码，又想使用传染性的许可证代码，怎么办？用一些自己的招数来做嵌套，如用MIT嵌套GPL代码做开源，自己商业代码再调用新开源MIT项目拿过来使用，表面上是合规的，但实际上里面是GPL的代码。这种情况下一定要用扫描工具让它大白于天下，把所有风险暴露给客户，让它断了这种念头，因为这是非常危险的。

4.建议用户把扫描的过程从后端移植到前端，也就是说单点扫描变成两端扫描，就是说在研发前沿的部分和扫描工具相结合。研发人员在做最初始开发工作时，如果找到了网上开源代码，那个时候先进行扫描确认是否有合规性风险或者安全性风险，这种时候我们认为对整个研发过程或对整个开源治理过程的成本是最低的，如果在后期发现了，返回来让研发人员修改，成本是很高的。

开源代码合规性风险的应对建议。

合规性风险包括传染性风险、兼容性风险、其他违规风险。

发现最严重的传染性风险之后，怎么应对？如果企业愿意让自己代码回馈社区或再开源的话，不在此范围内。如果企业就想卖这个代码，发现了GPL或发现了其他传染性代码，怎么办？

首先，要确认一下这个许可证使用的代码和应用场景是否匹配，也就是说不同的应用场景的风险是不一样的，如发现了GPL2.0的代码，我们是金融企业，只提供云服务或互联网服务，理论上来讲，GPL2.0对于我们应用场景是没有传染性风险的，所以这种情况是没有问题的。首先提示大家首先看一下应用场景和传染性风险是否匹配。

第二，我们是金融企业，发现AGPL3.0的代码，怎么办？因为同一段代码可能发现这种代码可能被不同的作者用不同的许可证在不同的平台上已经开源过很多次了。举例，同一段代码发现是AGPL3.0，可能在一年以前或三年以前被MIT/BSD其他许可证也被开源过了同样一段代码，如果发现这种情况，这段代码不是来源于AGPL3.0，就是用MIT/BSD，也能够逃脱所谓传染性风险。

前两种情况如果都不具备情况下，必须要做商业代码，必须要发布，这时候GPL2.0代码不可替代，最后只能重写。有很多企业用粗暴的模式，如变量加1-2个0，我们不建议这么做，因为很多工具是可以检测出来的，建议大家采用AB模式进行逻辑的模仿，什么意思？就是把研发人员分成两组，第一组人员来读这个GPL的代码，读完之后把逻辑写清楚，告诉第二组，第二组研发人员再根据你说的逻辑把这个功能实现一遍。相当于一个老师告诉两个学生，用X算法实现X功能，这两个学生写的代码完全不一样，这样写出来的话，和原来代码可能就不是一种代码。

合规性风险的预防。

我们认为预防比治理重要，如何预防？在研发阶段预防是好的。前面搞一个自己内部安全的开源库，研发人员使用这里的代码是最安全的。如果在前端把扫描和研发过程能够融合，也是非常好的选择。这个时候研发人员使用扫描来确认或降低风险，总比后面再发现风险，再去纠错，成本要低很多。

今天要讲的内容就这么多，谢谢大家！