潜精研思 笔耕不辍

出版物/Publications更多分类

地址:北京市东城区建国门内大街26号新闻大厦7-8层

电话:86 10 8800 4488, 6609 0088

传真:86 10 6609 0016

邮编:100005

国枫视角

国枫观察丨开源软件合规:法律风险、IPO监管与具体防控措施

发布时间:2025.08.05 来源: 浏览量:77

开源软件是数字和人工智能时代技术创新的核心资源,开源软件同时是典型的技术与法律相结合的产物。本文在简要介绍开源软件技术发展和商业应用的基础上,结合司法案例和裁判规则,对开源软件法律风险、IPO监管与具体风险防控措施展开分析和讨论。

作者:孟睿、史淑彦


一、引言


开源软件作为全球软件生态的核心组成部分,其使用、修改与分发行为受开源协议的严格规范。在数字和人工智能时代,开源软件更是企业技术创新的核心资源,推动着技术迭代与产业升级。本文结合我国开源软件纠纷司法实践和IPO审核实践,探讨开源软件使用中的主要法律问题、风险边界及防控措施。


二、开源软件与开源协议


开源软件是典型的技术与法律相结合的产物,法律问题的分析和解决不能脱离现实商业应用场景,本文在此简要回顾开源软件相关技术发展和商业应用。


(一)可分离提供的源代码和目标代码


计算机程序包括源程序(源代码)和目标程序(目标代码),同一计算机程序的源程序和目标程序被视为同一作品。[1]源代码是由高级编程语言编写的人类可读的符号化指令序列,例如result=x+y。目标代码是可由计算机等具有信息处理能力的装置执行的代码化指令序列,通常为二进制指令,机器可读但人类不可读,例如0100010101。软件工程师通过编写、修改源代码来开发、维护、完善和改进计算机程序及其功能。源代码经过编译器编译后形成目标代码,并由计算机执行。用户若仅关注软件的功能性使用,只需获得目标代码;若还计划自行修改或扩展软件功能,需获取源代码。


源代码和目标代码作为同一软件的不同表现形式,具有可分离的属性,可分别、独立提供给用户。在向用户或社会公众提供软件时,可基于具体需求,仅提供目标代码,或同时提供源代码和目标代码。


(二)开源软件与闭源软件


根据源代码的公开性,即根据是否向用户和公众提供软件的源代码,可将软件分为开源软件和闭源软件。开源软件,如Linux操作系统、Mozilla Firefox浏览器等,其源代码对公众开放,允许用户自由查看、修改和分发,其强调透明性、协作和共享。闭源软件,如Windows操作系统、iOS操作系统等,不对外公开源代码,用户只能使用目标代码,注重通过商业秘密和知识产权形成市场控制力和竞争力。


(三)开源软件的使用和分发方式


随着技术的发展,开源软件在前沿技术领域,尤其在人工智能、云计算和大数据等领域占据重要地位,其使用和分发方式也灵活多样。


常见的开源软件使用方式包括:


● 直接使用:用户直接功能性使用开源软件,无需修改或二次开发,如使用现成的开源软件作为数据库、中间件、框架等系统组件。


● 二次开发或定制化开发:对开源软件进行修改、扩展或定制化改造,以适应特定业务需求,如修改ECharts图表库以支持自定义样式和交互,或使用OpenCV进行图像识别算法开发。


● 作为研发工具使用:将开源软件作为开发工具的一部分,如使用SonarQube进行代码质量分析,或使用TensorFlow构建、训练和部署各类机器学习模型。


● 产品集成:将开源软件集成、嵌入到企业自创产品中,作为自创产品的一部分进行销售或分发。


软件分发方式是指向用户或公众提供软件的方式,常见的开源软件分发方式包括:


● 在线分发:通过互联网提供下载链接,如GitHub、GitLab等平台。


● 企业内部分发:通过内部网络或企业级工具(如SaaS)进行分发。


● 私有云部署:软件部署在客户机房或第三方托管的私有云中,独享使用。


● 公有云部署:通过第三方云服务商(如阿里云、AWS)提供服务,按需租用。


● 其他部署方式:单机部署、集群部署、自建数据中心和共用数据中心等。


不同的使用和分发方式,会引起不同的权利义务关系。


(四)开源协议及主要内容


