开源许可证的传染性条款之探析

随着信息技术的迅猛发展和互联网的普及，开源软件已经成为现代软件开发中不可或缺的一部分。开源软件以其自由、开放的特性，促进了技术创新和知识共享，同时也对传统的软件许可模式和知识产权保护提出了新的挑战。在这样的背景下，开源软件的传染性条款作为一种特殊的开源许可证条款，其对衍生作品使用和分发的影响尤为显著。

 

本文旨在深入探讨开源软件传染性条款的法律实务问题。通过对开源许可证条款的深入解读，结合具体案例分析，揭示传染性条款对企业的影响，以及如何在遵守相关法律法规的前提下，合理利用开源资源，促进技术创新和产业发展。

 

一、开源软件的传染性条款概述

 

开源软件指的是源代码可以被公众访问、查看、修改和增强的软件，这些软件的许可证允许用户自由地使用、复制、分发、研究、修改和改进该软件。传染性条款是开源许可证中的一种特殊条款。

 

当某款软件以开源的形式发布时，任何基于该软件的开源代码形成的衍生品均必须遵循该软件的开源许可证中的相同或相似的许可条款，这类许可条款通常包含商业应用、发布发行、修改、申请专利、个人使用、注明协议和版权、注明变更、义务、商标使用、公开源码等限制或要求，这种特性通常被称为“传染性”，基于该种特性形成的条款被称为传染性条款。

 

传染性条款的出现最早可以追溯到1989年，当时美国自由软件运动的倡导人理查德·马修·斯托曼（Richard Mattew Stallman）与几名律师起草了世界上第一个具有传染性条款的开源许可证——GNU通用公共许可证（GNU General Public License,GNU GPL v1）[1]。该许可证通过设置传染性条款，确立了只要开发者对附带有GPL v1的开源代码进行修改或分发，则修改或分发后的代码也必须开源的规定，旨在确保开源软件的自由使用、修改和分发。

 

随着开源软件的不断发展，开源许可证的种类也越来越多。目前已经通过开源促进会（Open Source Initiative，OSI）认证的开源许可证就有一百多种，常见的开源许可证包括GPL、LGPL、AGPL、Apache、MIT、BSD、MPL等。不同的开源许可证针对其自身的传染性条款有不同的规则，使得不同的开源许可证的传染性有强有弱。

 

二、传染性条款的具体内容与分类

 

在开源世界中，开源许可证不仅是法律协议，更是确保代码自由和开放性的基石，传染性条款作为许可证中的重要组成部分，决定了代码的使用、修改和分发规则。

 

1.主流开源许可证的简要介绍

开源许可证多种多样，每种许可证都有其独特的规定，以下是几种主流开源许可证及其特点：

（1）GPL系列许可证：

这是最严格的开源许可证之一，要求所有修改和衍生作品也必须遵循GPL发布，这意味着如果开发者使用具有GPL的开源代码编写软件后，开发者必须公开修改后的源代码，并且修改后的源代码应当具有GPL。

 

特别是，GPL作为全球最流行最早的开源许可证之一，其有许多变种版本，例如AGPL（GNU Affero 通用公共许可证），LGPL（GNU 较宽松通用公共许可证）等。

 

（2）Apache许可证：

Apache 2.0许可证是ASF（Apache Software Foundation,Apache 软件Q基金会）在2004年发布的，以帮助ASF实现其目标：“通过开源软件开发协作，提供可靠且长久不衰的软件产品”。Apache许可证允许用户使用、修改和分发代码，同时要求保留原始版权声明和许可证条款，在分发作品或衍生作品时，可以不再公开源码。可见，与GPL相比，Apache许可证对衍生作品的要求较少。

 

（3）MIT许可证：

MIT许可证之名源自麻省理工学院（Massachusetts Institute of Technology, MIT）。MIT许可证非常宽松，允许几乎任何类型的使用、修改和分发，只需保留原始版权声明和许可声明即可。它是许多开源项目的首选，因为简单明了且限制少。

 

（4）BSD许可证：

BSD源自加州大学伯克利分校。它允许用户自由使用、修改和分发代码，但要求保留版权声明。修订版移除了原始版本中的广告条款，进一步简化了使用要求。

 

（5）EPL许可证：

