|
四、开源软件应用中的主要法律问题
商业实践中，以下是开源软件使用人关注度较高的法律问题，在技术开发或商业应用中需要重视。
(一)是否需要向许可人或权利人支付开源软件使用费?
常规软件使用许可合同会约定被许可人需向权利人支付一定数额的使用费。然而，使用开源软件无需事先与权利人协商软件许可事宜，包括是否需要支付使用费。开源协议普遍不要求使用者支付软件许可使用费。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 | 
ENGLISH
律所微信
移动端微门户
律师微博
下一篇：