开源协议,又称开源软件许可证,是用于规范开源软件使用、修改和分发行为的法律文件,重点在于规范源代码的自由获取、使用、修改、分发。开源协议通常由开源社区或组织制定,而非立法或政府机关制定。据不完全统计,目前已形成一百多个开源协议,不同的开源协议适用于不同的使用和分发场景,形成不同的权利义务关系。开源协议通常包括以下主要内容:


● 授权条款:开源协议均明确授予用户自由复制、使用、修改和分发源代码的权利。


● 许可条件条款:规定用户复制、使用、修改和分发开源软件时必须履行的义务或遵守的条件,包括保留原始版权声明和修改信息;分发时附带协议文本,确保接收者知晓权利义务;禁止在开源协议外附加额外限制;未经允许不得使用开源软件的商标或贡献者名义进行商业推广等。


● 衍生软件及再分发条款:衍生软件是指对开源软件进行修改、二次开发或将开源软件与用户自己开发软件组合、整合或集成后形成的软件。不同开源协议对衍生软件是否如同开源软件本身那样也要开放源代码有不同要求。GPL协议要求衍生软件必须同样开源向用户提供源代码,以确保开源精神的延续性;而MIT协议则无此强制性要求。


● 免责条款:表明开源软件开发者、提供者不对因使用开源软件可能引起的问题承担责任。例如,MIT协议规定,软件以“现状”提供,不附带任何形式的保证,用户因使用该软件而遭受损失的责任完全由用户自行承担。


● 授权终止条款:如果用户在使用开源软件时违反了开源协议设定的任何条款,尤其是许可条件条款、衍生软件及再分发条款,那么该用户根据开源协议获得的自由复制、使用、修改和分发开源软件的授权将自动终止。


开源协议通过以上条款,系统性地构建了开源软件的使用规则与权利义务体系。


三、开源协议的法律性质及法律责任


虽然我国有关开源软件的司法案例还不多,但基于已有案件及其讨论分析,我国司法实践已经形成部分共识。


(一)开源协议构成附解除条件的软件著作权使用许可合同


开源协议不是立法或行政部门制定的法律文件,且授权人与用户之间无传统意义上的协商谈判过程。因此,开源协议能否作为法院审理案件时确定双方权利义务、侵权与否以及法律责任等争议的准据标准,是首先需要解决的问题。我国司法实践的主流观点认为,开源协议是附解除条件的软件著作权使用许可合同,对各方具有法律约束力。


第一,司法实践认为开源协议是通过要约与承诺达成的、对双方具有法律约束力的格式合同。在罗盒公司与风灵公司案中法院认为,GPL协议授予用户自由复制、修改、再发布等权利,属于设立、变更、终止民事权利义务关系的民事法律行为;开源软件的发布视为要约,用户通过复制、修改、再发布等行为作出承诺;GPL协议以电子文本方式表现其内容,而电子文本是一种有形的表现形式,属于以书面形式订立的合同;无论从内容还是形式分析,GPL协议具有合同性质,可认定为授权人与用户间订立的著作权许可合同。[2]在未来公司与云蜻蜓公司案中法院认为,GPL协议是为特定开源项目开发而预先拟定的格式合同,由著作权人向软件使用者提出合同条款;其格式化条款保持承继性,且不属于格式合同条款无效的情形,其授权内容符合我国《著作权法》的规定,具有合同性质,是授权方和用户订立的格式化著作权合同。[3]


第二,司法实践认为,开源协议是附解除条件的合同。GPL协议(3.0版)第8条约定:“除非在该协议明确授权下,其他任何传播或修改受保护作品的企图都是无效的,并将自动终止你通过本协议获得的权利。”对于此约定,在罗盒公司与风灵公司案,[4]罗盒公司与玩友公司案、[5]卓卓公司与摩尔口腔医院案中,[6]法院均认为协议规定的使用条件,如开放源代码、标注著作权信息和修改信息等,系授权人许可用户自由使用的前提条件,亦即协议所附的解除条件,一旦用户违反了使用的前提条件,将导致协议在授权人与用户之间自动解除,用户基于开源协议获得的授权自动终止。因此,开源协议实质是权利人将其复制权、发行权、修改权等附条件地许可给不特定公众的著作权许可合同。


(二)违反开源协议的法律责任