Eclipse公共许可证（简称EPL）是一种开源软件发布许可证，由Eclipse基金会应用于名下的集成开发环境Eclipse上。EPL许可证允许将开源代码与专有代码混合使用，但要求修改后的代码公开。这一许可证特别适用于Eclipse项目及其插件开发。

 

2.强传染性条款和弱传染性条款

开源软件许可证中的传染性条款是保障软件自由和开放的重要机制，根据其严格程度，可以粗分为强传染性条款和弱传染性条款两大类，下面通过一些主流开源许可证进行介绍。

 

2.1强传染性条款

强传染性条款要求，如果一个项目使用了遵循特定许可证的开源代码，那么整个项目（包括新增的代码、修改的代码、结合的代码）必须采用相同的许可证，必须强制开源。这类条款的核心目标是确保开源软件的自由和开放性，防止代码被用于闭源或商业用途而不回馈社区，以下通过GPL v2许可证、GPL v3许可证、AGPL v3许可证以及OSL 3.0许可证进行展示说明：

（1）GPL v2许可证

GPL v2是基于GPL v1延伸出来的版本，其始于2001年，是目前开源软件中较为通用的具有强传染性条款的开源许可证。

 

GPL v2的第二条规定，除了“独立且单独（independent and separate works）的作品”之外，只要开发者使用了具有GPL v2的开源代码生成衍生作品，那么在分发或发布该衍生作品时，该衍生作品需要遵循GPL v2的第二条免费许可给所有第三方免费使用、复制、修改、再分发[2]。进一步地，所有第三方在使用该衍生作品再进一步开发生成衍生作品的二次衍生作品时，该二次衍生作品同样需要遵循GPL v2第二条进行免费许可。

 

（2）GPL v3许可证

GPL v3是基于GPL v2延伸出来的版本，其始于2007年，与GPL v2相比，GPL v3补充了对专利的说明、对硬件加密的要求以及使用者可以自主添加的开源许可证条款，是对GPL v2中没有声明的部分的进一步完善。

 

在GPL v3的第五条中，自由软件基金会删去了GPL v2关于“独立且单独的作品”的表述，并使用“聚合体（aggregate）”这一概念来表述若干包含GPL v3的开源程序和若干个单独运行的独立程序组合形成的程序集合，同时对“聚合体”进行的本质进行说明，从文义上看，“聚合体”与“独立且单独的作品”所要表达的内涵是一致的，均是对开源许可证的传染性条款在横向传染时的例外规定。

 

与GPL v2一致的是，在GPL v3的第五条中除了“聚合体”的例外规定，只要开发者使用了具有GPL v3的开源代码生成衍生作品，那么在分发或发布该衍生作品时，该衍生作品需要遵循GPL v3的第五条免费许可给所有第三方免费使用、复制、修改、再分发[3]。

 

（3）AGPL v3许可证

AGPL v3是GPL v3的并列版本，同样始于2007年，之所以区分开是因为AGPL v3主要应用领域在网络服务器软件领域。

 

AGPL v3与GPL v3的条款除了第十三条之外，其余条款大体内容一致，此处不作赘述。第十三条主要约定了，如果开发者使用了具有AGPL v3的开源代码生成衍生作品，且该衍生作品是通过网络服务和用户进行交互的，那么该衍生作品需要遵循AGPL v3的第十三条免费许可给所有第三方免费使用、复制、修改、再分发[4]。

 

值得注意的是，在GPL v3中，开发者需要将具有GPL v3的开源代码生成的衍生作品进行分发或者发布时才会触发传染性条款强制开源，也就是说，如果开发者仅仅自己使用而不分发具有GPL v3的开源代码生成的衍生作品是不需要开源的。而AGPL v3在其第十三条解禁了该种局限，除了开发者获得商业授权外，无论以何种方式修改或使用具有AGPL v3的开源代码生成衍生作品，都强制其进行开源。

 

（4）OSL 3.0 许可证

OSL 3.0许可证的传染性条款与GPL系列许可证的核心理念相似，由于OSL 3.0是由劳伦斯·罗森律师编写的，因此其在法律上的适用性比GPL系列许可证更强。

 

相似地，OSL 3.0第三条同样要求具有OSL 3.0 许可的开源软件所创建的衍生作品也必须提供衍生作品的源代码，并遵守OSL 3.0许可证的约定[5]。

 

2.2弱传染性条款

