内蒙古电力（集团）有限责任公司信息通信分公司 汪 啸 额尔敦 王 博 尹梦宾

1 开源软件及其应用

1.1 开源软件基本概念

开源软件。一种版权持有人向公众公开软件源代码，并允许公众下载、编译。在许可证授权范围内，可进行修改、调用、分发等。

开源许可证。源代码版权所有人与被授权人就源代码使用达成的协议。因源代码已经面向公众公开，故协议以要约方式存在。即潜在被授权人在取得源代码时默认接受，在对代码行使约定权利时同时遵守约定义务。在工程实践中，源代码用户在下载、编译、使用软件时，默认接受开源许可证规定的全部条款。

1.2 应用开源软件的必要性

使用开源软件可降低软件研发成本。随着“云、大、物、移、智、链”技术发展，“产业+互联网”模式逐步落地，大量的业务需求驱动软件研发提质增效。原有“成套软件”模式适用于业务、用量相对固定（或可预测）的场景。在产业互联网化的背景下，继续采取“成套软件”进行定制化开发以满足业务需求，存在开发周期长、变更周期长、二次开发困难、开发成本高等问题。随着开源软件生态不断成熟，依托开源软件平台进行开发，引入开源代码，降低开发工作量，可有效应对上述问题。

提高软件行业“核高基”方面的自主可控能力。我国软件行业起步较发达国家晚，软件产业生态和自主可控能力存在一定不足。特别是在核心平台软件、高科技装备支撑软件、基础科研软件等方面对国外技术存在一定依赖。因国外企业在软件研发方面有长期的行业经验积累和开发技术储备，在短时间内进行“直道超车”可能性较低。在本行业内广泛应用开源软件的背景下，依托开源代码基础进行二次开发，有利于实现“弯道超车”。

1.3 应用开源软件的形式

代码级应用。在进行软件开发时，开发人员将开源代码以函数、实例、库等等形式复制到自己的工作成果中，形成隐含代码式引用。

软件级应用。在进行软件集成时，实施人员将开源软件整体进行封装，作为二次开发基础或者应用系统关键部件，形成成套引用。

系统级应用。在进行系统构建时，实施人员将社区版/商用版开源系统直接部署到生产环境，整体使用，形成系统级应用。

工具级应用。在进行软件开发、集成、系统构建等工作时，将开源软件作为开发平台、管理平台、技术工具、办公软件等，独立使用。

2 开源软件风险分析

2.1 开源软件风险概述

开源软件相较于传统商业化软件，在成本方面有显著优势。对软件二次开发难度较小，有效提升了系统灵活性。由于开源软件使用广泛，其生态较为完善，运维市场较为成熟，有利于开源软件应用。从风险管控角度来看，存在不同程度的知识产权问题、技术出口管控问题、质量与安全问题，且需要得到重视。

2.2 不当引用或引用不当

以BSD许可证为例。BSD许可证要求，当软件源代码持有人对所获得的BSD授权软件源代码进行修改，修改后的作品再分发时，按照BSD许可约定作出版权声明。声明中包括对其获得的BSD授权原创软件作品(源代码)的版权(所有权)内容。这就要求软件的二次及以上开发作者要区分各版本软件的初始代码及增量代码所涉及的许可证，按照BSD许可要求进行引用说明。

在软件开发过程中，源代码来源多样情况普遍存在，易导致引用不规范的情况出现。

2.3 授权传染或强制开源

以GPL许可证为例。GPL许可证要求，承认软件作品作者的著作权(所有权)，软件的二次及以上开发者必须允许其他人享有对其作品使用、修改、发行等权利。同时GPL许可证要求用户（含二次及以上开发者）不能改变软件的授权协议，即二次及以上修改版本再发行时，仍然按照GPL许可授权。由此可见，当源代码作为整体发行时，是基于GPL协议完全开源的，不会出现闭源情况。此外，GPL许可证为唯一许可授权，不接受混合授权，即无法通过其他许可证形式发布。

在软件开发、部署、使用的过程中，不可避免使用GPL授权软件产品。如对这些产品进行二次及以上开发，易导致授权传染或强制开源的情况出现。例如：1授权传染。使用了GPL许可证授权的软件，根据现场情况对源代码进行修改，则修改后的软件则为GPL授权软件，遵循GPL授权原则。无法闭源。2强制开源。修改后的软件按照GPL授权约定，需要对公众发布。

2.4 专利防御或专利诱饵

各个开源许可证对修改源代码后是否闭源、新增源代码是否遵循相同的许可证、修改源代码后是否要提供说明文档等有较为详细的规定，开源许可证对软件中涉及的专利使用与授权的约定相对模糊。针对专利权使用与授权，有的开源许可证明确规定，有的并不涉及。