如前所述,当用户违反开源协议条款时,权利人的授权或许可自动终止。此后,如果用户继续实施复制、修改、分发等行为将失去合法依据,需承担相应法律责任。我国《民法典》第一百八十六条规定:“因当事人一方的违约行为,损害对方人身权益、财产权益的,受损害方有权选择请求其承担违约责任或者侵权责任。”按照一般法理,授权终止后用户继续复制、修改和分发开源软件的行为构成违约责任与侵权责任的竞合,权利人可自主选择救济路径。司法实践中,法院亦认为违反开源协议使用开源软件的行为存在潜在的违约责任和侵权责任风险,[7]当事人有权自行选择救济方向。在罗盒公司诉玩友公司案件中,经法院依法释明后,罗盒公司明确主张玩友公司违反GPL开源协议构成无权使用,应承担相应侵权责任。[8]在其他司法案例中,权利人也通常倾向于选择主张侵权责任。[9]


本文认为,违约救济与侵权救济各有利弊,当事人可以结合具体案情和价值取向,选择更适合自身的救济路径。在主张违约责任时,权利人可要求违约方承担继续履行、采取补救措施或赔偿损失等责任。但需注意,由于开源协议通常未设置违约金条款,实践中难以直接主张违约金责任。在主张侵权责任时,除停止侵害、消除影响、赔礼道歉、赔偿损失等常规责任外,符合法定条件时还可申请临时禁令救济、主张惩罚性赔偿及要求支付合理维权开支。对比而言,违约责任的举证难度相对较低,侵权责任法律救济措施更多,损害赔偿范围更大,但举证难度显著提高。


值得注意的是,主张违约责任具有独特的法律价值:对于技术性能优异、应用价值突出的衍生软件,如果开源协议要求继续开源,权利人通过主张违约责任可要求违约方继续履行义务,强制将相关衍生软件按开源协议要求开源,这将有效保障开源软件“自由、协作、共享”核心理念的落实与传播。[10]


(三)开源抗辩的司法实践


开源抗辩是指在软件著作权侵权纠纷中,被控侵权人以原告(软件权利人)违反开源许可协议为由,主张原告的行为已丧失或部分丧失追究侵权责任的合法性,试图通过“不洁之手”原则否定原告著作权的正当性,进而请求法院驳回原告的著作权侵权诉求或限制其救济范围的一种抗辩策略。开源抗辩是否能够获得法院支持,我国司法实践呈现出观点摇摆的状态。


在未来案中,被控侵权人云蜻蜓公司辩称,原告涉案软件中主程序部分受GPL协议约束,但原告未遵守GPL协议开放主程序的源代码,反而对涉案软件进行闭源处理,构成违约行为;即使被告存在使用涉案软件的行为,原告的非法利益也不应受法律保护。法院经审理认为,原告软件主程序部分因GPL协议的“传染性”条款而受该协议约束,其违反GPL协议不对外提供主程序源代码的行为若仍获法律保护,实质是保护其不当行为产生的利益,有违诚信原则,且将导致GPL协议关于源代码持续开源的规定被虚置,不利于通过开源协议实现源代码持续传播的立法目的。因此,法院对主程序部分构成著作权侵权的诉求不予支持。[11]该案成为我国首例支持开源抗辩的司法案例。


然而,最高人民法院在之后的“亿邦案”二审判决中认为,软件侵权案件中被告以原告违反开源许可协议为由提出的不侵权抗辩不能成立。法院指出,软件开发者自身是否违反GPL协议与其是否享有软件著作权属于相对独立的法律问题,开发者违反GPL协议的行为属于合同义务违反,但其对独创性作品享有的著作权仍受法律保护,二者不宜混淆处理,否则可能不合理地剥夺或限制软件开发者基于其独创性贡献依法享有的著作权。被诉侵权人仅以开发者未依据开源协议开源为由抗辩不构成侵权的,人民法院一般不予支持。[12]


尽管有观点认为,最高人民法院在“亿邦案”中的裁判立场使得开源抗辩的司法适用空间被大幅压缩,甚至成为“昙花一现”的例外情形。但本文认为,鉴于当前司法案例样本有限,尚不足以认定我国已形成关于开源抗辩的统一裁判规则,该问题的法律内涵与法律价值仍需深入探讨。开源协议作为国际通行的、软件行业普遍认可的有效契约,其文本约束力是诚实信用原则在软件领域的具体体现。从法律价值层面分析,支持开源抗辩有助于维护开源创新生态体系的维持和健康发展,有利于保障公众对开源软件成果的预期和合理使用,这些法律价值取向值得司法实践予以充分重视。