弱传染性条款仅要求衍生作品携带其所述的许可证，除去某些特定情况外，开发者可以对该衍生作品自由选择开源或者闭源，这种条款更加宽松，以下通过MIT许可证、Apache 2.0许可证以及LGPL v3许可证进行展示说明：

（1）MIT 许可证

MIT 具有非常宽松的传染性条款，其第一条和第二条约定了开发者可以自由使用、复制、修改、合并、出版、分发、再授权和销售具有MIT许可证的开源代码，只需要在创建其衍生作品时保留原始版权声明和原始许可声明即可[6]，而不需要像GPL v3许可证或者AGPL v3许可证的传染性条款那样强制要求整个衍生作品的其他部分也使用MIT许可证，或是在分发或使用时强制其衍生作品开源。

 

（2）Apache 2.0 许可证

Apache 2.0与MIT类似，其第四条约定了开发者可以使用额外的或不同的开源许可条款和条件，用于使用、复制或分发基于Apache 2.0 许可证的开源代码而创建的衍生作品，只需要在该衍生作品时保留原始版权声明和修改标识即可，同样不需要其衍生作品使用相同的许可证进行发布[7]。

 

特别地，由于Apache 2.0在其第六条约定了对专利的免许可使用权[8]，为开发者提供了专利方面的保障，因此Apache 2.0较MIT更为适合用于企业开发项目。

 

（3）LGPL v3 许可证

LGPL v3最初是为了支持 GPL系列许可证抢占市场而创建的，所以相比于GPL v3，LGPL v3降低了其传染性，目前，LGPL v3总共有六条，其实质上是包含了GPL v3十七条的额外补充，即LGPL v3共计二十三条。可见，LGPL v3比MIT和Apache 2.0都要复杂一些。

 

在适用领域方面，LGPL v3主要为第三方软件函数库所使用，其第三条和第四条约定了被许可方可以自由添加开源许可证，如果衍生作品的主程序动态链接到了具有LGPL v3的库，则该主程序不被传染，即该主程序可以遵循其他开源许可证[9]。例如，在一个组合作品（Combined Work）中，主程序A遵循Apache 2.0 ，数据库A遵循LGPL v3，如果主程序A动态链接到了数据库A，此时主程序A不会被数据库A感染，不必遵循LGPL v3，主程序A不需要开源，而数据库A需要开源。但是，如果开发者针对数据库A进行修改衍生出了数据库A1，根据LGPL v3第二条，开发者需要按照LGPL v3或者GPL v3分发该数据库A1。

 

无论是强传染性条款还是弱传染性条款，都是为了保护和促进软件的开放性和共享性。强传染性条款在保护开源代码的同时，可能限制了商业软件的发展；而弱传染性条款虽然提供了更多的灵活性，但也可能影响开源社区的良性发展。

 

3.纵向传染条款和横向传染条款

根据传染条款的传播路径，可以分为纵向传染条款和横向传染条款，纵向传染条款主要强制保持开源软件二次开发/修改的衍生作品的开放性，而横向传染条款则更偏向于强制保持开源软件组合的衍生作品的开放性。

 

3.1纵向传染条款

纵向传染条款指的是，当一个软件项目使用了遵循特定许可证的开源软件时，任何对该开源软件的修改或基于该开源软件的二次开发/修改所产生的新开源软件都必须继续遵循相同的许可证。

 

例如，基于GPLv3 第五条的约定[10]，如果项目A1使用了遵循GPL v3的开源库，开发者基于对项目A1的代码进行修改或者扩展，形成单独的新项目A2或者修改项目A1+，那么项目A2或者项目A1+也必须遵循GPL v3。

 

3.2横向传染条款

横向传染条款指的是：当开源代码与其他代码结合使用时，如果这种结合导致代码之间形成了“紧密结合作品”，则整个软件必须遵循上述开源许可证的条款。例如，将开源代码比作汽车发动机，将其他代码比作汽车轮胎，在运行时，汽车发动机与汽车轮胎需要共同产生联动才能使得汽车前进，这种缺一不可的结合方式即“紧密结合作品”。

 

例如，基于AGPLv3 第五条和第十三条的约定[11]，如果一个网络服务开发者使用了具有AGPL v3的开源软件A，自研软件B和开源软件A在同一个程序C中互相关联运行，则自研软件B被传染，相应地，网络服务开发者需要遵循AGPL v3的规定将程序C免费开源。

 