在软件开发过程中，可能使用已经注册专利的算法或代码，涉及到专利运用问题。如对这些程序进行二次及以上开发，易导致不当使用专利的情况出现。例如：1专利防御。APSL-2.0规定了终止条款“如果获取者开始对A公司提起专利侵权诉讼，该许可和权利授予将无需A公司进行通知地自动终止，前提是A公司在该情况中没有首先提起专利侵权诉讼”。APSL-2.0开源协议中设置了条款来保护A公司权益。2专利诱饵。软件作者或二级及以上开发者在源代码中加入收到专利保护的代码或算法，同时依据开源许可证授权细则保留对专利的控制性授权权利，当其他组织或个人使用该软件时，造成侵权事实发生。特别是在广泛应用或应用在核心业务或系统中，造成专利授权费高昂或改造成本巨大的两难局面。

2.5 出口管制或弱自主可控

以当前软件行业生态来看，世界各公司以会员身份加入开源软件基金会并贡献源代码为主流形式，其中大量源代码由注册于A国企业生产并提供，同时颁发Apache、GCC、MIT、BSD、GPL（GNU）/LGPL等授权的组织均在A国注册，且主流开源托管平台（例如Github）服务器也位于A国境内。由此可见，开源软件生产阶段不可避免地受到A国法律管制。在国际关系风云变幻的背景下，出口管制问题易发、多发。A国利用产业上游阶段技术优势，通过出口管制手段，制裁过Z、H等公司，以达到相应目的。

虽然开源代码属于外国BIS（商业、工业及安全局）规定的公开发布的范畴，不受外国EAR（出口管理条例）约束。但是涉及加密软件源代码的开源项目仍然需要备案。考虑到释法、修法的主动权在A国，故A国对开源软件进行出口管制风险依然存在。

目前，从软件行业生态体系来看，具备完全且完整自主可控的主流软件软件产品相对缺乏。大部分软件项目均不同程度使用开源代码，故此类项目自主可控能力相对弱化。

2.6 代码质量及安全问题突出

参与开源软件代码开发的主体来源多样，既有个人，也有政府、高校、研究机构等组织，各类型组织对代码质量管控措施不同，导致代码质量不可控因素增多。代码审计工作也存在类似问题，导致代码安全风险不能被有效降低或消除。

软件质量风险或安全风险显现时，受开发主体能力限制，无法在第一时间完成漏洞修复工作，导致漏洞引发的信息系统运行故障和网络安全事故扩大化。对于典型的“0Day漏洞”，高效开发主体提供的补丁修复时间在1天至1周，一般开发主体以月或年为单位完成补丁发布，其他开发主体甚至无法进行修复。在修复前，信息安全体系相对薄弱的单位或个人将无法有效应对。

若代码来源可疑又未经审核，病毒、木马等恶意代码随开源软件进入部署环境情况发生，将导致更为严重的安全问题。

3 主流开源软件实证分析

3.1 泛在基础性软件开源许可证

操作系统。Linux是一种广泛用于服务器的操作系统。使用GNU/GLP许可证，故各种商业版本如Redhat、Fedora、SuSe以及Ubuntu、Slackware、Gentoo、Debian、centos均可以免费下载、使用。基于Linux的商业利益在于服务，而非常用的软件许可证授权。

数据库。Mysql数据库作为分布式架构的核心，使用GPL/GNU许可证。而postgre数据库使用BSD/MIT许可证。故基于Mysql源码修改的版本均遵循GPL许可证，而基于postgre源码修改版本需按照规则引用。

应用中间件。Tomcat是一种开源应用中间件，使用Apache许可证。故基于tomcat源码修改版本需按照规则引用。

分布式负载。Nginx是一种开源分布式负载，使用BSD许可证。故基于BSD源码修改版本需按照规则引用。

云平台软件。OpenStack是一种开源云平台管理软件，使用Apache许可证。故基于OpenStack源码修改版本需按照规则引用。云平台的虚拟化引擎KVM则为GPL许可证。

容器软件。Kubernetes是一种开源容器引擎管理软件。容器引擎Docker使用Apache许可证。

3.2 开源软件运用风险案例

S公司以自主可控为目标，基于Linux、Mysql、Postgre源码开发可用于重要业务的可视化操作系统、关系型数据库。根据上述软件的开源许可证可以推断，除基于postgre源码开发的数据库以外，均受到开源传染影响，需要按照约定公开源码，故其通过隐藏源码确保安全的行为存在法律风险。

Q公司以自主可控为目标，基于Linux源码开发可用于重要业务的可视化操作系统，并将其商业化。根据上述软件的开源许可证可以推断，均受到开源传染影响，需要按照约定公开源码，故其通过隐藏源码确保安全的行为存在法律风险。公开源码后，通过软件授权形式销售存在无法获得收益的风险。

运用开源软件对于降低信息系统建设成本，提高自主可控能力具有积极意义。同时，应认识到开源软件在应用过程中，存在不当引用或引用不当、授权传染或强制开源、专利防御或专利诱饵、出口管制或弱自主可控、代码质量及安全问题等风险。使用单位应开展风险管理工作，进行风险管控。