- within Transport, Strategy and Employment and HR topic(s)
一、引言
开源软件作为全球软件生态的核心基础设施，对于产业与技术的发展无可替代，不论是在传统的程序开发阶段还是在当下的AI辅助编程时代，其合规问题与司法裁判标准无疑是近年来高科技企业无法回避的经营边界。近期，因使用开源软件不合规，某A股主板上市芯片企业涉嫌侵犯多媒体处理开源架构FFmpeg计算机软件著作权，相关代码库被GitHub平台紧急冻结。该芯片企业于春节后立即启动合规性整改和公关，引发行业对于开源软件合规问题的高度重视和深度探讨。
根据开放源代码促进会（Open Source Initiative，简称“OSI”）官方网站的定义，开源软件系指向公众开放源代码的软件，用户可以以源代码的形式自由再分发、修改源代码并形成衍生作品。开源软件给予了用户最大限度的开发自由和传播自由，但同时具有明确的使用规范。当前各类开源软件使用场景下，因代码引用、二次开发、商业使用或分发、组件集成等引发的开源协议违约、侵害计算机软件著作权等问题并不鲜见。准确划定开源软件的合规边界，是企业使用开源软件开发产品和合规经营的基础和前提。
二、开源协议合规知识要点
从合规风控层面来看，开源软件的研发、复用、分发及商业化应用全流程，均以开源协议的具体类型为核心。开源协议并非普通的格式文本，其本质是具有强制许可性质的合同，不同类型的开源协议就权利边界、传播限制、溯源披露等义务设定存在本质差异，直接决定了开源软件使用行为的合法性。基于此，本部分将围绕开源协议的类型及其特点、开源软件合规风险防控与法律责任化解要点等关键法律问题进行详细阐释，为软件开发企业提供专业合规借鉴。
（一）开源协议的基本信息及审查要点
开源软件发展至今，经OSI批准的开源许可证类型已过百种，排除部分已废止和不常用的开源许可证，当前主流开源协议按照传染性的强弱，可以分为强著佐权式许可证、弱著佐权式许可证、宽松型许可证。各不同许可证典型示例及其特点如下：
由上可见，不同类型的开源许可证在许可条件方面存在巨大差异，企业在选择开源项目的同时，也应重点审查许可证的类型并厘清相应的权项限制。对于强著佐权式许可证，因其自带强制性开源约束，须格外关注其强传染性和合规边界，使用、修改、分发开源软件的任一组件，均会触发整个项目的开源义务。对于弱著佐权式许可证，通常采用文件级或库级的开源限制，通常仅要求对许可证涵盖的原有开源组件开源，无需公开自有核心代码。
对于宽松许可证，虽然限制少、使用灵活度高，企业可以自由开展闭源商用、修改源代码、二次分发等，但依然应当依据不同宽松许可证的具体条款，履行合规义务。
（二）通过技术措施规避开源约束的注意事项
开源软件的合规使用是技术与法律深度交叉融合的专业议题。除了从法律层面严格审查各类许可证条款、厘清权责义务与合规边界之外，还不能忽视技术层面的管控，尤其要对软件架构设计、代码隔离方式、组件集成模式等问题应予以重点关注。
对于诸如GPLv3的强著佐权式许可证，如希望规避特定开源组件导致整个软件被迫开源的风险，通常的代码隔离不能阻断强著佐权式许可证的传染性，应分层隔离软件架构以切断传染链路，对底层、中间层、应用层代码进行独立开发，以避免组件合并、嵌套编译、直接链接等方式引发许可证传染。
在罗盒诉玩友案1中，广州知识产权法院即提及谷歌公司在安卓操作系统上的解决方案，即“通过将GPL的适用局限在安卓系统独立的底层Linux内核空间中，而在上层的类库和应用框架以及用户空间部分则适用较为宽松的ASL开源软件许可协议。由于上层的类库和应用框架以及用户空间部分并不视为底层Linux内核的衍生产品，因此避开了GPL许可协议传染至整个安卓系统，那么安卓系统上层的硬件驱动和应用框架程序就是独立的，其开发者适用ASL进行开发，可以自由选择是否公开其源代码。如不能实现软件架构完全隔离，即应当履行许可证项下义务”。在不乱买公司诉闪亮公司侵害计算机软件著作权纠纷2中，最高人民法院也指出：“前端代码一般是关于用户可见部分的编码，用以实现操作界面如页面布局、交互效果等页面设计；而后端代码一般是涉及用户不可见部分的编码，用以实现服务端的相关逻辑功能。同时，前端代码与后端代码是可以分别独立打包、部署的。因此，前端代码与后端代码在展示方式、所用技术、功能分工等上均存在明显不同，不能因前端代码与后端代码之间存在交互配合就认定二者属于一体，原审法院认定前端代码与后端代码相互独立并无不当。”
对于弱著佐权式许可证或宽松许可证，在符合许可证条款约定的情况下，可以通过代码物理隔离避免许可证的传染，但应明确各许可证下的权属边界。不同许可证下的代码，应设立独立目录、独立模块，分别管理，分别编译；每个开源组件单独留存许可证文件、版权声明。混合使用多款开源组件时，还应关注许可证兼容性。不同开源许可证的条款约束存在差异，强著佐权式许可证排他性较强，通常无法与其他类型许可证混合分发，组件的合并整合会触发强传染性，容易导致整个项目被迫开源；弱著佐权式许可证的兼容性依许可证的具体条款确定；宽松许可证通常可以兼容。
三、主流裁判规则对于开源软件侵权之诉的认定标准
（一） 开源软件的性质
软件开源许可的设立目的在于倡导开放、共享、平等、协作精神，鼓励自由使用、自由复制、自由修改、自由分发，核心在于促进技术的共享与传播。当前涉及开源软件的案件数量整体较少，但主流裁判对于开源软件许可证的性质和违反开源许可证的后果基本形成共识。
在前述罗盒诉玩友案中，广州知识产权法院对开源许可协议的法律性质进行了详细分析，指出GPLv3协议属于格式化民事合同，并非典型合同，是授权方和用户之间形成的以使用开源软件源代码为目的的一种民事法律行为。开源作者向不特定对象让渡部分著作人身权与全部财产权，以此换取使用者遵守开源协议义务，其条款具备承继性，内容符合我国著作权法规定，合法有效。开源许可协议无需书面签订，使用者以实际使用行为作出承诺，即可成立合同关系。
罗盒诉风灵案3中，最高人民法院对于开源许可证的法律性质秉持了相同的观点，并进一步明确了违反开源许可证可以适用侵权法律关系予以救济：“根据开源软件的特性，GPL3.0协议规定的使用条件（如开放源代码、标注著作权信息和修改信息等）系授权人许可用户自由使用的前提条件，亦即协议所附的解除条件。一旦用户违反了使用的前提条件，将导致GPL3.0协议在授权人与用户之间自动解除，用户基于协议获得的许可即时终止。用户实施的复制、修改、发布等行为，因失去权利来源而构成侵权。”
可见，开源作者与使用者之间虽然属于合同法律关系，但基于开源许可协议的特殊性，使用者违反开源许可证，开源作者可以基于未经许可的使用行为提起侵权之诉。
（二） 开源软件侵权之诉的原告主体资格认定
- 开源作者提起诉讼是否须以获得开源项目其他贡献者授权为前提？
开源软件往往由一个项目管理者上传项目初始源代码并创建主分支，其他用户可以基于主分支创建自己的分支并自行维护，经项目管理者同意，其他用户可以将其分支中的修改并入主分支，最终形成一个集全球开发者智慧和软件最优化的开源项目成果。
基于最高人民法院在罗盒诉玩友案中所确立的裁判规则，项目管理者具有独立的诉权。项目管理者和项目并入主分支的其他贡献者对开源项目存在共同创作的合意，其他贡献者在申请将其代码合并入主分支时默认同意适用LGPLv3协议或GPLv3协议，即同意将其代码开源贡献给项目管理者和其他用户在开源协议范围内自由使用。即使将涉案软件认定为合作作品，在难以查清所有权利人的情况下，若要求必须经过开源项目的所有贡献者授权才能提起诉讼，那么将导致开源软件维权无从提起。
进一步地，其他贡献者对独立创作且已并入主分支的部分，是否享有独立的诉权？由于实践中进入诉讼阶段的侵害开源软件著作权纠纷较为有限，尚无司法裁判就此明确认定。笔者认为，根据《计算机软件保护条例》第十条之规定：“由两个以上的自然人、法人或者其他组织合作开发的软件，其著作权的归属由合作开发者签订书面合同约定。无书面合同或者合同未作明确约定，合作开发的软件可以分割使用的，开发者对各自开发的部分可以单独享有著作权；但是，行使著作权时，不得扩展到合作开发的软件整体的著作权。”如果其他贡献者能够证明其主张权利的部分系独立开发、修改且具有独创性，则开源软件的分支可独立作为著作权法保护的客体，合作作者对其独立开发或修改的部分享有完整著作权。如遭遇侵权，在不延及软件整体著作权的前提下，该贡献者有权就其独立开发或修改的分支进行“分割”维权。
- 开源作者未遵守开源许可证，是否有权提起侵权之诉？
开源软件使用者未遵守开源协议，未对二次开发形成的衍生作品进行整体开源，其对衍生作品可能存在权利瑕疵，该等权利瑕疵是否影响原告提起侵害著作权纠纷的权利基础，最高人民法院最新司法态度倾向于将原告违反开源协议与原告就独创部分主张权利明确区分为两个独立的法律关系，在先违约行为不实质性影响原告对独创作品在中国著作权法下受到保护的权利，但仍应适当考量受开源协议约束的开源组件与软件的其他部分是否已融为一体。
苏州某科技公司诉浙江某通信公司侵害计算机软件著作权纠纷4中，原告基于GPL开源项目OpenWRT二次开发形成权利软件，权利软件一部分是对GPL开源项目OpenWRT系统软件对应源代码进行增删、修改、调整而形成的软件底层系统，另一部分是与涉案软件具体功能相对应的新增源代码所形成的上层功能软件，被告在开发被诉侵权软件过程中复制并修改了原告的权利软件并公开发布。就被诉侵权软件整体是否受GPLv2协议约束，最高人民法院指出，“该问题涉及底层系统软件是否受GPLv2协议约束、上层功能软件是否构成GPLv2协议项下‘独立且分离的程序’、二者间采用的隔离技术手段、通信方式、通信内容等如何界定以及软件领域对GPLv2协议传导性的通常理解与行业惯例等因素。在OpenWRT系统软件权利人并非本案当事人情形下，亦难以查明与GPLv2协议有关的前述系列事实。……软件开发者自身是否违反GPLv2协议和是否享有软件著作权，是相对独立的两个法律问题，二者不宜混为一谈，以免不合理地剥夺或限制软件开发者基于其独创性贡献依法享有的著作权。本案最终认定被诉行为构成侵权并支持苏州某科技有限公司部分诉请，并不表明苏州某科技有限公司将来在潜在的违约或侵权之诉中可免予承担其依法应当承担的违约或侵权责任。”本案客观上并未严格审查原告所采取的技术隔离手段是否切实有效、原告未予开源的部分是否构成“独立且分离的程序”，最高人民法院重点区分了原告在开源软件下的合规义务和对独创作品依法维权的基本权利，鼓励原告对自有创新成果的保护，对创建风清气正的科技创新环境持积极且坚定的司法态度。
南京市中级人民法院在早先案例中的不同裁判，亦值得企业关注。在南京未某公司诉江苏云某公司侵害计算机软件著作权纠纷5中，原告主张被诉侵权软件侵害了权利软件的计算机软件著作权，但原告使用了受GPL开源协议约束的代码却未基于GPL协议公开权利软件源代码。南京市中级人民法院明确指出：“如果能够确定作品的一部分并非程序的衍生作品，是独立的，则这部分独立的程序发布时可以不受GPL的约束……确定被传染的部分应当是与原开源软件形成密切通信使得二者高度牵连融合成一体的程序，而非只要有数据交换就会构成传染。”并对受GPL开源许可证传染的代码进行了审查：“主程序与涉案GPL开源代码存在函数调用关系的情况，涉案GPL开源代码实现的压缩功能系投标文件上传前不可或缺的功能，因此，主程序系涉案GPL开源代码的衍生作品，受GPL协议的约束。……未某公司通过将自行编写的FutureZR.cs文件与SharpZipLib开源代码一同编译成FZR.dll，并由主程序对其进行调用的方式，不符合独立模块”，由此认定原告违反了GPLv2协议要求提供相应源代码的义务，构成违约，原告对原GPL开源代码的继续使用系无权使用。南京市中级人民法院指出：“原告起诉被告行为不当，构成侵权，但其自身首先应当规范使用开源代码，遵守开源协议，并证明自身权利的正当和合法，否则即会导致一个不当、不法的行为人指责另一个实施相同行为的不当、不法行为人的逻辑怪圈。法院如果基于原告的该权利认定其他行为人构成计算机软件侵权，即会保护原告未某公司的不当行为带来的利益，势必赋于其特殊法律地位和特别商事利益，不符合公平、诚信原则。”
南京市中级人民法院的裁判观点看似与最高人民法院典型案例的裁判规则存在矛盾，实则不然。最高人民法院在典型案例中对原告软件独创部分给予保护，亦是基于原告主张保护的权利基础属于软件系统的上层架构，与基于开源软件开发完成的底层系统相对独立，具有单独主张的可行性；南京市中级人民法院的在先案例中，原告主张保护的权利软件功能与开源软件功能密不可分，权利软件主程序与开源程序存在明确的调用关系，是开源软件的衍生作品，与开源组件难以明确分割，或强行分割后会因功能故障而无法作为一个独立程序作品，故其权利瑕疵可能对原告的诉讼主张产生实质性影响。
对于受强著佐权式许可证约束的开源软件，只有在软件的闭源部分与开源组件相对独立、可以明确分割的情况下，衍生作品的著作权人存在权利瑕疵时，才有权基于衍生作品主张权利。技术隔离手段是否切实有效、是否符合行业惯例等问题影响原告是否违反开源协议的定性，但并不当然阻碍法院对其中相对独立的独创作品进行侵权审查。
（三） 开源协议中附加许可条件并不当然有效
不同于通常的知识产权许可协议，双方可以通过协商变更许可条件，不断调整双方权利义务。开源协议系预先设置好格式化条款的协议，协议未明确授予使用者修改许可证、增加附加许可条件的情况下，附加许可条款可能因超出开源协议约定的附加许可情形或与开源许可证其他条款相悖等原因无效。
在前述罗盒诉玩友案中，广州知识产权法院即基于GPLv3协议第5条、第7条和第10条规定，认定“开源软件与商业软件的最大区别就在于开源软件作者将全部著作财产权利让渡给了使用者，开源软件是以放弃著作权相关权利的形式所进行的一种软件开发模式。虽然开源软件作者将著作财产权利让渡给软件使用者，但并没有放弃用商业化的方式促进开源软件产业的发展。……罗盒公司的商业使用限制保留条款对于用户使用其源代码的目的进行了限制，从而也限制了用户范围，即只有非商业用途的用户才可以使用其源代码，这显然与GPLv3协议的‘著佐权’特性矛盾。该限制保留条款也不属于第7条规定的可以添加的6种补充附加条款之一，应属于非许可性附加条款，属于第10条中的‘进一步限制’，因此罗盒公司无权在适用GPLv3协议的涉案VirtualApp项目中添加商业使用限制保留条款。”
实践中，部分开源项目管理者提供受GPLv3约束的开源代码，但在开源协议中约定，如用户支付必要许可费用，即可向用户提供闭源商用版本；此类条款违反强著佐权式许可证的设立目的，且超出了GPLv3开源协议约定的附加许可情形，可能属于无效条款。企业面对此种情况，应当重点审查开源项目中是否已包含了受GPL或AGPL等强著佐权式许可证约束的在先开源组件，如是，则该开源项目管理者所提供的开源代码在未采取有效隔离措施的情况下，已被在先开源组件传染。不论企业是否支付费用，均不能免除企业使用该开源项目后对衍生软件应履行的开源义务。
四、AI辅助编程时代仍应关注软件的开源合规问题
近年来AI技术快速普及，各类AI编程工具已成为代码研发的主流辅助手段，但企业使用AI生成代码并不能豁免开源合规义务，开源软件合规风险仍是AI编程场景下必须正视的问题。
代码大模型虽精通计算机语言语法与编程通用逻辑，但其输出内容并非“0→1”原创。模型训练以海量开源架构、开源代码及技术文档作为底层语料，经深度学习与概率推理，生成代码。不同于其他模型的语料训练，算法模型在机器学习阶段使用的语料大多来源于开源项目，开源作者选择将项目开源，相当于同意将其代码许可给不特定用户在开源协议范围内自由使用，以鼓励开源代码的传播。故当前学术和实践领域普遍关注的模型训练数据合法性问题、因训练数据不正当而引发的AIGC侵权定性问题，在AI编程领域似乎并不存在。使用AI编程工具可能引发的侵害计算机软件著作权纠纷，未来可能主要出现于用户端而非平台方，即企业在使用AI生成代码过程中，是否对AI生成代码中的开源项目尽到了审慎注意义务，以及是否依据开源许可证的约定履行了开源义务。
故企业在使用AI编程工具时，也应对AI生成代码中的开源组件和开源代码进行溯源，审查相应开源协议的约束条款，以防范AI工具所产生的知识产权风险。
五、结语
开源软件为企业研发工作提供了极大便利，也系软件开发行业的重要技术资源。同时，各类开源协议为用户设定了明确的使用规则，框定了依法使用和侵害计算机软件著作权的边界。企业在享受开源软件带来便利的同时，也应重视开源软件的合规管理，规避因忽视开源协议条款而导致核心源代码被迫强制开源或软件主要模块重新开发，或因违反协议约定面临软件产品禁售，从而损害企业的竞争优势，增加企业经营成本。
注释：
1 广州知识产权法院（2019）粤73民初207号民事判决书，入选2021年中国法院十大知识产权案件，广州知产法院2021年度知产司法保护十大典型案例
2 最高人民法院(2019)最高法知民终663号民事判决书
3 最高人民法院（2021）最高法知民终2063号民事判决书，入选最高人民法院知识产权法庭裁判要旨摘要（2023）
4 最高人民法院(2021)最高法知民终51号民事判决书，入选最高人民法院知识产权法庭成立五周年100件典型案例，最高人民法院知识产权法庭裁判要旨摘要（2023），2023年度苏州法院知识产权司法保护十大典型案例
5 南京市中级人民法院（2021）苏01民初3229号民事判决书
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
