开源软件“传染性”与商业秘密“秘密性”要件冲突分析

一、问题的提出

开源是促进信息技术创新与技术资源共享的重要途径。在技术领域，开源已涵盖源代码、软硬件设计文档、源数据等多种要素，源代码始终是其主要载体。通过开源许可证，使用者只要遵守相应许可限制，即可自由获取、使用、复制、修改和再发布开源成果。[1]通过共享资源、协同开发，不断累积集体智慧，从而实现持续创新与技术进步。

然而，正是这种开放共享、协同创新的模式，与企业将其软件技术成果作为商业秘密加以保护的私有化诉求之间，产生了日益突出的制度张力。当软件产品中包含受“传染性”开源许可证（如GPL[2]系列）约束的代码时，企业能否以及如何在何种范围内主张商业秘密保护，成为理论和实务中亟待解决的难题。

所谓“传染性”，是指部分开源许可证（Copyleft型许可证）要求衍生作品必须继续以相同许可证开放源代码，以此确保开源软件的持续传播与共享。[3]这一规则与商业秘密保护的前提“不为公众所知悉”之间存在内在张力。若企业使用的开源代码触发了传染性，则其衍生代码必须公开，从而丧失秘密性；反之，若企业主张整个软件构成商业秘密，则可能规避开源义务，损害开源生态。

我国司法实践中对此类纠纷的处理呈现两种极端倾向。一种倾向是“绝对化否定”，即笼统认为软件一旦包含开源代码，则整体丧失商业秘密保护的资格。例如，在“未来案”[4]中，法院认定原告主程序因受GPL约束而不得主张版权侵权救济，类推至商业秘密领域，类似逻辑可能导致企业创新成果因少量开源代码而被完全排除保护。另一种倾向是“忽视性肯定”，即完全回避开源合规义务的审查，径行认定企业主张的代码整体构成商业秘密。例如，在“亿邦案”[5]中，最高人民法院明确表示“软件开发者自身是否违反GPLv2协议，与是否享有软件著作权，是相对独立的两个法律问题”，该立场在商业秘密案件中同样可能被援引，从而助长企业利用开源代码却闭源牟利的不诚信行为。

上述两种裁判路径均失之偏颇。前者忽视了企业独立开发的创新部分所凝结的智力劳动，不当地扩大了开源许可证的“传染”范围；后者则无视开源许可证的合同效力与公共利益，可能瓦解开源生态的信任基础。开源许可证的“传染性”义务与商业秘密的“秘密性”要件之间并非不可调和的非此即彼关系，而是需要建立一套精细化的分层评判规则。因此，需要构建“技术分离与法律分层评判”的双层审查框架，区分开源部分与独立创新部分，并分别审查企业对开源义务的履行情况，从而在维护开源生态“共享创新”初衷与保护企业合法商业秘密之间，构建清晰的司法认定规则与合规指引。

二、开源许可证义务与商业秘密构成要件剖析

（一）开源许可证类型与“传染性”义务范围

开源软件是指依照开源许可证发布的软件，其使用、发布、修改和创作衍生作品等虽然免费，但并非是无条件的，而是需要遵守各种私人自由软件团体制定的规则，即许可证（License）。通说认为许可证是一种附解除条件的版权许可合同，许可条款是版权许可的条件，如果用户违背条款规定，那么许可的前提条件就不复存在，则许可协议终止适用，用户获得的授权也将自动终止。[6]根据对衍生作品的限制程度不同，开源许可证可主要分为两大类型。[7]

第一类是“宽松型”许可证（Permissive Licenses），如MIT、BSD、Apache许可证。此类许可证允许用户将开源代码整合到专有软件中，且不要求衍生作品开放源代码。用户仅需保留原作者的版权声明和免责条款。在此类许可证下，企业完全可以将其在开源代码基础上开发的增量代码作为商业秘密保护，不存在与“传染性”的冲突。