四、开源软件应用中的主要法律问题


商业实践中,以下是开源软件使用人关注度较高的法律问题,在技术开发或商业应用中需要重视。


(一)是否需要向许可人或权利人支付开源软件使用费?


常规软件使用许可合同会约定被许可人需向权利人支付一定数额的使用费。然而,使用开源软件无需事先与权利人协商软件许可事宜,包括是否需要支付使用费。开源协议普遍不要求使用者支付软件许可使用费。GPL、LGPL、BSD、MIT、Apache 2.0、MPL、木兰宽松许可证等主流开源协议均不要求用户在遵守开源协议设定的许可条件下,无论商业还是非商业用途,支付使用费。权利人仅可就物理介质分发、技术支持、定制开发等服务收取费用,但这些费用并非开源软件本身的使用费,而是基于开源软件的周边服务或定制服务等收取的增值服务费。


(二)是否可以商业化使用开源软件?


开源软件的商业化使用是指企业或个人在商业活动中或以盈利为目的使用开源软件。常见的商业化使用方式包括:


● 内部使用:企业在自身产品开发、运营、管理等内部流程中使用开源软件。


● 产品集成与分发:将开源软件集成到自有产品或服务中,作为整体解决方案的一部分提供给客户,或将开源软件(原版或修改版)打包后分发、销售。


● 基于开源软件的有偿服务:如技术支持、定制开发、维护、培训等收费服务,或通过SaaS、云服务等方式提供基于开源软件的有偿托管服务。


大多数开源协议允许使用者在遵守开源协议所约定的使用条款的前提下进行商业化使用。开源协议并不排斥软件开发者从软件中获取利益,只是盈利方式从传统依赖软件拷贝的销售,转向主要提供软件及信息服务,如技术支持、培训、咨询、系统集成或其他派生的增值业务。[13]


实践中,还会面临软件提供方是否可以在开源协议基础上另行设置商业使用限制条款的问题。在罗盒案件中,罗盒公司主张权利的VirtualApp软件是适用GPL协议的开源软件,根据GPL协议的规定,用户可以自由使用VirtualApp软件,包括商业化使用。但罗盒公司在VirtualApp项目中声明“当您需要将VirtualApp用于商业途径时,需要进行授权”,也就是说,罗盒公司在GPL协议的基础上另行对商业化使用做了限制,要求使用者事先取得其授权,从而改变了GPL协议原本的规定。法院认为,罗盒公司的商业使用限制条款对于用户使用其源代码的目的进行了限制,从而也限制了用户范围,即只有非商业用途的用户才可以自由使用其源代码,但根据GPL协议本身的条款,罗盒公司无权在GPL协议基础上另行添加商业使用限制条款。[14]简言之,就GPL协议而言,软件发布者不得就商业化使用做出限制。


(三)用户是否需要公开衍生软件的全部源代码? 


这一问题的回答需要依据开源协议的传染性来确定,不同开源协议的传染性不同。传染性是指对开源软件进行修改、扩展或结合其他代码形成衍生作品时,衍生作品也必须遵守该开源协议向用户提供源代码,不得将源代码闭源。典型的具备传染性的开源协议为GPL和AGPL。GPL协议规定:“将衍生自本程序或其任何部分的任何作品,若进行任何发行或者发布,则作为一个整体自由许可给所有第三方”。这意味着使用GPL开源软件开发的衍生软件同样需要适用GPL,在对外分发时,例如向客户提供目标代码时,必须按照GPL协议要求同时向客户提供源代码。在罗盒公司诉玩友公司案中,法院对开源传染性的效力归纳如下:[15]


● 用户不得在使用受GPL协议保护的软件基础上加入闭源软件构成更大软件,GPL软件的所有部件均须遵循GPL规定公开源代码;


● 用户不得将GPL软件修改后(如加入自己编写的软件)将修改部分变成闭源软件,即用户的创造或增值软件的源代码应公开给社会共享。


