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

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功能，这两个学生写的代码完全不一样，这样写出来的话，和原来代码可能就不是一种代码。

合规性风险的预防。

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

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

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

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