第二类是“传染型”许可证（Copyleft Licenses），以GPL（通用公共许可证）系列为代表，包括GPLv2、GPLv3以及更严格的AGPL。此类许可证的核心要求是：若用户分发基于GPL代码的衍生作品，则必须将衍生作品的源代码以相同许可证开放。这就是“传染性”的来源。需要注意的是，传染性的触发是有条件的。以GPLv3第5条为例，只有“基于本程序的作品”或“修改版本”才受约束。具体而言：其一，触发条件是“分发”，而非内部使用；其二，传染范围限于“衍生作品”，而非任何与之交互的独立程序；其三，通过标准API调用的独立模块，若与GPL代码之间保持“适当的隔离”，可能不被传染。[8]

此外，开源许可证还包含其他义务，如版权声明义务、修改说明义务、禁止搭便车推广义务等。违反这些义务通常导致许可证自动终止，使用者不再享有授权。但就商业秘密争议而言，最关键的义务是开源义务，即是否必须公开源代码。因此，本文讨论主要围绕传染型许可证的开源义务展开。

（二）商业秘密“秘密性”要件的相对性与认定标准

根据《反不正当竞争法》第10条规定，商业秘密指不为公众所知悉、具有商业价值并经权利人采取相应保密措施的技术信息、经营信息等商业信息。即要求具有秘密性、价值性、采取保密措施。而《商业秘密保护规定》第6条进一步解释商业秘密的秘密性要件，也即“不为公众所知悉”要件，包含“不为普遍知悉”和“不容易获得”两层含义。实务中常见的误区是将“秘密性”理解为信息的绝对不公开，这导致许多包含公开信息的整体被不当排除出保护范围。然而，商业秘密的秘密性具有相对性，具体从以下几方面理解把握。

首先，部分信息的公开不影响整体信息的秘密性。《最高人民法院关于审理侵犯商业秘密民事案件适用法律若干问题的规定》（以下简称“《商业秘密司法解释》”）第4条第2款明确规定：“将为公众所知悉的信息进行整理、改进、加工后形成的新信息，符合本规定第三条规定的，应当认定该新信息不为公众所知悉。”因此软件产品中即使包含少量开源代码，其独立开发的增量代码、算法逻辑、参数配置、数据结构等，完全可能满足秘密性要求。

其次，根据《商业秘密司法解释》第3条，秘密性的判断时点是侵权行为发生时，而非软件开发时或诉讼时。企业开发过程中使用开源代码，并不当然导致后续独立开发的代码丧失秘密性，除非该独立代码因许可证义务被公开。

最后，秘密性要求的“不容易获得”应结合行业技术水平和复现成本判断。如果竞争对手通过独立研发、反向工程或合法手段（如从公开渠道获取）能够合理复现该信息，则不满足秘密性。但开源代码的存在本身并不降低企业独立开发代码的复现难度，因为竞争对手若不接触企业代码，仍可能需要投入大量资源才能实现相同功能。

因此，商业秘密的秘密性要件与开源许可证的传染性义务之间，并非简单的互斥关系。关键在于区分：哪些信息因许可证义务必须公开（从而丧失秘密性），哪些信息可以合法保密。这一区分的基础，正是下文将要构建的技术分离与法律分层评判框架。

三、司法实践争议与裁判路径批判

（一）绝对化否定阻碍实质性创新

“绝对化否定”的观点可以总结为，凡包含开源代码的软件，其整体即丧失商业秘密保护资格。这一裁判逻辑在“未来案”中表现得最为典型。该案中，原告的投标软件主程序因包含GPL开源代码且违反开源义务，法院拒绝提供版权侵权救济，理由是“保护其不当行为带来的利益不符合公平、诚信原则”。