需要注意的是,并非所有开源协议均具有传染性。宽松型开源协议如MIT、Apache 2.0和BSD等,允许用户将开源代码整合到闭源项目中,不再开源,即基于MIT、Apache的衍生软件的源代码可以不向用户或社会公众提供。


不同开源协议的对传染性强度要求也不同。GPL仅对通过光盘、U盘等传统模式分发开源软件的行为进行了规制,而没有限制通过云服务使用开源软件也需要满足开源要求的义务。AGPL则规定,当开源软件放置在服务器,虽然没有向用户提供开源软件副本、用户也无需下载开源软件,但让用户与之通信,例如供用户调用,则也需要提供开源软件源代码。SSPL规定,在“软件即服务”模式下,虽然没有向用户提供开源软件副本、用户也无需下载开源软件,但当公司将SSPL协议下开源软件的功能作为一项直接面向客户的服务提供给客户时,需要向用户提供源代码。也就是说,衍生软件的分发方式不同,也有可能涉及不同的开源义务。


实践中,企业往往会在开源软件基础上投入大量人力、物力进行进一步开发,生成与自身服务或产品相关的商业化软件。显而易见,为保持竞争优势,企业往往倾向于将这些衍生出的商业化软件作为技术秘密保护,不公开或不向用户提供源代码。此时,企业需要基于软件使用方式、分发方式以及适用的开源协议进行具体分析和判断,其是否有提供衍生软件源代码的义务。


(四)开源软件使用中的专利问题保护和专利侵权问题


将算法对应的代码对外开源形成开源软件,同时针对算法对应的方法申请专利,是实践中采用多种知识产权保护立体保护技术研发成果的常规做法。对此,存在以下两个与专利相关的法律问题。


第一,基于开源软件的衍生技术成果是否能够申请专利,是否可以获得专利授权? 


就是否可以提交专利申请而言,主流开源协议如GPL、LGPL、AGPL以及SSPL等均没有限制开源软件的后续开发者、使用者不得申请专利,对开源软件进行二次开发的发明人可以就研发成果申请专利。就是否满足专利授权条件获得专利授权而言,由于开源软件是公开的现有技术,这部分不符合专利授权中的新颖性和创造性条件。将公司自己开发出的软件部分对应的技术方案申请专利,属于正常的专利申请,与是否使用开源软件已无关系。将开源软件与公司自己软件结合后形成的技术方案申请专利,即申请专利的技术方案既包括开源软件内容又包含公司自己软件内容的,是否能够授权,需要根据新颖性、创造性的授权条件具体判断。


第二,开源软件的权利人是否可以依据授权专利向开源软件使用者发起专利侵权诉讼?


对于此问题,部分开源协议明确规定,开源软件的权利人必须同时将相关专利授权给用户使用。GPL协议明确写道:GPL协议保证专利不能使程序非自由化,软件的“贡献者”授予软件使用者对于其“必要专利”的非独占的、全世界范围的、免费的制造、使用、销售、许诺销售、进口的权利。GPL协议管理方还在其官网进一步解释到,针对专利威胁的更强保护无论何时,只要有人输送了自写或修改版的GPL软件,他们就必须为每个接收者提供他们实际使用需要的任何专利许可。此外,如果有专利权人想要通过专利诉讼阻止其他用户实现他们的权利,那么他在开源协议项下获得的许可就会被中止。[16]木兰宽松许可证明确授予用户永久性、全球性、免费的、非独占的、不可撤销的版权和专利许可,并针对目前专利联盟存在的互诉漏洞问题,明确规定禁止“贡献者”或“关联实体”直接或间接地(通过代理、专利被许可人或受让人)进行专利诉讼或其他维权行动,否则终止专利授权。对于这些明示了专利授权条款的开源协议,专利侵权风险相对较小。


部分开源协议没有明示专利许可规定,如BSD、MIT等,理论上开源软件的权利人有可能向开源软件使用者提起专利诉讼并收取专利许可费,但这又不符合开源协议自由使用的价值取向,具体有待实践检验和观察。


(五)产品销售者是否具有开源合规审查义务?


