【摘要】本文介绍了开源软件在我国发展应用的现状，分析了开源软件知识产权风险领域现有检测技术的不足，提出开源软件多层级知识产权风险溯源检测技术。通过对3类典型的基础软件开展检测分析，总结常见的开源软件不规范使用行为和知识产权风险类型，并从国家层面、行业层面、企业层面出发，提出风险应对建议。
【关键词】开源软件知识产权风险
1引言
近年来，随着网络强国、数字中国战略部署深入推进，国家层面持续加强开源领域顶层设计，高度重视开源软件发展。《中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标纲要》明确提出，“支持数字技术开源社区等创新联合体发展，完善开源知识产权和法律体系，鼓励企业开放软件源代码、硬件设计和应用服务”。在国家政策的大力支持下，行业层面和企业层面也积极拥抱开源、使用开源。近年来，笔者参与了多款国内软件的检测分析，范围覆盖操作系统、数据库、浏览器、基本输入输出系统（BIOS）等产品类型。通过数据分析发现，开源软件已成为国内软件开发的重要技术路线。在操作系统、数据库、浏览器3类基础软件产品中，采用开源技术路线的产品数量占被测产品总量的89%。
国内软件企业广泛使用开源，也同步回馈开源，并致力于共建国内外开源软件生态，已取得显著成效。根据《2021Github年度报告》显示，Github平台上我国开源开发者人数已达755万人，成为仅次于美国的第二大开发者群体。国内首个开源基金会开放原子基金会、最大的开源代码托管平台Gitee、首个获得国际开放源代码促进会（OpenSourceInitiative，OSI）认可的本土开源许可证木兰许可证等应运而生，并已得到广泛应用。目前，Gitee上的注册用户数已超过800万人，代码仓库数量已超过2000万个。OpenEuler、OpenHarmony、OpenGauss、OceanBase等国内软件开源项目及开放社区也呈现蓬勃发展态势。
2开源软件典型知识产权权利要求形式
一般来说，开源软件的生产模式是，开源贡献者发起并完成初始开发，将其贡献至开源社区、捐赠至开源基金会或托管至开源平台后，由多个开发者采用开放式、分布式的开发模式，参与实现软件版本迭代演进。开源使用者可通过互联网下载开源项目，在此基础上研发软件产品，如图1所示。开源使用者开发某软件版本V1.0中，使用了众多开源贡献者资源，包括原始开源贡献者贡献的初始版本V1.0，以及开源贡献者A、B、C、D、E等贡献的代码。
图1开源软件常见开发模式
一般来说，开源软件从开源许可证要求、开源社区/开源基金会/代码托管平台管理及政策、法律法规规定等多个方面出发，对其自身的使用、发布、复制和演绎等过程的知识产权使用权利要求进行规定。以开源Linux操作系统为例，该软件典型的知识产权使用权利规定如下。
2.1开源许可证要求
图2某桌面操作系统代码中开源许可证使用情况
通过研究分析许可证条款发现，图2中列举的7种开源许可证赋予开源使用者不同的权利和义务，如表1所示。
表1开源许可证典型知识产权权利规定
2.2社区及平台级管理及政策要求
2.3知识产权类法律法规规定
近年来，国内外开源法律诉讼案件显示，开源软件明确受知识产权法律法规保护，主要包括以下方面。
（3）开源软件所涉的技术构思、操作方法等属于专利法保护的对象，开源软件所涉及的专利权一般属于开源贡献者或第三方。
3开源软件多层级知识产权风险溯源检测技术
为了避免因使用开源软件产生知识产权中断、诉讼、侵权等风险，业界研发推出多款检测工具，如BlackDuck、FOSSID、FOSSA、FOSSology、LincenseFinder、WhiteSource等，此类工具能够支持对常见编程语言软件代码开展如代码同源性扫描、许可证探测、代码质量审核等工作，帮助开发者准确且高效实现代码开源成分分析、许可证识别、代码质量控制。但是，此类工具主要针对被测软件代码本身开展代码扫描、开源许可证的识别及合规检查，较少考虑开源软件知识产权权利要素，对于多种开源许可证知识产权权利要求冲突等问题尚未开展有效检测，缺少更细粒度的开源软件知识产权检测及风险识别手段。
如图3所示，依赖开源项目开展研发的项目C为被测对象，其由C1及C2共同组成，C1与C2之间存在调用关系，项目C源代码为闭源状态。
图3开源软件许可证使用情况
利用现有工具对项目C开展检测，大多数工具输出的检测结果包括以下几个方面：C1与开源项目A中的A1具有同源关系；C2与开源项目B中的B1具有同源关系；C1无开源许可证；C2无开源许可证；A1采用GPL2.0开源许可证；B1采用AGPL3.0开源许可证。
但是下列3类问题，大部分现有工具无法做到有效识别。
问题1：C1与A1具有同源关系，按照A1中GPL2.0许可证要求，C1应与A1许可证一致，但C1显示无开源许可证，存在删除GPL2.0许可证的情况。同理，C2与B1具有同源关系，C2显示无开源许可证，存在删除AGPL3.0许可证的情况。大部分现有工具能识别C1与A1、C2与B1的同源关系，但不对C1、C2删除许可证问题进行提示。
问题2：如果C1和C2严格按照文件A1和B1中的许可证要求，则由于GPL2.0许可证要求与AGPL3.0许可证要求存在不兼容问题，C1和C2共同组成C时，将产生许可证冲突问题。大部分现有工具未将许可证冲突纳入检测范围，不对其进行提示。
问题3：如果C1和C2严格按照文件A1和B1中的许可证要求，则按照GPL2.0开源许可证要求和“传染性”特性，在某些特定情况下，待测项目C将被视为衍生代码且需要开源。大部分现有工具对使用开源但衍生产品闭源的情况不作风险提示。
上述3类问题均由待测项目C的同源项目引入，实际工作中需要对项目C开展全面的溯源风险分析，最大程度上定位其面临的知识产权风险。
基于此类情况，笔者研究提出开源软件多层级知识产权风险溯源检测技术，对开源许可证要求、开源社区/开源基金会/代码托管平台管理及政策要求、法律法规规定提取信息，并进行信息规范化及标准化，以此构建开源软件知识产权权利要求知识库，通过代码同源性比对分析，建立开源软件溯源关系，检测待测项目自身知识产权风险，以及由同源项目传递至待测项目的知识产权风险，检测技术框架如图4所示。
图4开源软件多层级知识产权风险溯源检测技术框架
基于开源软件多层级知识产权风险溯源检测技术，对3类软件（包括操作系统、数据库、浏览器）开展了检测，发现以下4类典型风险。
二是违反开源许可证要求，将开源软件衍生代码闭源分发、商业化；
三是多个开源项目不规范组合，产生开源许可证冲突，如表2所示；
四是特定情况下，使用开源软件可能侵犯开源贡献者或第三方专利权。
表2数据库产品使用的开源项目许可证冲突
4开源软件风险防范及应对建议
建议从以下3个方面出发，全面深入防范开源软件知识产权风险，引导我国软件产业高质量发展。
4.1国家层面，实施开源激励政策，建设本土开源生态
4.2行业层面，高效协同形成合力，推动开源良性发展
从行业层面，建立高效协同的开源产业联盟，科学统筹、集中力量、形成合力，共同打造统一、具有一定规模的本土开源社区、开源代码托管平台等开源基础设施，解决传统开源领域组织分散、各为一方、社区散乱弱小等问题。进一步丰富建设我国开源行业标准和规范，继续研究制定受国际认可、具有国际影响力的本土开源许可证，加强行业开源理念、法律法规、开源合规等的科普和培训宣贯，为我国开源生态提供有力的知识产权、法律支撑，引导中国软件开发者正确使用开源软件，有效防范开源软件知识产权风险，推动开源良性发展。
4.3企业层面，加强自主研发能力，规范使用开源软件
5结语
本文通过笔者在实际业务工作中掌握的开源软件应用现状，分析开源软件典型知识产权权利要求，通过提出一种新型的开源软件多层级知识产权风险溯源检测技术，对开源软件使用常见的知识产权风险进行了分析总结，并给出风险防范和应对建议。政产学研用各方应该把握开源软件发展趋势，聚焦我国软件产业在开源应用过程中面临的突出问题，加强顶层设计和统筹规划，推动国产自主软件开源生态建设及良性发展。