若将该逻辑延伸至商业秘密领域，将产生严重负面影响。第一，忽视企业独立创新部分的智力贡献。软件产品往往是复杂系统，其中可能包含大量企业独立开发的算法、架构设计、参数配置等。这些部分即使不依赖任何开源代码，也可能因与开源代码“打包”而被“传染”，丧失保护。这种做法无异于“将婴儿与洗澡水一起倒掉”，严重打击企业投入研发的积极性。第二，不当扩大开源许可证的“传染”范围。GPL的传染性仅及于“衍生作品”，而非任何在同一产品中的独立模块。将少量开源代码的存在作为否定整体秘密性的依据，实质上是在司法层面创设了比GPL文本更严苛的规则，违背了许可证设计的初衷。第三，与商业秘密法基本原理相悖。商业秘密的秘密性强调信息“不被知悉”的状态，而非信息的“合法性”来源。即使企业在开发过程中存在违约行为（如违反开源义务），其独立开发的独创性部分仍可能满足秘密性要件。将开源合规瑕疵与商业秘密资格挂钩，混淆了行为评价与权利归属两个不同层次的问题。

即使权利人存在开源违规行为，该行为也只应影响其与上游开源者之间的法律关系，不应自动成为下游侵权者的“护身符”。创作过程的违法性不应当然否定独创性成果的可保护性。在非法演绎作品的保护问题上，应当区别看待创作过程中的违法行为与创作过程中产生的独创性劳动。即使是非法演绎的作品，其作者仍可能对其在创作过程中的新增独创性表达享有一定的著作权。[9]当非法演绎作品遭遇侵权时，应当允许演绎作品的版权人提起侵权之诉并获取赔偿，以保护版权人的独创性劳动、制止下游侵权行为。相反，如果因作者创作过程的违法性而否定其作品的独创性，则版权人将无法制裁非法演绎作品的下游侵权行为，最终只会放纵侵权行为的发展。[10]

这一裁判规则在软件开源语境中具有同样的适用空间。权利人违反开源协议的行为固然应予否定评价，但该否定评价不应无限扩张至其独立开发的所有代码。“违约的归违约，独创的归独创”。上游开源者可以通过违约或侵权之诉追究权利人的责任，但下游侵权者不能因权利人违反开源协议而获得无偿使用权利人独创性代码的“豁免”。将开源合规瑕疵作为否定全部商业秘密保护的理由，实质上是将本应由上游开源者行使的权利让渡给了下游侵权者，既不符合公平原则，也不符合比例原则。

因此，绝对化否定路径的错误在于，它一刀切式拒绝提供保护，而没有进行精细的技术分离和利益衡量。这一路径虽然有利于维护开源精神的纯粹性，但付出了过度抑制创新的代价。

（二）忽视性肯定损害开源生态

与绝对化否定相对，“忽视性肯定”路径则回避对开源合规义务的审查，径行认定企业软件整体构成商业秘密并给予保护。这一倾向在“亿邦案”中具有代表性。最高人民法院在该案中指出：“软件开发者自身是否违反GPLv2协议，与是否享有软件著作权，是相对独立的两个法律问题，二者不宜混为一谈。”该逻辑在商业秘密案件中可能被援引，导致法院完全不审查原告是否履行了开源义务。

例如网某科技股份有限公司与深圳万某科技有限公司等侵害计算机软件著作权纠纷、侵害商业秘密纠纷上诉案密纠纷上诉案[11]中被告深圳万某公司明确主张网某公司涉案软件“大量使用遵循开源协议的自由软件开源代码进行编译”，故不构成商业秘密。然而，最高人民法院的审理中对开源争议的处理则显得极为简略。在事实查明层面，法院仅依据鉴定意见认定涉案源代码文件不为公众所知悉，而并未对涉案代码是否包含开源成分进行审查。然而单纯的鉴定意见也只是可推翻的证据。鉴定专家很少有从事所属领域实际工作的人员，并不了解所属领域信息的全部公开渠道，难免有公开信息的遗漏。[12]在裁判理由层面，法院未对被告的开源抗辩作出实质性回应，而是以“深圳万某公司、厦门万某公司拒不提交‘*递’软件源代码，且对于前述相似性未作出合理解释”为由，径行推定侵权成立。