再举个反例，如果项目A使用了遵循LGPL v3协议的开源库，并且项目A与另一个项目B动态链接，那么基于LGPL v3第三条和第四条的约定[12]，其衍生作品必须确保库的部分遵循LGPL v3，且项目B本身可以保持闭源。

 

纵向和横向传染条款是开源许可证中两种不同的传染性条款，它们各自有不同的侧重点和影响，纵向传染条款更注重软件作品的垂直衍生性，而横向传染条款则关注软件作品的水平传播性。开发者和企业在选择开源许可证时，需要仔细考虑这些条款对自己项目的具体影响，以确保既能遵守开源精神，又能保护自身的商业利益。

 

三、司法实践中传染性的认定

 

我国法院对于开源许可证传染性条款的司法判决不多，对传染性的理解也经历了一个由保守逐渐过渡到开放的过程，体现了我国司法体系在面对新兴技术和法律问题时的逐步适应和调整，以下通过几则案例介绍这一过程：

1.数字天堂（北京）网络技术有限公司诉柚子（北京）科技有限公司、柚子（北京）移动技术有限公司侵犯计算机软件著作权纠纷案（2019年）

基本案情：数字天堂公司主张柚子公司在APICloud软件中使用了其HBuilder软件的三个插件的源代码，构成著作权侵权。柿子公司辩称，HBuilder软件使用了GPL开源代码，因此这些插件也应适用GPL协议，允许柚子公司自由使用，不构成侵权。

 

法院认为：1.涉案三个插件处于独立的文件夹中，且文件夹中均未包含GPL协议；2.HBuilder软件的根目录也不存在GPL软件协议；3.尽管HBuilder软件中包含的其他文件夹中含有GPL协议，但GPL协议对涉案三个插件并无约束力，涉案三个插件不属于应根据GPL协议开放源代码的衍生软件作品[13]。

 

本案中，法院以“独立的文件夹无GPL协议”和“根目录中无GPL协议”作为判断依据，这种做法较为形式化，忽视了GPL协议的传染性。GPL协议的目的是确保开源软件的自由传播，除了“聚合体”之外，只要衍生作品某部分使用了GPL代码，该衍生作品整体就应遵循GPL协议，无论文件夹结构如何设置。另外，从国际司法实践来看，判断是否构成衍生作品应基于代码的实际使用情况和功能依赖性，而非单纯的形式化标准。

 

2.北京闪亮时尚信息技术有限公司与不乱买电子商务（北京）有限公司侵害计算机软件著作权纠纷案（2021年）

基本案情：不乱买公司是一家电子商务公司，自主开发并运营“不乱买”网站，该网站是一个中文海淘搜索引擎，自2014年8月上线以来积累了大量用户，并享有较高知名度。闪亮时尚公司成立于2016年6月15日，经营范围与不乱买公司相似。

 

不乱买公司认为闪亮时尚公司旗下的“闪亮时刻”网站自2016年7月上线后，其网站设计、布局及源代码与“不乱买”网站实质性相同，涉嫌侵权。闪亮时尚公司认为不乱买公司软件代码因使用了大量开源软件代码，根据GPL协议及其“传染性”特性，权利软件整体均应遵循GPL协议向所有第三方无偿开源，因此闪亮时尚公司不构成侵权。

 

法院认为：前端代码与后端代码在展示方式、技术、功能等方面存在明显不同，属于独立程序，根据2007年6月29日发布的GPL协议第3版第5条关于聚合体的规定，不乱买公司的后端代码是独立于前端代码的其他程序，并不受GPL协议的约束，无需强制开源[14]。

 

本案中，法院从GPL v3为基础详细分析了传染性的例外情形，即，在“聚合体”中未使用开源代码的独立程序不受开源许可证的限制，进而否定其传染性，相对于“数字天堂诉柚子移动案”中法院依据文件夹的独立性而否定开源许可证的传染性，最高院有限地承认了开源软件的传染性条款，是一个不小的进步。

 

3.济宁市罗盒网络科技有限公司、广州市玩友网络科技有限公司等侵害计算机软件著作权纠纷案（2021年）

