编者按
2022年11月最高院做出（2021）最高法知民终2298号判决，维持深圳中院于2021年6月做出的（2019）粤03民初4519号判决，认定技术秘密侵权成立并判赔500万元。笔者作为深圳花儿绽放网络科技股份有限公司（以下简称“原告”）的委托代理人参与诉讼。较多读者希望能够从“实操”角度尽可能以“实录”方式推出代理案件的系列工作成果。由于涉案软件源代码在境外互联网平台GitHub上被披露已丧失“秘密性”，因此担心再次泄密的顾虑相对较小，且有可能大有助益法律实务工作者。为承行此愿，尽可能分享案件代理过程中的法律文书，敬请批评指正！
上一篇分享了《GitHub网站代码分享机制说明》及附件《GitHub网站代码分享机制功能介绍和使用步骤》，对GitHub分享平台有了基本的了解。本案在很大程度上是涉嫌商业秘密犯罪的，为此要有刑事的思维：一是，发现侵权行为的证据或者证据线索；二是，针对侵权行为的态度和及时采取的措施；三是，对侵权证据特别是电子数据的固定等。本案一、二审诉讼中合议庭对此均给予了关注并做出调查，与侵权和损失认定均具有关联性。
在确定侵权证据后，接下来要准备权利内容和保护范围方面的证据：一是，结合已固定的被披露的软件源代码，确定作为权利证据的软件源代码版本，并撰写技术秘密点说明文件；二是，针对技术秘密点说明文件中已明确不为公众所知悉的代码，对应软件源代码载体文件中的具体位置并做标注；三是，当技术秘密说明文件所对应的软件源代码载体文件的版本与被披露源代码版本不同时，要充分证明主张软件源代码与被披露源代码之间的关系。
本篇分四个部分对以上问题进行说明和总结，并奉上部分工作成果。
一、发现侵权行为证据与及时采取制止侵权的措施
本案中，原告将涉案技术秘密许可给被告一浙江某股份公司使用（2018年10月18日签订合同），被告一浙江某股份公司由此获得了涉案源代码（2018年10月24日交付），被告二浙江某有限公司作为被告一的唯一股东也具备了接触涉案源代码的途径。2019年4月19日，原告通过客户投诉并核实后得知，涉案源代码已于2018年12月31日被用户luxin212121在全球开源社区网站GitHub上公开披露。原告随后展开了一系列的调查和投诉活动，但直至2019年7月10日，相关链接才被GitHub网站禁用。
一审中，原告提供了《原告客户与原告员工的微信聊天截屏打印件》（详见图一），该份证据证实原告客户（涉案源码小程序另一被许可方）向原告投诉称，发现有客多软件源代码被披露在GitHub共享平台上，并提供了披露链接地址，要求原告给予合理解释，删除侵权链接，并停止支付二期授权款。
图一：《原告客户与原告员工的微信聊天截屏打印件》
接到原告客户投诉后，笔者开始积极研究GitHub平台的投诉规则以及针对不同事由的投诉途径。2019年6月20以邮件方式与平台沟通涉案源代码被非法上传的事实和请求下架事宜，并明确要求平台提供侵权用户的实名信息。直至2019年7月10日，平台才以侵犯著作权事由同意删除侵权用户的相关链接，但因未提供美国当地的司法文件，不同意提供用户实名注册信息。（详见附件《给GitHub律师函及回函邮件.pdf》）
二、非法披露涉案源代码侵权行为的证据固定与说明
2019年5月9日至21日，原告将GitHub共享平台披露涉案源代码的侵权用户luxin212121在平台上的注册信息、披露的涉案源代码和该用户发布的其他项目内容，以录视频或截屏的形式证据固化。以录视频的光盘文件为对象，将侵权用户发布的项目信息中能体现被告一和被告二公司信息的内容做了截屏，注明录频时间位置，并对全部信息进行了分组，以实现两被告公司或其员工具有非法披露涉案源代码的重大嫌疑。（详见附件《F0772固化光盘截屏文件.pdf》）
经比对，披露代码包里完全包含了原告主张的965个源代码技术秘密文件，即原告主张的技术秘密全部被公开披露。通过比对披露代码包与交付代码包，发现披露代码包作了多处修改及新增，这些修改及新增的信息均为被告二的公司信息。例如，披露代码包将交付代码中的平台注释和系统平台名称由“有客多小程序”修改为“被告二公司微店”，将交付代码包中的 “默认签名”修改为“被告二公司简称”；将交付代码中的“微俱聚logo” 修改为“被告二公司简称微店logo”，将交付代码中的客服电话400-7888-925修改为被告二公司官网客服电话；增加了权利人为被告二的版权信息等。
进一步的通过浏览用户luxin212121在GitHub上发布的其他公开存储库，发现其它存储库中含有被告二公司内部研发管理系统链接；被告二公司若干域名；被告二公司微店介绍；被告二公司版权信息；被告二公司官网介绍链接；被告二公司官网帮助支持链接；被告二公司官网联系信息链接；被告二公司办公地址；被告二公司网盟链接；被告二公司大学链接；被告二公司支付宝收款账户信息。基于上述事实，原告有充分的理由怀疑被告一、被告二及其员工非法披露了原告的技术秘密，应承担连带侵权责任。故在完成证据组织后，原告决定于2019年10月以被告一和被告二为共同被告提起技术秘密侵权之诉。
三、软件源代码技术秘密点说明文件与证据组织
（一）结合电子数据的形式和内容，妥善处理好软件源代码版本存在的问题
侵权发生后及时地固定了被披露的软件源代码（以下简称“披露源代码”），最理想的状态是以原告所保存的与被披露代码最接近的且交付给被告的软件源代码版本作为权利证据。
可通常情况却不理想，比如：（1）有可能最接近的源代码并未保存或者不符合电子数据的证据要求；（2）或者向被告交付源代码时原告未保存副本只能找到相同或相近交付时间的版本；（3）或者交付源代码后应被告的要求原告做了修改又形成了不同的版本；（4）或者甚至还有原告版本服务器发生过事故，导致源代码版本混乱的情况等。笔者曾撰写《因软件源代码技术秘密案诉讼请求的版本有误被驳回》的专题文章，希望能够引起必要的重视。[1]
首先，要以被披露源代码为对象组织证据，然后以交付时间为线索确定原告保存的最为接近的版本；请注意在这里强调了交付时间，意即包涵了被告的接触事实；其次，实务中由于交付行为不规范导致证据不完善，需要结合原告所保存的最为接近版本的电子数据属性信息比如修改时间和创建时间以及存储环境信息等证据共同实现证明目的；第三，当出现原告方所保存的一个版本的源代码无法单独实现证明目的，需要两个或者更多版本源代码作为证据共同证明的情况下，既要对所提交几个不同版本的原因以及相互之关系做说明，还要分别说明几个不同版本与被披露源代码的对应关系。
（二）针对已确定的原告保存且交付的源代码，撰写技术秘密点说明文件
撰写并提交技术秘密点说明文件并非法律强制性要求，但具有非常重要的作用，笔者建议遵照“明确”“具体”且“真实”的原则，组织相应的载体和说明文件：“明确，是指技术秘密保护的范围要明确；具体，是指保护范围的技术特征要具体；真实，是指秘密点要有载体能够证明是真实的。”[2]现结合本案中软件源代码具体情况做实操性说明。
（1）总体描述软件名称、研发情况；所使用的开发语言、平台和架构；软件运行环境和部署；软件功能模块和各模块功能介绍；软件的应用形式；软件研发过程以及所采取的保密措施等；（2）所主张的技术秘密点要能覆盖软件全部功能且包含被披露源代码，要剔除开源代码和公知代码等不属于不为公众所知悉的源代码文件；以此为原则将涉案8389个源代码文件归类为20个技术功能点，确定拟主张的979个源代码文件；（3）为了让鉴定专家更好更快的了解涉案软件源代码整体与所主张的979个源代码文件技术秘密点之间的关系，需要分别对主张的技术秘密点的功能作用与软件整体技术功能做详细说明；（4）为了明确主张的源代码文件真实存在于整体源代码包中，将979个源代码文件按照技术点分类并以表格形式列明；最终完成《有客多软件技术点说明》文件移交给鉴定机构并在一、二审法庭调查中有效地发挥作用。（详见附件《有客多软件技术点说明.pdf》）
（三）从不同的角度证明涉案源代码被披露，且是被告特别授权员工所实施
在《有客多软件技术点说明》文件中确认了979个源代码文件为技术秘密点，主张不为公众所知悉并委托鉴定机构检索、分析出具鉴定意见，这是证明涉案源代码属于不为公众所知悉的一种方法。这里有三个数字：一是涉案源代码的技术功能点20个；二是原告主张不为公众所知悉的源代码979个；三是涉案被非法披露的源代码8389个。首先，商业秘密保护的对象不是20个技术功能点，而是原告主张的不为公众所知悉的979个源代码文件这不难理解，但是不能据此认为只给予这979个源代码文件商业秘密保护，还应当包括实现20个技术功能点的涉案8389个源代码文件。因此，在证明被告的员工实施非法披露涉案源代码侵权行为时，不能仅限于委托鉴定不为公众所知悉的979个源代码文件。
在比对主张源代码文件与被披露源代码文件时发现除主张的979个源代码文件完全相同外，被披露的源代码中有若干文件与主张的源代码文件不同。进一步研究不同的源代码文件，结合涉案软件应用场景和使用流程进行分析，确信被披露的源代码为被告一和被告二公司在收到的交付代码包基础上修改后的文件，修改原因为被告需要在使用前嵌入实际运营主体的名称、logo、客服电话、收款账号等信息，方能管理运行微信小程序。组织好证据证明这一事实并充分地做好说明责任，是有效证明是被告员工且能够接触核心代码文件的特别授权员工，实施非法披露行为的重要工作内容。
本案中做了如下证据组织工作：
提交了主张的技术秘密点源代码文件与披露代码包的比对报告光盘、比对步骤说明；（详见附件《非公知代码包与披露代码包比对步骤说明.pdf》）；
将技术秘密点对应的整个源代码包与被披露的源代码包进行比对并从以下方面准备证据说明：（1）通过具体分析未主张为技术秘密的源代码文件类型，剔除开源文件、版本文件、资源文件夹、重复文件夹、数据可初始化文件夹和前端页面等不属于技术秘密的文件；（2）对剔除后的文件进一步分析，得出被披露代码包与所主张的技术秘密点源代码文件进行比对，修改了164个文件，删除了9个文件，新增了374个文件；（3）列明前述源代码文件的路径，并对具体修改的内容、增加的内容进行了详细说明。（详见附件《交付代码包与披露代码包比对说明.pdf》）
四、非公知性诉辩思路和法院对事实认定的启示
（一）一审原告以单方委托的《鉴定意见书》作为主要证据主张非公知性
前文分享了涉案软件源代码不为公众所知悉的证据准备与证据说明工作方法与基本流程，鉴定机构接受委托后就原告所主张的979个源代码文件是否属于不为公众所知悉进行鉴定，其中20个技术点对应的965个源代码文件在2018年12月31日之前不为公众所知悉。
与此证明事实有关的主要证据为第30号《鉴定意见书》记载信息如下：[3]
（1）委托人为花儿绽放公司，委托事项为花儿绽放公司的有客多软件部分源代码在2018年12月31日前是否为公众所知悉，受理日期为2019年6月27日；
（2）鉴定材料包括：①源代码光盘，一式一份，内含源代码压缩包“gongzhi.zip”和“shal.txt”,经查验gongzhi.zip的SHAI校验值与shal.txt中记载的一致；②《有客多软件技术点说明》，一式一份，共28页。依据《有客多软件技术点说明》可知，有客多软件是一款微信小程序开发工具，提供小程序行业解决方案让用户快速拥有自己的微信行业小程序。软件采用java语言，基于SpringMVC+Mybatis架构开发，软件是通过打包编译生成war包部署在阿里云平台提供服务。整个软件从业务架构上分为三层，包括业务前台、服务中台和底层架构。其中业务前台包含建站业务、电商业务、餐饮业务、名片业务、多门店业务、分销业务、互动业务、知识付费业务、社区服务等模块；服务中台包含商品SKU服务、订单服务、会员及优惠券服务、积分服务、奖品服务、活动服务、微信接口服务、短信服务、多媒体服务、资讯论坛服务、资源调度服务等模块；底层架构包含分布式部署架构、缓存架构、数据存储架构、日志整体架构、消息队列架构等。花儿绽放公司主张的20个技术点对应的979个源代码文件，涵盖了实现上述业务前台和服务中台的全部功能模块的部分源代码；
（3）检索结果：2019年6月28日至7月22日，鉴定组依据《有客多软件技术点说明》，针对有客多软件中的20个技术点对应的979个源代码文件，在谷歌、百度2个知名搜索网站，GitHub、searchcode2个软件源代码共享网站进行了搜索，检索到与上述有客多软件中14个源代码文件内容相近似的内容，未检索到与其他源代码文件内容相近似的内容；
（4）鉴定意见：有客多软件中20个技术点对应的965个源代码文件在2018年12月31日之前不为公众所知悉。
（二）被告以二审单方委托鉴定意见为证据抗辩非公知性，被部分采纳
一审中，两被告对鉴定机构未在GitHub网站上检索到被披露的有客多源代码提出了质疑。为此鉴定机构做出了合理的解释被法庭采纳：检索时间为2019年6月28日至7月22日，而GitHub网站在7月9日前已删除了被披露的有客多源代码。鉴定机构实施检索时并非必然以GitHub网站为首选，后期在GitHub网站上未检索到已被删除的源代码亦符合实际情况。
一审中，两被告公司辩称GitHub网站上关于小程序的开源项目众多，但并无相反证据推翻该鉴定意见；二审中，被告提出第30号《鉴定意见书》检索范围、检索方法有重大瑕疵，单方委托的第040号《鉴定意见书》的鉴定结论显示其中3个源代码文件属于行业惯例、在公开的代码文件中可以检索到4个与花儿绽放公司主张的涉案源代码部分相同的代码，且在2018年10月18日前，已经在开源领域存在多种与有客多软件功能相同的软件，因此第30号《鉴定意见书》的鉴定结论不应采信，并申请法院组织对涉案源代码是否“不为公众所知悉”进行重新鉴定。
（三）最高院实质审查双方单独委托的鉴定意见，分别评述是否采纳的理由
二审中，最高院认为，首先，《最高人民法院关于民事诉讼证据的若干规定》（2019修正）第四十条第一款规定，当事人申请重新鉴定，存在下列情形之一的，人民法院应当准许：（一）鉴定人不具备相应资格的；（二）鉴定程序严重违法的；（三）鉴定意见明显依据不足的；（四）鉴定意见不能作为证据使用的其他情形。第30号鉴定意见书从涉案源代码文件中提取了类名、方法名、变量名、表达式等作为关键词在百度、谷歌两个知名搜索网站及GitHub、searchcode两个软件源代码共享网站进行检索，其检索范围为知名、主流的搜索引擎及软件源代码共享网站，是所属软件领域的相关公众最常使用、访问的网站，故第30号鉴定意见书的检索方法、检索范围并无明显不当，且被告在二审期间，已经单方委托了鉴定机构对涉案技术信息是否具有非公知性进行了鉴定，故对其所提由法院组织重新鉴定的申请不予支持。
其次，根据第040号《鉴定意见书》的如下鉴定结论：
“GoodsBuyDetail.java”“Area.java”“CusmallStatisticsInfo.java”3个文件中的代码由且仅由成员变量定义及成员变量对应的geter、seter等方法组成，其中成员变量属于常见命名，该种定义成员变量并生成geXXX、setXXX等方法的形式是Java编程语言推荐的标准写法，属于所述领域的行业惯例。花儿绽放公司针对第040号鉴定意见的上述结论，未合理说明该些变量命名方式及对应生成方法的独特性，故采信第040号鉴定意见的上述意见，认定“GoodsBuyDetail.java”“Area.java”“CusmallStatisticsInfo.java”3个文件中的代码“为公众所知悉”。
第040号鉴定意见书还认为：
“AppletWxPayController.java”“AppletKoulingRedpackMobileController.java”“EmailServiceImpl.java”“HttpUtils.java”4个文件中的部分代码在2018年10月18日之前已被开源软件库公开，但均仅涉及该些文件中的部分代码片段，无法证明该些文件中的源代码整体已被公开，且代码中涉及程序的组织结构、调用关系、执行逻辑等，应将一个源代码文件作为一个整体对待，不应将一个完整代码进行部分切分而判断是否“为公众所知悉”。故对第040号《鉴定意见书》中关于4个文件中的部分代码已被公开的鉴定结论不予采信；
最后，软件源代码涉及到特定的变量名、类名及方法的定义、程序的组织结构、调用关系、执行逻辑等，还包括在特定位置对方法、语句和变量的注释文字等，软件源代码也体现了软件开发人员的代码风格、特定字词的独特表达，故即使为开发相同功能的软件，不同开发者可以设计不同的源代码进行表达，被告有关软件功能相同推论出代码相同的主张没有事实依据不予支持。
综合上述情况，鉴于第040号鉴定意见书亦认为涉案其他源代码“不为公众所知悉”，结合双方各自单独委托的第30号鉴定意见书和第040号鉴定意见书的意见，在被告未能再提出其他相反证据的情况下，最高院认定，本案中花儿绽放公司主张的涉案962个源代码文件“不为公众所知悉”。
总结：1. 原告方对非公知性事实的证明责任很重，一审、二审甚至再审审查中均是如此，笔者作为代理人对二审中对方超出举证期限提交《鉴定意见书》的做法提出了强烈的反对并书面表达了拒绝质证的意见，但是非常遗憾最高院对此未做任何否定性的评价，必然产生负面的导向作用，在此期盼能够及时予以纠正；
2. 鉴定机构和鉴定专家的作用、能力和水平层次不齐，工作的质量与态度也有很大的不同，在与其合作的过程中一方面律师团队要对自己提出更高的要求并加强自律，相关证据组织与证据说明工作必须到位，另一方面要注意提升沟通的能力务必做到让鉴定专家清楚的了解涉案技术与鉴定的目的，为确定正确的鉴定方法和流程提供有力的保障；
3. 要注意多角度思考并组织证据以有效提升证据的证明力，在多数情况下有很多的证据都存在这样或者那样的问题，特别是电子数据更是如此，较多的待证事实往往是通过多份证据组合在一起才能产生证明力，而一份证据又可能与多个待证事实相关联；
4. 庭审的压力很大因为大量的证据需要说明，要求主审法官庭审花费大量时间消化技术问题是不现实的，这就要求出庭律师对证据要非常的熟悉，法官问什么随时要能够回答且是结合证据具体内容回复，律师团队的配合非常重要，建议对系列专题做好书面的备忘录，切忌临场发挥。
注释：
[1] 参见李德成、白露著《科创版技术秘密审查与技术秘密刑事保护》法律出版社2022年11月第一版，第225、226页。
[2] 参见同上，第153页。
[3] 见（2021）最高法知民终 2298 号《民事判决书》一审法院认定事实部分。
2022年11月最高院做出（2021）最高法知民终2298号判决，维持深圳中院于2021年6月做出的（2019）粤03民初4519号判决，认定技术秘密侵权成立并判赔500万元。笔者作为深圳花儿绽放网络科技股份有限公司（以下简称“原告”）的委托代理人参与诉讼。较多读者希望能够从“实操”角度尽可能以“实录”方式推出代理案件的系列工作成果。由于涉案软件源代码在境外互联网平台GitHub上被披露已丧失“秘密性”，因此担心再次泄密的顾虑相对较小，且有可能大有助益法律实务工作者。为承行此愿，尽可能分享案件代理过程中的法律文书，敬请批评指正！
上一篇分享了《GitHub网站代码分享机制说明》及附件《GitHub网站代码分享机制功能介绍和使用步骤》，对GitHub分享平台有了基本的了解。本案在很大程度上是涉嫌商业秘密犯罪的，为此要有刑事的思维：一是，发现侵权行为的证据或者证据线索；二是，针对侵权行为的态度和及时采取的措施；三是，对侵权证据特别是电子数据的固定等。本案一、二审诉讼中合议庭对此均给予了关注并做出调查，与侵权和损失认定均具有关联性。
在确定侵权证据后，接下来要准备权利内容和保护范围方面的证据：一是，结合已固定的被披露的软件源代码，确定作为权利证据的软件源代码版本，并撰写技术秘密点说明文件；二是，针对技术秘密点说明文件中已明确不为公众所知悉的代码，对应软件源代码载体文件中的具体位置并做标注；三是，当技术秘密说明文件所对应的软件源代码载体文件的版本与被披露源代码版本不同时，要充分证明主张软件源代码与被披露源代码之间的关系。
本篇分四个部分对以上问题进行说明和总结，并奉上部分工作成果。
一、发现侵权行为证据与及时采取制止侵权的措施
本案中，原告将涉案技术秘密许可给被告一浙江某股份公司使用（2018年10月18日签订合同），被告一浙江某股份公司由此获得了涉案源代码（2018年10月24日交付），被告二浙江某有限公司作为被告一的唯一股东也具备了接触涉案源代码的途径。2019年4月19日，原告通过客户投诉并核实后得知，涉案源代码已于2018年12月31日被用户luxin212121在全球开源社区网站GitHub上公开披露。原告随后展开了一系列的调查和投诉活动，但直至2019年7月10日，相关链接才被GitHub网站禁用。
一审中，原告提供了《原告客户与原告员工的微信聊天截屏打印件》（详见图一），该份证据证实原告客户（涉案源码小程序另一被许可方）向原告投诉称，发现有客多软件源代码被披露在GitHub共享平台上，并提供了披露链接地址，要求原告给予合理解释，删除侵权链接，并停止支付二期授权款。
图一：《原告客户与原告员工的微信聊天截屏打印件》
接到原告客户投诉后，笔者开始积极研究GitHub平台的投诉规则以及针对不同事由的投诉途径。2019年6月20以邮件方式与平台沟通涉案源代码被非法上传的事实和请求下架事宜，并明确要求平台提供侵权用户的实名信息。直至2019年7月10日，平台才以侵犯著作权事由同意删除侵权用户的相关链接，但因未提供美国当地的司法文件，不同意提供用户实名注册信息。（详见附件《给GitHub律师函及回函邮件.pdf》）
二、非法披露涉案源代码侵权行为的证据固定与说明
2019年5月9日至21日，原告将GitHub共享平台披露涉案源代码的侵权用户luxin212121在平台上的注册信息、披露的涉案源代码和该用户发布的其他项目内容，以录视频或截屏的形式证据固化。以录视频的光盘文件为对象，将侵权用户发布的项目信息中能体现被告一和被告二公司信息的内容做了截屏，注明录频时间位置，并对全部信息进行了分组，以实现两被告公司或其员工具有非法披露涉案源代码的重大嫌疑。（详见附件《F0772固化光盘截屏文件.pdf》）
经比对，披露代码包里完全包含了原告主张的965个源代码技术秘密文件，即原告主张的技术秘密全部被公开披露。通过比对披露代码包与交付代码包，发现披露代码包作了多处修改及新增，这些修改及新增的信息均为被告二的公司信息。例如，披露代码包将交付代码中的平台注释和系统平台名称由“有客多小程序”修改为“被告二公司微店”，将交付代码包中的 “默认签名”修改为“被告二公司简称”；将交付代码中的“微俱聚logo” 修改为“被告二公司简称微店logo”，将交付代码中的客服电话400-7888-925修改为被告二公司官网客服电话；增加了权利人为被告二的版权信息等。
进一步的通过浏览用户luxin212121在GitHub上发布的其他公开存储库，发现其它存储库中含有被告二公司内部研发管理系统链接；被告二公司若干域名；被告二公司微店介绍；被告二公司版权信息；被告二公司官网介绍链接；被告二公司官网帮助支持链接；被告二公司官网联系信息链接；被告二公司办公地址；被告二公司网盟链接；被告二公司大学链接；被告二公司支付宝收款账户信息。基于上述事实，原告有充分的理由怀疑被告一、被告二及其员工非法披露了原告的技术秘密，应承担连带侵权责任。故在完成证据组织后，原告决定于2019年10月以被告一和被告二为共同被告提起技术秘密侵权之诉。
三、软件源代码技术秘密点说明文件与证据组织
（一）结合电子数据的形式和内容，妥善处理好软件源代码版本存在的问题
侵权发生后及时地固定了被披露的软件源代码（以下简称“披露源代码”），最理想的状态是以原告所保存的与被披露代码最接近的且交付给被告的软件源代码版本作为权利证据。
可通常情况却不理想，比如：（1）有可能最接近的源代码并未保存或者不符合电子数据的证据要求；（2）或者向被告交付源代码时原告未保存副本只能找到相同或相近交付时间的版本；（3）或者交付源代码后应被告的要求原告做了修改又形成了不同的版本；（4）或者甚至还有原告版本服务器发生过事故，导致源代码版本混乱的情况等。笔者曾撰写《因软件源代码技术秘密案诉讼请求的版本有误被驳回》的专题文章，希望能够引起必要的重视。[1]
首先，要以被披露源代码为对象组织证据，然后以交付时间为线索确定原告保存的最为接近的版本；请注意在这里强调了交付时间，意即包涵了被告的接触事实；其次，实务中由于交付行为不规范导致证据不完善，需要结合原告所保存的最为接近版本的电子数据属性信息比如修改时间和创建时间以及存储环境信息等证据共同实现证明目的；第三，当出现原告方所保存的一个版本的源代码无法单独实现证明目的，需要两个或者更多版本源代码作为证据共同证明的情况下，既要对所提交几个不同版本的原因以及相互之关系做说明，还要分别说明几个不同版本与被披露源代码的对应关系。
（二）针对已确定的原告保存且交付的源代码，撰写技术秘密点说明文件
撰写并提交技术秘密点说明文件并非法律强制性要求，但具有非常重要的作用，笔者建议遵照“明确”“具体”且“真实”的原则，组织相应的载体和说明文件：“明确，是指技术秘密保护的范围要明确；具体，是指保护范围的技术特征要具体；真实，是指秘密点要有载体能够证明是真实的。”[2]现结合本案中软件源代码具体情况做实操性说明。
（1）总体描述软件名称、研发情况；所使用的开发语言、平台和架构；软件运行环境和部署；软件功能模块和各模块功能介绍；软件的应用形式；软件研发过程以及所采取的保密措施等；（2）所主张的技术秘密点要能覆盖软件全部功能且包含被披露源代码，要剔除开源代码和公知代码等不属于不为公众所知悉的源代码文件；以此为原则将涉案8389个源代码文件归类为20个技术功能点，确定拟主张的979个源代码文件；（3）为了让鉴定专家更好更快的了解涉案软件源代码整体与所主张的979个源代码文件技术秘密点之间的关系，需要分别对主张的技术秘密点的功能作用与软件整体技术功能做详细说明；（4）为了明确主张的源代码文件真实存在于整体源代码包中，将979个源代码文件按照技术点分类并以表格形式列明；最终完成《有客多软件技术点说明》文件移交给鉴定机构并在一、二审法庭调查中有效地发挥作用。（详见附件《有客多软件技术点说明.pdf》）
（三）从不同的角度证明涉案源代码被披露，且是被告特别授权员工所实施
在《有客多软件技术点说明》文件中确认了979个源代码文件为技术秘密点，主张不为公众所知悉并委托鉴定机构检索、分析出具鉴定意见，这是证明涉案源代码属于不为公众所知悉的一种方法。这里有三个数字：一是涉案源代码的技术功能点20个；二是原告主张不为公众所知悉的源代码979个；三是涉案被非法披露的源代码8389个。首先，商业秘密保护的对象不是20个技术功能点，而是原告主张的不为公众所知悉的979个源代码文件这不难理解，但是不能据此认为只给予这979个源代码文件商业秘密保护，还应当包括实现20个技术功能点的涉案8389个源代码文件。因此，在证明被告的员工实施非法披露涉案源代码侵权行为时，不能仅限于委托鉴定不为公众所知悉的979个源代码文件。
在比对主张源代码文件与被披露源代码文件时发现除主张的979个源代码文件完全相同外，被披露的源代码中有若干文件与主张的源代码文件不同。进一步研究不同的源代码文件，结合涉案软件应用场景和使用流程进行分析，确信被披露的源代码为被告一和被告二公司在收到的交付代码包基础上修改后的文件，修改原因为被告需要在使用前嵌入实际运营主体的名称、logo、客服电话、收款账号等信息，方能管理运行微信小程序。组织好证据证明这一事实并充分地做好说明责任，是有效证明是被告员工且能够接触核心代码文件的特别授权员工，实施非法披露行为的重要工作内容。
本案中做了如下证据组织工作：
提交了主张的技术秘密点源代码文件与披露代码包的比对报告光盘、比对步骤说明；（详见附件《非公知代码包与披露代码包比对步骤说明.pdf》）；
将技术秘密点对应的整个源代码包与被披露的源代码包进行比对并从以下方面准备证据说明：（1）通过具体分析未主张为技术秘密的源代码文件类型，剔除开源文件、版本文件、资源文件夹、重复文件夹、数据可初始化文件夹和前端页面等不属于技术秘密的文件；（2）对剔除后的文件进一步分析，得出被披露代码包与所主张的技术秘密点源代码文件进行比对，修改了164个文件，删除了9个文件，新增了374个文件；（3）列明前述源代码文件的路径，并对具体修改的内容、增加的内容进行了详细说明。（详见附件《交付代码包与披露代码包比对说明.pdf》）
四、非公知性诉辩思路和法院对事实认定的启示
（一）一审原告以单方委托的《鉴定意见书》作为主要证据主张非公知性
前文分享了涉案软件源代码不为公众所知悉的证据准备与证据说明工作方法与基本流程，鉴定机构接受委托后就原告所主张的979个源代码文件是否属于不为公众所知悉进行鉴定，其中20个技术点对应的965个源代码文件在2018年12月31日之前不为公众所知悉。
与此证明事实有关的主要证据为第30号《鉴定意见书》记载信息如下：[3]
（1）委托人为花儿绽放公司，委托事项为花儿绽放公司的有客多软件部分源代码在2018年12月31日前是否为公众所知悉，受理日期为2019年6月27日；
（2）鉴定材料包括：①源代码光盘，一式一份，内含源代码压缩包“gongzhi.zip”和“shal.txt”,经查验gongzhi.zip的SHAI校验值与shal.txt中记载的一致；②《有客多软件技术点说明》，一式一份，共28页。依据《有客多软件技术点说明》可知，有客多软件是一款微信小程序开发工具，提供小程序行业解决方案让用户快速拥有自己的微信行业小程序。软件采用java语言，基于SpringMVC+Mybatis架构开发，软件是通过打包编译生成war包部署在阿里云平台提供服务。整个软件从业务架构上分为三层，包括业务前台、服务中台和底层架构。其中业务前台包含建站业务、电商业务、餐饮业务、名片业务、多门店业务、分销业务、互动业务、知识付费业务、社区服务等模块；服务中台包含商品SKU服务、订单服务、会员及优惠券服务、积分服务、奖品服务、活动服务、微信接口服务、短信服务、多媒体服务、资讯论坛服务、资源调度服务等模块；底层架构包含分布式部署架构、缓存架构、数据存储架构、日志整体架构、消息队列架构等。花儿绽放公司主张的20个技术点对应的979个源代码文件，涵盖了实现上述业务前台和服务中台的全部功能模块的部分源代码；
（3）检索结果：2019年6月28日至7月22日，鉴定组依据《有客多软件技术点说明》，针对有客多软件中的20个技术点对应的979个源代码文件，在谷歌、百度2个知名搜索网站，GitHub、searchcode2个软件源代码共享网站进行了搜索，检索到与上述有客多软件中14个源代码文件内容相近似的内容，未检索到与其他源代码文件内容相近似的内容；
（4）鉴定意见：有客多软件中20个技术点对应的965个源代码文件在2018年12月31日之前不为公众所知悉。
（二）被告以二审单方委托鉴定意见为证据抗辩非公知性，被部分采纳
一审中，两被告对鉴定机构未在GitHub网站上检索到被披露的有客多源代码提出了质疑。为此鉴定机构做出了合理的解释被法庭采纳：检索时间为2019年6月28日至7月22日，而GitHub网站在7月9日前已删除了被披露的有客多源代码。鉴定机构实施检索时并非必然以GitHub网站为首选，后期在GitHub网站上未检索到已被删除的源代码亦符合实际情况。
一审中，两被告公司辩称GitHub网站上关于小程序的开源项目众多，但并无相反证据推翻该鉴定意见；二审中，被告提出第30号《鉴定意见书》检索范围、检索方法有重大瑕疵，单方委托的第040号《鉴定意见书》的鉴定结论显示其中3个源代码文件属于行业惯例、在公开的代码文件中可以检索到4个与花儿绽放公司主张的涉案源代码部分相同的代码，且在2018年10月18日前，已经在开源领域存在多种与有客多软件功能相同的软件，因此第30号《鉴定意见书》的鉴定结论不应采信，并申请法院组织对涉案源代码是否“不为公众所知悉”进行重新鉴定。
（三）最高院实质审查双方单独委托的鉴定意见，分别评述是否采纳的理由
二审中，最高院认为，首先，《最高人民法院关于民事诉讼证据的若干规定》（2019修正）第四十条第一款规定，当事人申请重新鉴定，存在下列情形之一的，人民法院应当准许：（一）鉴定人不具备相应资格的；（二）鉴定程序严重违法的；（三）鉴定意见明显依据不足的；（四）鉴定意见不能作为证据使用的其他情形。第30号鉴定意见书从涉案源代码文件中提取了类名、方法名、变量名、表达式等作为关键词在百度、谷歌两个知名搜索网站及GitHub、searchcode两个软件源代码共享网站进行检索，其检索范围为知名、主流的搜索引擎及软件源代码共享网站，是所属软件领域的相关公众最常使用、访问的网站，故第30号鉴定意见书的检索方法、检索范围并无明显不当，且被告在二审期间，已经单方委托了鉴定机构对涉案技术信息是否具有非公知性进行了鉴定，故对其所提由法院组织重新鉴定的申请不予支持。
其次，根据第040号《鉴定意见书》的如下鉴定结论：
“GoodsBuyDetail.java”“Area.java”“CusmallStatisticsInfo.java”3个文件中的代码由且仅由成员变量定义及成员变量对应的geter、seter等方法组成，其中成员变量属于常见命名，该种定义成员变量并生成geXXX、setXXX等方法的形式是Java编程语言推荐的标准写法，属于所述领域的行业惯例。花儿绽放公司针对第040号鉴定意见的上述结论，未合理说明该些变量命名方式及对应生成方法的独特性，故采信第040号鉴定意见的上述意见，认定“GoodsBuyDetail.java”“Area.java”“CusmallStatisticsInfo.java”3个文件中的代码“为公众所知悉”。
第040号鉴定意见书还认为：
“AppletWxPayController.java”“AppletKoulingRedpackMobileController.java”“EmailServiceImpl.java”“HttpUtils.java”4个文件中的部分代码在2018年10月18日之前已被开源软件库公开，但均仅涉及该些文件中的部分代码片段，无法证明该些文件中的源代码整体已被公开，且代码中涉及程序的组织结构、调用关系、执行逻辑等，应将一个源代码文件作为一个整体对待，不应将一个完整代码进行部分切分而判断是否“为公众所知悉”。故对第040号《鉴定意见书》中关于4个文件中的部分代码已被公开的鉴定结论不予采信；
最后，软件源代码涉及到特定的变量名、类名及方法的定义、程序的组织结构、调用关系、执行逻辑等，还包括在特定位置对方法、语句和变量的注释文字等，软件源代码也体现了软件开发人员的代码风格、特定字词的独特表达，故即使为开发相同功能的软件，不同开发者可以设计不同的源代码进行表达，被告有关软件功能相同推论出代码相同的主张没有事实依据不予支持。
综合上述情况，鉴于第040号鉴定意见书亦认为涉案其他源代码“不为公众所知悉”，结合双方各自单独委托的第30号鉴定意见书和第040号鉴定意见书的意见，在被告未能再提出其他相反证据的情况下，最高院认定，本案中花儿绽放公司主张的涉案962个源代码文件“不为公众所知悉”。
总结：1. 原告方对非公知性事实的证明责任很重，一审、二审甚至再审审查中均是如此，笔者作为代理人对二审中对方超出举证期限提交《鉴定意见书》的做法提出了强烈的反对并书面表达了拒绝质证的意见，但是非常遗憾最高院对此未做任何否定性的评价，必然产生负面的导向作用，在此期盼能够及时予以纠正；
2. 鉴定机构和鉴定专家的作用、能力和水平层次不齐，工作的质量与态度也有很大的不同，在与其合作的过程中一方面律师团队要对自己提出更高的要求并加强自律，相关证据组织与证据说明工作必须到位，另一方面要注意提升沟通的能力务必做到让鉴定专家清楚的了解涉案技术与鉴定的目的，为确定正确的鉴定方法和流程提供有力的保障；
3. 要注意多角度思考并组织证据以有效提升证据的证明力，在多数情况下有很多的证据都存在这样或者那样的问题，特别是电子数据更是如此，较多的待证事实往往是通过多份证据组合在一起才能产生证明力，而一份证据又可能与多个待证事实相关联；
4. 庭审的压力很大因为大量的证据需要说明，要求主审法官庭审花费大量时间消化技术问题是不现实的，这就要求出庭律师对证据要非常的熟悉，法官问什么随时要能够回答且是结合证据具体内容回复，律师团队的配合非常重要，建议对系列专题做好书面的备忘录，切忌临场发挥。
注释：
[1] 参见李德成、白露著《科创版技术秘密审查与技术秘密刑事保护》法律出版社2022年11月第一版，第225、226页。
[2] 参见同上，第153页。
[3] 见（2021）最高法知民终 2298 号《民事判决书》一审法院认定事实部分。