这一裁判逻辑存在一些缺陷。其一，在事实查明层面，被告的开源抗辩具体指向“大量使用开源代码”，法院至少应委托鉴定机构进行开源代码筛查，而非完全不查，其二，在法律适用层面，被告主张的“因含开源代码而不构成商业秘密”涉及秘密性要件的实体判断，不能单纯被“拒不提交源代码推定侵权”这一程序规则所替代。其三，在举证分配层面，法院课以被告证明独立研发的负担，但原告却无需证明其代码的合法性来源，在涉开源场景下可能导致权利人利用开源代码却无需对此作出任何说明。

从更深远的层面来看这一路径的危害同样显著。第一，鼓励企业“搭便车”行为。企业可以自由使用开源代码进行商业开发，然后以商业秘密为由拒绝公开衍生代码，实质上是将开源社群的公共成果私有化，严重违背开源许可证的契约精神。第二，损害开源生态的可持续发展。开源运动的核心机制是“互惠”，如果法律对违约闭源行为不施加任何不利后果，开源社区的信任基础将被瓦解，长期将导致高质量开源项目的萎缩。第三，与诚实信用原则相悖。企业注册账户时同意遵守开源许可证，却在诉讼中主张完全不受其约束，这种行为本身即构成权利滥用。法院若对此不闻不问，实质上是在司法层面认可了不诚信行为的合法性。

因此，忽视性肯定路径的错误在于，它将商业秘密保护与企业行为正当性完全割裂，忽视了开源许可证作为合同的法律效力以及开源生态作为公共利益的保护价值。这一路径虽有利于维护企业短期利益，但长期将侵蚀整个软件产业的创新环境。

综上，上述两种极端的共同缺陷在于缺乏对“开源部分”与“独立创新部分”的区分审查，以及对企业开源合规义务履行的个案分析。冲突的解决之道，不在于非此即彼的“全有或全无”，而在于构建精细化的分层评判框架。

四、构建冲突调适的双层审查框架

基于对上述司法实践的批判性考察，本文认为应当采用“技术分离与法律分层评判”的双层审查框架。开源许可证义务的约束对象是特定代码的“行为”（是否公开），而商业秘密秘密性的判断对象是信息的“状态”（是否已公开），两者并非同一层面的事务，亦非不可调和的非此即彼关系。法院应当在技术层面对涉案代码进行分离审查，再在法律层面对不同部分适用不同的评判规则。

（一）技术分离原则

技术分离原则要求法院在审理涉及开源软件的商业秘密案件时，首先对涉案软件进行技术层面的拆解，区分不同的代码模块及其法律属性。这是后续法律评判的事实基础。具体而言，可以区分为以下几类代码：

第一类，开源代码及其修改。指企业从开源社区直接获取的源代码，以及在此基础上进行的修改。这类代码的来源公开，且受开源许可证约束。企业对该类代码主张商业秘密保护的空间极为有限，除非企业能证明其修改部分具有非公开性且未触发许可证的开源义务（例如仅内部使用，未分发）。

第二类，独立开发代码。指企业完全独立编写的代码，未复制或借鉴任何开源代码。此类代码不受开源许可证的“传染”，当然可以单独主张商业秘密保护，前提是满足秘密性、价值性和保密措施三要件。需要注意的是，独立开发代码即使与开源代码在功能上存在交互（如通过API调用），也不当然成为“衍生作品”。根据美国自由软件基金会的官方意见，判断是否构成衍生作品的关键在于代码之间的“通信密切程度”和“内部数据结构交换”，而非简单的功能关联。[13]

第三类，混合代码。指虽未直接复制开源代码，但在开发过程中参考了开源代码的算法逻辑、架构设计等非字面元素。此类代码是否构成“衍生作品”需要个案判断。一般而言，单纯参考思想、功能或算法，而不复制具体表达，不构成版权法意义上的衍生作品，也不触发开源传染性。但若企业在开发过程中实质依赖了开源代码的内部结构，则可能被认定为衍生作品。

技术分离应遵循“最小必要”原则。只要独立开发代码能够与开源代码在技术上实现物理隔离（如不同文件、不同模块、动态链接而非静态链接），就应推定为非衍生作品，不受传染性约束。举证责任由主张传染的一方（通常为被告）承担。