基本案情：罗盒公司开发了“罗盒（Virtual App）插件化框架虚拟引擎系统 V1.0”（简称“Virtual App V1.0”），该软件从2016年7月8日开始使用LGPL v3协议，后于2016年8月12日更换为GPL v3协议，2017年10月29日，罗盒公司在后续开源版本中删除了GPL v3协议的表述，并于2017年11月8日取得计算机软件著作权登记证书，享有该软件的全部著作权。

 

罗盒公司指控被告广州市玩友网络科技有限公司（简称“玩友公司”）及其关联公司在开发的微信视频美颜相机APP中，未经许可使用了Virtual App的核心代码（沙盒分身功能模块），且未遵守GPL v3协议的开源义务（如提供源代码），构成著作权侵权。玩友公司认为，Virtual App曾以GPL v3协议开源，根据其“传染性”，原告无权对开源部分主张侵权，且被告未修改或衍生代码，故无需提供源代码。

 

法院认为：对于在逻辑上与开源代码有关联性且整体发布的衍生作品，只要其中有一部分适用了GPL V3协议发布，那么整个衍生作品都必须适用GPL V3协议而公开。本案中，沙盒分身部分功能代码是作为被诉侵权软件的衍生部分而整体发布的，玩友公司并未举证证明沙盒分身功能部分源代码是独立的，或使用了类似谷歌公司的安卓系统方法，即在各个独立的不同层级框架中适用不同的开源授权许可协议，因此被诉侵权软件应整体适用GPL V3协议，玩友公司应开源整个被诉侵权软件的源代码。[15]

 

本案是国内首例法院承认开源软件具有传染性的案件，在判决中，法院对GPL v3的传染性给予了详细解释，明确了开源软件的衍生作品在分发时必须继续依照GPL v3进行开源，为广大开发者在研究、适用GPL v3时提供了司法支撑。

 

4.上海卓卓网络科技有限公司与A医院侵害计算机软件著作权纠纷案（2024年）

A医院使用DedeCMSV5.7-sp1软件开发网站，卓卓公司以其拥有DedeCMS Biz V1.0以及后续多个版本的著作权为由，认为医院侵犯了自己的著作权，要求A医院赔偿5800元的授权许可费和8700元的诉讼费用。A医院认为，DedeCMS是一款以GPL协议对外许可发布的开源软件，DedeCMS后续版本包括涉案权利软件都是在DedeCMS V3版本基础上迭代升级的，因此受GPL约束。

 

法院认为：1.本案中，涉案软件所连接的库 sphinx client 是以GPL 发布，涉案软件整体因其他部分实际与该库形成了连接，软件应当采用 GPL 或者GPL 兼容的许可证进行发布。涉案软件sphinx client与涉案软件其余部分的通信方式是程序内部的调用并非程序间的通信，故无法认定二者各为独立程序，二者应当认定为一个大程序的两个组合部分；2.卓卓公司本可以通过技术设计将遵循GPL的类库与涉案软件其他部分进行隔离或者通过联系sphinx的开发者获得商业许可这两种方式来规避GPL协议对涉案软件的影响，但卓卓公司并未采取以上措施，而是将该类库以直接调用的方式集成在涉案软件中将涉案软件进行了发布。[16]

 

本案中，法院明确了在软件中，即使是调用库存在开源许可证而主程序不存在开源许可证，只要调用库的数据被主程序所调取，主程序的源代码也会被调用库的开源许可证传染，即横向传染，这也正是前文所述的GPL与LGPL的实质区别。遗憾的是，本案还处于上诉中，终审判决如何需要进一步等待。

 

四、企业在开源软件项目中规避传染性条款的几点建议

 

1.根据传染性条款的强弱以及传染方式，选择适合自己的开源许可证类型及其版本

不同的开源许可证具有不同传染强度的传染性条款，直接影响企业对开源软件项目的使用和分发。企业应根据自身的商业目标、法律合规性和技术需求选择合适的开源许可证，例如，MIT较为宽松，允许商业用途和闭源，非常适合需要灵活性的开源软件项目；而GPL要求任何基于其的衍生作品必须开源，适合希望确保所有衍生作品都保持开源的开源软件项目。

 

有时，开发者的开发方式也会对传染性条款的选择产生影响，例如有些开发者是针对某开源软件纵向二次开发形成迭代版本，这时就需要选择MIT，因为其能在纵向上隔绝传染性；抑或者是，开发者希望通过横向开发形成组合程序，这时就可以选择LGPL，因为其能在横向上隔绝传染性。

 