在Harald v. FANTEC案件中,[17]被告FANTEC在其销售的媒体播放器中使用了基于GPL协议开源的netfilter/iptables软件,该软件著作权人为Harald Welte。GPL要求使用者必须向用户提供软件的完整源代码,但FANTEC未履行该义务。Harald Welte指控FANTEC违反开源协议,侵犯其著作权。FANTEC辩称其仅为经销商,产品由供应商提供,且供应商已保证源代码完整,因此不应承担责任。法院认为,FANTEC不仅是经销商,更是产品的“制作商和分销商”,需对产品合规性负责,依赖供应商保证不构成有效抗辩,企业应主动审查开源协议合规性,而非被动接受第三方承诺。该案判决认定,企业无论作为开发者、集成商还是经销商,均需对采购的软件进行合规审查,确保符合开源协议要求。虽然该案为德国案例,但对于我国企业和开源司法实践而言,具有参考意义,经销商也应重视对经销产品或软件的开源合规审查,而不仅仅依赖于供应商的单方保证。


本文需要强调的是,以上讨论的法律问题,主要基于主流或常见开源协议展开讨论,但不同开源协议对以上法律问题的约定不同,问题的结论自然也会有不同。实践中,需要结合具体开源协议进行有针对性的分析论证。


五、IPO监管实践及合规要求



(一)监管要求与规则体系


各证券板块均将开源软件的使用作为重点监管内容。2024年11月,深圳证券交易所在总结行业审核实践经验的基础上,发布《深圳证券交易所创业板数字经济领域首发审核指南(试行)》,明确将源代码及开源软件问题纳入首发审核要点。其中:


● 第十三条规定,针对软件和信息技术服务相关业务,审核时应结合发行人核心技术情况,重点关注核心技术的形成过程、源代码的掌握情况、是否符合开源协议约定,以及是否存在侵犯知识产权或商业秘密的情形。


● 第二十八条规定,针对涉及人工智能的业务,审核时应结合发行人核心技术情况,重点关注对开源技术的改进情况、核心技术的独创性,以及是否存在套用其他开源模型外壳的情形


● 第三十条规定,审核核心技术外部依赖性时,应重点关注核心技术来源及源代码开发情况


可以看出,该指南明确将开源软件使用情况纳入与核心技术相关的审查范围,要求发行人详细披露开源协议履行、技术独创性及知识产权归属等关键信息。对于从事软件和信息技术服务业务、人工智能业务的拟上市企业,开源软件将是核心技术及知识产权等多个审核环节的监管要点。


(二)监管关注的典型问题及实践案例


1. 发行人一


发行人一存在使用开源软件搭建核心产品基础组件的情形。监管问询聚焦于:核心技术的开发过程是否存在对电商平台数据、开源软件的重大依赖,以及是否涉及数据安全、知识产权侵权法律风险。


发行人一回复强调:软件研发过程中使用开源软件/代码具有行业普遍性,其不存在对单一开源软件形成依赖的情形;所使用的开源软件均通过许可协议允许个人及机构免费使用,未因开源软件使用导致经济利益受损或侵害他人权益,不存在知识产权侵权法律风险。


2. 发行人二


发行人二存在使用非自主开发的底层开源软件的情形。监管问询重点为:是否存在未经许可使用受限制底层软件的情形,是否建立知识产权保护等内部制度及执行情况,是否涉及技术侵权纠纷或潜在纠纷


发行人二回复明确:所涉底层软件均为开源软件,依据协议可免费使用并用于商业软件开发,不属于需许可的受限软件;经自查,未因未经许可使用受限软件引发诉讼、仲裁等纠纷。


3. 发行人三


监管机构在审核中发现发行人三存在开源软件管理缺陷,包括未制定专项开源软件管理制度、开源组件安全评估未覆盖全部组件等,并要求整改。


发行人三整改措施包括:制定专项开源软件管理制度,组织专题会议开展开源组件安全性评审,完善管理流程。


4. 发行人四


发行人四采用基于开源软件的操作系统开发模式,如基于Linux内核及各类Linux发行版进行商业开发,并实现自动分布式系统重建、分布式缓存分层等基础功能。监管要求保荐人及发行人律师就以下事项发表明确意见:相关操作系统及软件开发是否符合开源协议约定,是否存在使用不可商业化开源代码或违反协议的其他情形,是否涉及向开源社区付费,是否附带开源社区商标或协议条款,是否存在知识产权侵权风险或潜在争议。


(三)监管背后的法律逻辑:开源合规