（二）法律分层评判

在技术分离的基础上，法院应对不同类别的代码适用不同的法律评判标准。安某（北京）互联网科技有限公司与岭某（北京）有限公司、吴某某侵害技术秘密纠纷案[14]中较好地回应了开源代码与秘密性的关系。

涉案“吴某某应交接版源代码”明确包含三部分：开源代码（部分为GPL2.0许可证）、从第三方某朗公司获得许可的代码、吴某某自行开发的代码。法院分两个层次进行裁判。第一层，区分“开源许可证义务”与“已公开事实”。法院认为“即便GPL2.0许可证中要求使用者使用开源模块应当履行开源声明义务，但该约定仅系使用者与开源社区之间的合同关系。判断是否为公众所知悉时，应以是否对外公开源代码内容为依据，而不能仅以‘开源协议中约定有披露义务’为由即当然认为涉案技术信息不满足秘密性的构成要件”。第二层，引入“整体技术方案”判断标准。法院认为三类代码“存在内在的逻辑关联，不宜机械割裂看待”，“即便该技术整体方案中的部分技术信息可能在被诉侵权行为发生时为公众所知悉，亦不必然意味着涉案技术信息作为一个技术方案整体……为公众所普遍知悉和容易获得”。据此，法院认定涉案技术秘密整体上满足秘密性要件。

由上述案件进行延伸，对开源代码及其修改部分的审查核心是企业是否履行了开源许可证项下的义务。如果企业存在以下情形，则该部分代码不得主张商业秘密保护，且可能影响整个软件产品的合法性评价：（1）未按照许可证要求公开源代码；（2）未保留原作者的版权声明和许可证文本；（3）在分发衍生作品时未适用相同许可证。需要特别指出的是，违反开源义务的法律后果应限于丧失对该部分代码的商业秘密主张权利，且构成对开源权利人的违约或侵权。但企业是否因此丧失对整个软件产品的商业秘密资格，应区分情况。如果开源代码与独立代码在技术上无法分离（如“强传染”情形），则整个软件可能被视为衍生作品，具有开源义务，而丧失资格；如果两者可以分离，则独立部分不受影响。

当然一般情况下法院并不会要求强制开源。《民法典》第580条规定，对于“债务的标的不适于强制履行”的情形，对方不得请求强制履行。强制公开源代码要求义务人主动实施一系列复杂的技术行为，例如整理代码、撰写文档、上传至开源平台、选择许可证等，法院难以强制执行这类行为。

对独立开发部分的审查应独立于开源部分进行商业秘密三要件分析。秘密性方面，只要企业未将该部分代码公开（无论是通过分发还是其他方式），且其内容不为所属领域相关人员普遍知悉和容易获得，即满足要件。开源代码的存在本身不降低独立代码的复现难度。价值性方面，独立代码带来的技术优势或商业利益是认定价值性的直接依据。保密措施方面，企业需证明对该部分代码采取了合理的保密措施（如访问权限控制、加密、保密协议等）。

此外，关于秘密性举证责任分配的程序性规制。在涉及开源代码的商业秘密案件中，秘密性要件的举证应当遵循“初步证明—举证责任转移”的递进逻辑。权利人首先应提供初步证据，对涉案信息“不为公众所知悉”进行充分举证，通常包括权威行业机构出具的证实该领域相关人员对涉案信息知晓程度的证明、权利人已采取的具体保密措施等。在此基础上，举证责任方转移至被告方，由被告对涉案信息已被公知承担举证责任。[15]

但需要注意的是，在涉开源场景下，这一分配规则面临特殊适用困境。权利人提交的鉴定意见如果仅以“未检索到紧密关联代码”为依据认定秘密性（消极鉴定），而未主动进行开源代码扫描与排除，则该鉴定意见是否构成“初步证明”值得质疑。不能仅以“鉴定机构未发现”替代“权利人应证明”。权利人至少应证明其已对涉案代码进行过开源合规审查，或提交代码扫描报告以排除开源代码。否则，被告仍可通过对代码进行开源扫描的反证来推翻权利人的初步证明。因此，法院在审查权利人的初步举证时，应特别关注其鉴定方法是否涵盖了开源代码的主动排除，而非仅以“消极检索法”的结论作为秘密性成立的依据。

