AI公司“抄代码”如何认定:软件著作权侵权的边界与证据某AI公司的几名核心研发人员离职后加入竞争企业。数月后，竞争企业上线了一款功能接近的AI应用。初步技术分析显示，两套软件的整体架构并不完全一致，大部分代码不存在直接相同，只有若干核心文件高度相似，相同部分占原软件全部业务代码的比例不足2%，部分变量名、函数名称和文件结构也已经修改。竞争企业认为，98%以上的代码都不相同，不能认定侵权；原公司则认为，离职员工参与开发，对方不可能在短期内独立完成相关模块；法务部门可能进一步认为，必须取得对方完整源代码并鉴定出较高相似率，才具备维权基础。软件著作权侵权不是一道单纯计算代码行数的数学题。相同代码比例很低，不代表一定没有侵权；离职员工参与开发，也不意味着功能相同就可以推定复制；无法取得对方完整源代码，同样不等于无法维权。真正需要回答的是：企业主张保护的是哪一套软件、哪个版本和哪些代码；相似部分是否属于开发者独立完成的程序表达；被诉方是否具有接触可能；相同或者实质性相似的内容，是复制形成，还是能够由开源代码、公共框架、技术标准、有限表达或者独立开发作出合理解释。
一、主张“代码被抄”以前，先要确定企业真正拥有哪套软件
《计算机软件保护条例》所称计算机软件，包括计算机程序及其有关文档。计算机程序既包括源程序，也包括目标程序，同一程序的源程序和目标程序属于同一作品。用于描述程序内容、组成、设计、功能规格、开发情况、测试结果和使用方法，并由开发者独立形成、固定下来的程序设计说明书、流程图、用户手册等，也可以作为软件文档受到保护。其他需求记录、测试日志和研发资料即使不构成受保护的软件文档，也可能用于证明软件版本、开发过程和权利归属。但在具体争议中，企业不能只说“对方复制了我们的AI平台”或者“抄了整个核心系统”。AI产品通常由前端界面、业务后端、模型调用层、数据处理模块、权限系统、审核模块和第三方组件共同组成，同一产品还会持续发布多个版本。权利人需要进一步明确：主张的是完整应用还是某个模块，是前端代码、后端代码、模型调用层还是嵌入式程序，是源代码、目标程序还是软件文档，对应哪个开发完成日期和版本号，争议功能在什么时间加入，后续是否经过重写，哪些代码由企业自行开发，哪些来自开源项目、供应商或者外包团队。如果保护对象始终停留在“整套系统”“全部业务代码”或者“核心平台”这样的抽象层面，后续就很难准确开展独创性筛选和侵权比对。以整个代码仓库为分母，核心模块的相似比例可能很低；以争议模块为分母，相似程度却可能很高。脱离比对范围讨论“代码相似率”，很容易得出误导性结论。软件著作权自软件开发完成之日起产生，并不以登记为生效条件。没有办理软件著作权登记，不代表企业当然没有著作权；办理了登记，也不意味着登记人对产品全部功能、算法思想和每一行代码当然享有权利。软件登记证明只是登记事项的初步证明。登记证书可以与完整源代码、设计文档、代码仓库记录、开发人员材料、权利取得合同和软件发布资料相互印证；存在相反证据时，登记记载仍可能被推翻。司法实践中常见的问题是，登记时交存的是一套代码，实际发布的是另一套版本；交存材料只包含部分代码，争议组件并不在其中；登记主体与实际开发主体不一致；或者登记完成后代码已经多次重构，企业无法还原争议发生时的具体版本。在（2022）最高法知民终670号案件中，权利人主张两个动态链接库组件受到保护，但只能提交软件登记证书和登记时交存的部分代码，无法提供争议组件对应的完整代码，也不能通过权利信息、共同缺陷或者冗余设计等其他证据明确保护对象。最高人民法院认为，权利人尚未完成初步举证，不能仅因被诉方控制相关代码，就将举证责任转移给对方。权属问题同样不能忽略。《计算机软件保护条例》第十条、第十一条和第十三条分别规定了合作开发、委托开发和职务开发的软件著作权归属。委托开发的软件首先按照书面合同确定权属；合同没有明确约定时，并不当然归支付费用的委托方。员工开发的软件是否属于单位，也要结合本职工作、明确开发目标、单位提供的物质技术条件以及责任承担方式判断。因此，发现竞品代码可疑以后，企业首先要核清的不是相似比例，而是自己的权利链：究竟有哪些代码属于企业，依据什么取得，争议发生时对应哪个版本。二、著作权保护程序表达，不保护功能、算法思想和唯一实现方式
软件著作权保护开发者独立完成并固定下来的程序表达，不延及开发软件所使用的思想、处理过程、操作方法或者数学概念。《计算机软件保护条例》还明确规定，软件开发者开发的软件由于可供选用的表达方式有限而与已经存在的软件相似，不构成侵权。在AI应用中，上传文件后进行解析，对文档进行分段、向量化和检索，通过API向大模型发送请求，对模型输出进行格式化，设置缓存、限流和重试，根据风险词触发审核，存储和调用会话记录，这些通常首先表现为功能目标、处理过程或者技术方案。两款软件都采用检索增强生成，不代表一方复制了另一方代码；都根据置信度切换模型，不代表相关判断逻辑当然属于先使用者；都实现同一行业标准接口，也不能仅因接口名称和参数形式相同认定侵权。但算法思想不受软件著作权保护，不意味着实现该思想的具体代码可以任意复制。开发者围绕相同功能，对代码结构、函数安排、数据结构、条件判断、模块拆分、错误处理、注释和特殊参数组织方式作出的具体选择，仍可能形成受到保护的程序表达。代码比对因此不能把所有相同内容同等处理。编程语言固定语法、框架自动生成模板、公共函数、常见代码片段、硬件厂商示例、技术标准规定的接口、第三方SDK、数据库自动生成代码、开源项目代码以及为兼容特定系统必须采用的表达，应当先被识别、筛选或者降低证明力。权利人不能将第三方和公共代码全部纳入自己的独创性贡献，再以整体相似为由主张权利。被诉方也不能只笼统声称“行业都这么写”或者“代码来自开源”，而不说明具体来源。如果主张来自开源项目，至少应当指出项目名称、文件位置、公开时间、版本和对应代码；如果主张由框架自动生成，应说明使用了什么框架和工具；如果主张属于标准接口，应提交相应技术标准。只有具体的来源证据，才能解释相似为何不是对权利人程序表达的复制。双方使用同一种AI编码工具，也可能生成接近的模板代码。这种情况既不能因为代码“由AI生成”就当然排除侵权，也不能因为输出相似就直接推定一方接触了另一方代码。企业仍需要说明使用了什么工具、何时生成、由谁操作、输入了什么需求、输出代码如何修改，以及是否进行过开源和相似性扫描。AI生成代码本身的权属、训练来源和许可证问题需要单独分析，本篇只将其作为代码可能相似的一种来源。三、软件复制不是“全有或全无”，复制少量独立模块也可能侵权
“相同代码必须达到多少比例才构成侵权”，是软件争议中最常见的问题，但现行法律并不存在统一的10%、30%或者50%侵权线。（2022）最高法知民终1605号案件中，被诉软件有9个文件与权利软件相同或者实质性相似，相同代码约占权利软件业务源代码的1.085%。一审以相同代码比例较低、内容较为分散为由未认定侵权。最高人民法院二审认为，复制比例不当然决定侵权行为是否成立，但会影响损害后果、主观过错和责任大小。在该案的具体证据条件下，相关9个代码文件能够实现相对独立功能，并体现了权利人的独创性表达。被诉方不能证明相似代码来自开源软件、有限表达或者其他合法来源，也未提出足以否定独创性和接触可能的相反证据，法院据此认定构成部分复制。该案并没有确立“单个代码文件当然构成独立作品”的规则。判断少量代码能否受到保护，仍然要考察其是否包含开发者自己的表达选择，是否只是简单配置、常量或者通用调用，是否能够实现相对独立功能，与其他模块能否合理区分，相似内容是否来自公开项目，以及可供选择的表达方式是否有限。核心模块的代码量可能不大，却决定软件能否完成关键功能；大段代码也可能只是框架模板和自动生成内容，独创性贡献有限。因此，代码数量、文件数量和相似比例都只能作为分析因素，不能代替保护范围判断。修改变量名、函数名和文件结构，也不能当然消除复制关系。在（2023）最高法知民终2573号案件中，法院对不同程序部分分别审查，在排除无关和第三方代码并判断相关代码独创性的基础上发现，部分被诉文件仅修改了函数名、变量名或者变量类型，其余主体及算法逻辑流程仍然一致。法院还结合执行代码、反汇编代码的高度对应、被诉软件中出现权利人的特征性字符、相关人员接触可能以及被诉方未提交源代码等事实，认定构成侵权。实际争议中，复制者可能删除原作者注释、调整文件顺序、合并或者拆分函数、增加无关代码、更换外层界面，甚至将代码转换为另一种编程语言。这些变化会降低表面文本相似度，但如果模块关系、主要程序结构、异常处理、特殊常量、非必要细节和共同缺陷仍然高度对应，仍可能被认定为对原程序表达的复制或者修改。更换编程语言不能单独证明独立开发，也不能单独证明侵权。仍需判断新程序是否在模块关系、函数组织、条件判断、异常处理、特殊常量和非必要细节等方面再现了原程序的具体表达，以及是否存在以原代码为蓝本进行转换的证据。四、“接触加实质性相似”是判断主线，鉴定相似率只是证据之一
计算机软件著作权侵权通常围绕“接触可能性”和“实质性相似”展开。接触解决的是被诉方是否可能取得权利软件，实质性相似解决的是双方是否使用了相同或者实质上相同的受保护表达。接触并不要求权利人证明被告亲自打开过每一个代码文件。核心研发人员曾在权利人处任职，双方存在外包、合作开发或者技术服务关系，被诉方曾取得源代码、SDK、测试版本或者交付包，双方共用代码仓库或者服务器，异常账户在离职前集中下载代码，都可能成为接触证据。但员工曾经任职、双方存在竞争关系、被告曾经使用过权利软件，通常只能证明接触可能，不能单独证明复制成立。还需要结合源代码、目标程序、特有信息或者其他证据，判断相似是否指向受保护的程序表达。源代码直接比对通常是最重要的证明方法之一，但鉴定报告给出的“相似率”不能脱离鉴定范围使用。比对的是完整系统还是特定模块，软件版本是否对应，源代码是否完整并能编译，是否先排除了第三方和开源代码，采用文本比对、结构比对还是反汇编比对，相似比例的分母如何确定，都会直接影响鉴定结果。技术鉴定可以说明哪些代码相同或者近似、相似部分实现什么功能、是否存在特殊对应关系，但哪些内容属于独创性表达，哪些属于公共或者有限表达，相似程度是否达到法律意义上的实质性相似，仍然属于法院结合全案证据作出的法律判断。企业无法直接取得对方服务器中的源代码时，也不必立即停止调查。根据软件形态，可以从合法取得的设备、安装包、可执行文件或者嵌入式产品中提取目标程序，比较文件名称、特殊字符串、权利人信息、错误提示和共同缺陷，并在合法、必要范围内开展技术分析。反编译或者反汇编并不是当然合法的通用取证方式。是否可以实施，应结合软件复制品的取得方式、是否绕过访问控制或者加密措施、许可协议限制、分析目的和必要范围判断。存在破坏技术措施、接触无关商业秘密或者证据真实性风险的，宜通过法院证据保全、司法鉴定或者其他受控程序完成。数据库字段、通信协议和输出内容也可以作为判断系统关系或者共同来源的间接线索，但其本身不当然属于受保护的程序表达。相关内容可能受到技术标准、兼容要求和有限表达制约，只有具有非必要、特有或者难以由独立开发解释的对应关系时，才具有较强证明力。五、没有被告源代码也可能认定侵权，但举证责任不会自动转移
软件源代码通常掌握在被诉企业手中。要求权利人在起诉前取得对方完整源代码，往往并不现实。因此，司法实践允许权利人通过接触、界面、运行结果、共同缺陷、特有字符和目标程序分析完成初步举证。在（2020）最高法知民终209号案件中，最高人民法院指出，源代码比对并非软件著作权侵权判断的必备环节。权利人已经证明被诉方存在接触可能，两款软件的可视化内容相同，并存在相同瑕疵的，可以认为其完成了与举证能力相适应的初步证明。但该案并未在二审裁定中最终认定侵权成立。被诉方在二审期间提交了载有源代码的光盘，相关证据仍需进一步质证和查明，最高人民法院最终撤销原判并发回重审。该案能够说明的是举证责任如何分配，而不是仅凭界面和瑕疵相同即可直接得出侵权结论。2026年2月28日发布的指导性案例279号进一步明确，软件著作权人能够证明被诉软件与权利软件的名称、版本号、权利人信息等特有信息相同，或者软件界面设计高度近似的，法院一般无需进行软件代码比对即可认定实质性相似，但被诉方有充分反证的除外。被诉方妨害法院证据保全的，还可能承担不利事实推定。但这一案例不能被扩大解释为“只要两个AI应用界面相似，就可以推定后台代码相同”。该案涉及企业未经许可下载安装并商业使用工业软件，保全电脑中直接显示了权利软件名称、版本和权利人信息，被诉企业还在法院现场保全过程中实施了妨害行为。其证据强度与两家企业分别开发、仅在产品界面上存在相似的情形并不相同。举证责任转移的前提，仍然是权利人先明确保护对象，并提交与其举证能力相适应的初步证据。如果权利人自己不能提供对应代码，也没有特有权利信息、共同缺陷、冗余设计或者其他高度指向复制的证据，就不能只凭功能相同和主观怀疑要求对方公开全部代码。《最高人民法院关于知识产权民事诉讼证据的若干规定》第二十五条和《最高人民法院关于民事诉讼证据的若干规定》第九十五条，均允许法院对控制证据却无正当理由拒不提交，或者毁灭、伪造、妨害证据使用的一方作出不利认定。但这些规则针对的是相关证据已经明确存在、由一方控制且法院依法要求提交的情形，并不意味着被诉企业在任何软件纠纷中都必须主动向原告开放整个代码仓库。源代码涉及被诉企业商业秘密的，可以通过法院组织比对、限定查阅人员、签署保密承诺、不公开审理或者委托鉴定等方式兼顾举证与保密。需要向法院提交证据，不等于必须向竞争对手完整披露全部源代码。“无需代码比对”的本质，不是降低软件著作权保护对象和举证基础，而是在权利对象已经明确、间接证据形成较强指向后，根据双方举证能力和证据控制情况合理分配证明责任。六、独立开发不是一句抗辩，而是一条能够还原研发过程的证据链
被诉企业面对代码侵权指控时，常见解释包括：功能由团队自行讨论形成，相似部分来自程序员习惯，使用了网上公开资料，代码由外包人员提供，双方使用了相同开源框架，代码由AI工具生成，或者离职员工没有携带原公司的任何文件。这些解释只有得到争议发生前已经形成的客观记录支持，才具有较强证明力。企业应当持续保存立项文件、需求来源、技术方案、开发任务分工、代码仓库首次提交及历次修改、分支合并和评审记录、测试及缺陷修复材料、第三方和开源组件来源、外包交付文件、AI编码工具使用和人工修改记录，以及上线包、版本号和哈希值。这些材料不要求企业为了诉讼额外制造复杂文件，而是要求研发活动本身能够被事后还原。仅在收到律师函以后补写一份“自主研发说明”，通常难以解释此前已经形成的高度相似。离职员工参与竞品开发会提高接触可能，但不当然构成侵权。原企业需要说明相关员工能够接触哪些代码，何时取得权限，是否存在异常下载、复制或者携带行为，新产品中的哪些程序表达与原软件相同。新企业则需要证明项目代码是否从空仓库逐步形成，是否禁止新员工带入前雇主文件，是否对高风险模块实施隔离开发，是否进行过代码来源声明和相似性检查。员工“凭记忆重新写出”也不是绝对免责理由。一般知识、开发经验和编程技能可以继续使用，但如果重新写出的内容实际再现了原软件中特定的代码结构、异常处理和非必要细节，仍可能构成对具体程序表达的利用。至于相关代码是否同时构成商业秘密，属于另一套保护规则，不在本篇展开。企业也不能通过委托外包切断代码侵权风险。外包方承诺“全部自主开发”，只是合同陈述，不是代码来源合法的事实证明。核心外包人员是否来自竞争企业，是否使用自有代码库、开源项目或者第三方组件，能否提交代码形成记录，发生投诉后是否配合比对，都应纳入项目管理。外包合同可以约定知识产权归属、第三方代码披露、开源组件清单、代码来源审计、侵权代码替换和损失追偿，但合同只能在双方之间分配责任，不能对抗真正的著作权人。七、企业需要同时建立权利链和开发链，而不是只做软件登记
软件登记可以为企业提供初步权利证明，但无法单独回答争议发生时究竟保护哪套代码，也不能证明企业开发过程中没有使用他人代码。权利链用于证明企业有权保护什么，至少应覆盖软件名称和版本、完整源代码及目标程序、代码形成时间、实际开发人员、职务开发材料、委托和合作开发合同、权利转让和授权文件、开源及第三方代码范围、登记资料、上线更新记录，以及争议模块与完整软件的对应关系。开发链用于证明产品如何独立形成，至少应覆盖需求和技术方案来源、代码仓库历史、开发人员和权限、组件来源、代码评审、独立测试、竞品接触、外部代码导入、AI工具使用和上线版本。两条证据链应当相互对应。登记版本找不到代码仓库记录，编译包无法对应源代码，外包交付代码没有权利转让文件，争议模块上线时间早于内部立项记录，都会削弱企业对权利来源或者独立开发的说明。对于集中招募竞争企业研发人员，并准备在较短时间内推出替代产品的AI公司，代码来源审查尤其重要。企业可以设置入职代码声明、前雇主资料禁带规则、高风险模块隔离开发、外部代码扫描和专项法务评审，降低团队有意或者无意带入他人代码的风险。发现代码来源异常后，也不宜立即删除全部记录。企业应当先固定当前代码版本、提交人和提交时间、来源说明、访问下载日志、相关设备账号、已发布版本和受影响产品，再决定隔离、重写、暂停发布或者通知供应商。未经保全就直接删除代码和提交历史，可能导致企业无法查清侵权范围，无法证明后续整改，也无法向员工、外包方或者供应商追偿。争议发生后的公证、司法鉴定、证据保全和行为保全，属于诉讼处置问题，留待后续文章系统分析。软件代码著作权保护既不能退化为“功能相同就是抄袭”，也不能被简化为“整体代码不同就没有侵权”。企业真正需要管理的，是可保护代码的版本、来源和形成过程。权利人需要证明相似部分为什么属于自己的程序表达，被诉方则需要说明相似为什么来自公共内容、合法来源或者独立开发。代码相似率只是技术证据，不是侵权结论。只有将权利对象、独创性表达、接触可能、实质性相似和合法来源放在同一条证据链中审查，才能判断一套AI软件究竟是在合法实现相同功能，还是已经跨过了复制他人代码的边界。第一时间获取AI领域合规解读、政策动态与实操指南，助您更高效地识别风险、理解规则、推动合规落地。也欢迎您转发、转载本文，让更多有需要的朋友及时看到。
夜雨聆风