同时，开发者应当保持对开源许可证版本的关注，每个开源许可证都可能产生若干版本，而每个版本的传染性条款均可能会产生变化，根据自身条件及需求正确选择开源许可证及其版本，能够在源头上规避传染性问题。

 

2.严格遵循开源许可证条款

一种很普遍的情况就是开发者对开源程序并没有太多的选择，只能基于特定的开源程序进行开发，因此开发者在使用该开源程序的时候，务必先了解该开源程序的开源许可证，因为不同的许可证对代码的使用、修改和分发设定了截然不同的规则。例如，GPL要求任何基于其开发的衍生作品必须同样以开源形式发布，而MIT或Apache则允许闭源商业使用，只需保留版权声明即可。如果开发者忽视这些条款，可能无意中触发法律风险，导致项目被迫公开核心代码，甚至面临侵权诉讼。现实中不乏因误解许可证而付出惨痛代价的案例，比如某科技公司曾因未遵守LGPL的动态链接条款，不得不支付高额赔偿并重新设计产品架构。

 

3.对于强传染性条款，需要技术隔离开源代码与自有代码

根据自由软件基金会发布的《GNU许可证常见问题》可知[17]，“聚合体”包含有多个独立的程序，并在同一个CD-ROM或其他媒体上发行，如果两个模块都包含在同一个可执行文件里，那么它们一定是一个程序的组件。如果两个模块运行时是在共享地址空间连接在一起的，那么它们几乎也构成一个组合软件。那么，使开源软件项目成为“聚合体”，即有效隔离开源代码和自有代码是当前企业面对诸如GPL协议里的强传染性条款时的一个优选举措，以下介绍几种隔离方式：

3.1套接字和命令行通信隔离：

实践中常采用的技术手段包括利用套接字和命令行实现开源代码与自有代码间的数据交换和通信，这种方式可以使开源代码和自有代码之间形成“独立且分离的程序”，保证自有代码的功能作为独立模块运行，同时自有代码可以通过约定的接口与之交互，避免了代码层面的混合。

 

3.2动态链接隔离

动态链接在运行时调用开源库的功能，而无需将开源代码嵌入到自有代码中，使得开源代码和自有代码处于分离状态，从而减少了开源许可证传染性的适用风险，这种措施特别适合具有LGPL v3的开源库与具有其它开源许可证的程序动态链接。

 

3.3接口隔离

如果自由代码与开源代码之间的接口具有清晰的定义，且该自由代码不包含任何开源代码，此时该自由代码不应该被认为是开源代码的派生作品。因此，从理论上讲，该自由代码与开源代码在功能上是相互独立的，该自由代码可以被作为能与开源代码交互的闭源代码。

 

4.建立内部开源合规管理体系

为了有效管理开源软件的使用，避免法律风险，企业需要建立一套内部开源合规管理体系。

 

这一体系应从风险评估开始，明确开源软件可能带来的法律和合规风险，例如开源许可证的传染性条款、知识产权侵权风险，同时，企业应制定明确的开源软件使用政策，规定允许使用的开源许可证，并建立审批流程，确保所有使用的开源代码都经过合规团队的审核和批准。另外，企业应设立专门的开源合规管理组织，负责监督和实施开源政策。该组织应由具备法律、技术和管理背景的专业人员组成，确保开源软件的使用符合相关法律法规。最后，企业还需要负责对员工进行培训，提升他们的合规意识和知识水平，确保每个使用开源软件的员工都了解并遵守公司的开源软件开发使用流程。

 

五、结论

 

开源许可证的传染性条款作为保障开源软件开放性和共享性的重要法律机制，在推动技术创新和协作的同时，也对企业合规和风险管理提出了更高的要求。通过本文对传染性条款的概述、分类、司法实践以及企业应对策略的系统分析，进一步明确了通过合理选择开源许可证、技术隔离开源代码、建立内部合规管理体系等方式有效利用开源许可证的传染性条款。

 

开源许可证的传染性条款既是保障开放协作的利器，也是企业合规管理的重要课题，通过深入理解传染性条款内容、借鉴司法实践经验和采取有效的应对策略，企业可以在开源软件的使用中实现合规与创新的双赢，为开源生态的繁荣和可持续发展贡献力量。