上述案例中,监管问询常围绕开源依赖性、协议履行情况、商业使用边界等问题展开,这些问题直接反映在开源协议合规性、知识产权归属与侵权风险、商业使用限制等法律问题上。监管问询的依据和目的就是开源软件使用要符合规范,不存在不利影响。发行人需通过协议条款分析、使用情况自查、风险排查等方式,全面证明开源软件使用的合规性。


六、启示与建议


各类市场主体可以通用以下两个方面工作强化开源软件使用的合规性,避免陷入不必要的纠纷或诉讼。


(一)严格履行开源协议义务


1. 严格遵守开源协议条款


在使用开源软件前,详细审查并严格遵守所适用开源协议的具体条款,按要求公开源代码、保留原作者信息、声明修改内容,禁止擅自增加限制性条款等。


2. 明确权利归属与管理机制


开源项目应通过协议或社区规则明确管理者、贡献者的权利归属。


3. 证据留存与合规审查


权利人应保存著作权登记证书、源代码、开发过程记录、协议文本等证据;使用人应保留合规使用、履行协议义务的证明材料,如开源协议文本、修改记录、公开声明等。


4. 关注商业化使用风险


若开源协议限制商业用途,企业应严格区分内部学习与商业运营场景,避免超范围使用导致违约或侵权。


5. 及时应对侵权指控


被控侵权或违约时,使用人应及时核查所用软件版本、协议类型及实际用途,举证合规使用或协议授权,避免因举证不足承担不利后果。


(二)开源软件风险防控策略建议


开源软件涉及著作权、专利权、商标权、商业秘密等多重知识产权问题,且跨界计算机技术与法律领域,需要技术人员与法律人员共同关注。


1. 加强对开源协议的规范认知


开源协议类型多样(如GPL、LGPL、MIT、Apache等),权利义务规定各异,且条款表述可能存在模糊性。开源软件使用者应系统解读各类开源协议的内容,准确把握使用与贡献规则,避免因认知不足引发合规风险。


2. 加强开源合规管理组织建设


根据企业规模与发展阶段设置专项管理组织:


● 大型企业可将开源管理上升至战略层面,设立“开源委员会”,由技术负责人、总法律顾问、首席知识产权顾问等组成,统筹制定开源策略、推动社区合作、决策重大问题;


● 中小企业可根据开源软件使用量设置专门岗位或小组,负责跟踪技术动态、评估软件性能、指导合规使用、应对风险事件。


3. 建立健全完备的开源软件规章制度


系统梳理企业所有软件产品中涉及的开源软件,研究对应许可证要求,制定《开源软件使用规则》,明确以下内容:


● 不同开源协议的应用场景、性能效果、可替代方案;


● 开源协议核心要求(如是否允许与非开源代码混合、是否需公开修改后代码、专利许可授权规则、协议终止条件等);


● 风险分级管控(如禁止使用的高风险许可证、谨慎使用的中风险许可证、推荐使用的低风险许可证),并标注内部审批流程与开发注意事项。


查看参考文献

[1] 参见《计算机软件保护条例》第三条。

[2]参见(2021)最高法知民终2063号民事判决书。

[3]参见(2021)苏01民初3229号民事判决书。

[4]参见(2021)最高法知民终2063号民事判决书。

[5]参见(2019)粤73知民初207号民事判决书。

[6]参见(2023)苏02民初482号民事判决书。

[7]参见(2018)苏05民初845号民事判决书、(2021)最高法知民终51号民事判决书。

[8]参见(2019)粤73知民初207号民事判决书。

[9]参见(2021)最高法知民终2063号民事判决书。  

[10]潘亮:开源软件司法保护探析,知产财经微信公众号,https://mp.weixin.qq.com/s/-qP5PaWoU3o4o1CWR-Ff5Q

[11]参见(2021)苏01民初3229号民事判决书。

[12]参见(2018)苏05民初845号民事判决书、(2021)最高法知民终51号民事判决书。

[13]参见(2019)粤73知民初207号民事判决书。

[14]参见(2019)粤73知民初207号民事判决书。

[15]参见(2019)粤73知民初207号民事判决书。

[16]来源:www.gnu.org/licenses/quick-guide-gplv3.html

[17]参见Regional Court of Hamburg, Harald v. FANTEC, June 2013


image.png

相关人员