法院应最终判断整个软件产品的商业秘密保护范围。若开源代码及修改部分占比较小且可分离，法院应仅排除该部分的保护，对独立开发部分给予保护；若开源代码构成软件的“核心”且传染性不可避免（如整个软件是GPL代码的修改版本），则应认定软件整体丧失秘密性，企业不得主张商业秘密保护。但即便在后者情形下，企业仍可就其独立开发的、与核心代码可分离的插件或工具主张保护。

（三）企业合规框架重构

从企业角度，为避免陷入开源许可与商业秘密保护的冲突陷阱，应重构内部合规框架。

第一，建立开源代码清单与合规审查机制。企业在软件研发初期即应建立开源代码使用清单，记录所使用的开源组件名称、许可证类型、版本、修改情况等信息。在主张商业秘密保护时，该清单可作为区分开源部分与独立部分的证据。

第二，实施技术隔离设计。对于拟作为商业秘密保护的独立开发代码，应采取技术隔离措施，确保其与开源代码之间保持清晰的边界。例如将独立代码编译为独立模块，通过标准API与开源代码交互；避免将独立代码与开源代码静态链接或合并至同一可执行文件；在代码仓库中设立独立的目录结构，明确标注开源部分与专有部分。

第三，严格执行开源许可证义务。对于使用GPL等传染型许可证的开源代码，企业应确保：（1）在分发软件时，随附源代码或提供书面开源报价；（2）保留原作者的版权声明；（3）对衍生作品适用相同许可证。若企业无意公开衍生代码，则应避免使用GPL代码，转而使用MIT、BSD等宽松型许可证的开源替代品，或向权利人购买商业许可。

第四，完善贡献者协议与保密协议。对于开源项目的贡献者，企业应通过贡献者许可协议（CLA）明确贡献代码的著作权归属和许可范围，避免因贡献者身份不明导致商业秘密保护资格争议。同时，企业应对内部研发人员签订保密协议，明确独立开发代码不得借鉴或复制开源代码（除非经合规审查）。

第五，诉讼策略准备。在涉及商业秘密诉讼时，企业应主动向法院提交开源代码使用清单和合规证明，证明其已履行开源义务，从而避免被对手以“违反开源协议”为由攻击商业秘密资格。反之，被告企业若主张原告违反开源协议，应承担举证责任，且需证明传染性已实际波及原告主张的商业秘密密点。

五、结语

开源软件“传染性”与商业秘密“秘密性”之间的冲突，本质上是开源运动的共享理念与企业私有创新的制度张力在数字时代的集中体现。绝对化的“全有或全无”裁判路径，要么过度抑制创新，要么瓦解开源生态，均不可取。

本文提出的“技术分离与法律分层评判”框架，试图在技术事实与法律规范之间建立精细化的对接机制。技术分离原则要求法院深入软件的技术架构，区分开源代码、修改代码与独立开发代码；法律分层评判则要求对开源部分审查许可证义务履行情况，对独立部分独立审查商业秘密三要件。这一框架既尊重开源许可证的合同效力与公共价值，又保护企业独立创新的合法成果，符合比例原则和利益平衡的基本法理。

在更宏观的层面，这一框架也回应了开放式创新时代知识产权制度调适的命题。商业秘密保护与开源共享并非零和博弈，合理的规则设计可以激励企业既积极参与开源生态，又保护其核心创新资产。未来，随着开源人工智能模型、代码生成式AI等新技术的涌现，开源与闭源的边界将更加模糊，本文所构建的框架或可为更广泛场景下的权利冲突解决提供参照。

（本专题由华东政法大学知识产权专业

2025级研究生董晓杰整理、编写）