AI逆向火了:把别人的软件重做一遍,法律允许吗?

不拿源代码，不直接复制文件，甚至换一种编程语言。看上去，整个过程都是"重新开发"。

这也是 AI 逆向最容易引起争议的地方：原开发者觉得自己的研发成果被快速复用，重写者则认为，自己只是学会了实现方法。

站在法律上，这两种说法都不能直接决定结果。判断要沿着"取得材料—分析研究—重写使用"这条线走。

一、软件闭源，不等于别人不能研究

先解释一下，这里说的"AI 逆向"，是借助 AI 分析已有软件的运行行为、程序文件或者接口信息，理解它的实现方式，有时再据此开发新软件。

但"分析"这两个字底下，藏着三种完全不同的做法，法律上的分量也完全不一样。对这类分析，法律上早就按"接触到了多深"分出了层次。

一种是只看行为。把软件当黑盒，正常使用，观察它吃什么输入、吐什么输出、怎么响应用户操作。这条路你从头到尾没打开过它的程序文件。

一种是看接口。抓包看它和服务器之间传了什么，调它开放的 API，看返回了什么数据。你接触到的是数据、协议和调用规则，不是程序本身。

还有一种是看代码。把它反编译，读出伪代码，或者拿到内部技术文档、错误信息库。到这一步，你手里握着的，已经是别人写出来的具体表达了。

这个区分很重要，因为法律评价的起点不是"你研究了它"，而是 “你研究到了什么东西”。

软件著作权有明确的保护边界。《计算机软件保护条例》第六条把"开发软件所用的思想、处理过程、操作方法或者数学概念等"排除在保护范围之外。一款软件可以自动整理发票，你研究它如何分类、如何检索，再自己开发一个同样能整理发票的工具，仅凭功能相同，通常不足以认定侵权。第十七条也为研究留了空间：为了学习和研究软件内含的设计思想和原理，通过安装、显示、传输或者存储等方式使用软件的，可以不经软件著作权人许可，不向其支付报酬。

再往前一步，《著作权法》第五十条第一款第（五）项甚至允许为"计算机软件反向工程研究"避开技术措施。这是中国法上少见的、明文给"软件反向工程研究"留位置的条款。

但这一层层让出来的，都是"研究"的空间，不是"照搬"的许可。第六条划的是思想与表达的界，第十七条管的是"使用软件"这一环，而第五十条在给出例外之后，紧接着就写了一句话——不得向他人提供避开技术措施的技术、装置或者部件，不得侵犯权利人依法享有的其他权利。允许你自己看，不等于允许你把看到的东西原样搬走。

原开发者投入了大量时间和资金，值得尊重，但这不意味着他可以通过著作权独占某种功能。反过来，研究者也不能把"功能不受保护"当成万能挡箭牌。

二、"代码重新写了"，为什么还可能侵权？

假设另一位开发者拿到了原软件的代码，让 AI 换变量名、调整函数顺序，再改写成另一种语言。

生成的文件是新的，运行环境是新的，连编程语言都不一样。但这与"观察功能后独立实现"，显然不是一回事。

判断软件著作权侵权，要过两关：有没有接触原软件的条件，以及两套代码有没有实质性相似。前者是机会，后者是结果，缺一条都不足以定案。

先说相似这一关。看的是受保护的具体表达有没有被利用。改代码的外观，不一定消除了原有表达。法院比的是两套代码在整体上有没有实质性相似，而不是逐行数有没有一样的字——你把变量名全换一遍、函数挪个位置，整体的相似程度并不会因此改变。

这个标准，最高人民法院（2020）最高法知民终 1164 号判决（新思公司诉芯动公司软件著作权案）讲得很清楚：软件构成"实质性相似"有两种情形，一是文字成分的相似，以程序代码中引用的百分比为依据；二是非文字成分的相似，即以"整体上的相似"为依据——所谓整体上的相似，指的是两套软件在程序的组织结构、处理流程、所采用的数据结构等方面实质相似。换句话说，就算一个字符都没抄，骨架搭得一模一样，也可能落进这一条。

北京知识产权法院公开过一起游戏软件侵权案。被告把文件名、类名、字段名做了机械替换，还删掉一批无关代码，指望常规比对工具认不出来。但技术调查官打开一看，某些类的定义里，变量定义、参数取值、方法实现几乎完全一致，区别只在类名和变量名——法院最终认定两套软件构成实质性相似。机器批量改名，逃不过比对。

反过来也要说清楚：两段代码有相同之处，也不必然侵权。通用写法、行业惯例、因可选表达方式有限而必然相似的部分，本身不受保护。《计算机软件保护条例》第二十九条规定，由于可供选用的表达方式有限而与已经存在的软件相似的，不构成对已有软件著作权的侵犯。

再说接触这一关，还有一条容易被忽略的规则。最高人民法院指导性案例279号明确：软件著作权人如果能举证证明被诉软件与权利软件在名称、版本号、权利人信息等特有信息上相同，或者界面设计高度近似，法院一般不需要进行代码比对，就可以认定实质性相似。

这条规则对做重写项目的人是一个提醒：比对的对象从来不止代码本身。你把代码让AI全改一遍，但界面还沿用原来的样式、报错提示还是原话、内部标记还留在文件里，比对不会因为你换了语言就停下来。

再往前一点，最高人民法院2026年9月发布的《关于依法审理涉人工智能纠纷案件的意见》第十二条，把这条规则推到了AI场景：人工智能使用者知道或者应当知道在先作品，利用人工智能生成与在先作品实质相似的作品，且没有合理使用等免责事由的，应当认定构成侵权。

它同时给出了举证路径，这一点对做事的人比结论更重要：权利人主张使用者侵权，先要举证使用者接触过在先作品，或者有接触的可能。一旦存在接触可能，就推定使用者知道在先作品的存在，使用者要想脱身，得自己拿出证据推翻这个推定。AI让生成变得容易了，但"接触"这一步反而更容易留下痕迹——谁登过账号、谁下过载、谁在离职前批量导出过文件，都是记录。

还有一种情况更容易被忽略：代码确实是独立写的，但界面里的插画、图标、帮助文档直接沿用了原软件。代码层面的独立开发，替这些内容解决不了授权问题——它们各有各的权利人。

所以，"AI生成的""换过语言了""相似率很低"，这三个理由单独拿出来，都不能得出不侵权的结论。

三、真正敏感的，往往是"材料从哪里来"

再换一个场景。

某位前员工带着原公司的内部技术文档加入新团队，新团队让 AI 根据这份文档重新生成一套代码。最终代码和原软件差别很大，是不是就没有问题？

仍然可能涉及商业秘密。

著作权不保护的某些算法思路、技术流程，如果符合条件，可以走商业秘密这条路。条件是三个：不为公众所知悉，具有商业价值，权利人采取了相应的保密措施。

什么算技术信息，现在有了明确的列举。2026年6月1日起施行的《商业秘密保护规定》第五条第二款规定，与技术有关的结构、原料、配方、材料、样品、样式、工艺、方法、数据、算法、计算机程序、代码等信息，都属于技术信息。算法、数据结构、接口参数、核心代码，只要确实具有秘密性和价值、企业也确实管住了，就可能落在这个范围里。

代码表达变了，不等于"用了别人的秘密信息"这个事实也跟着消失。前面那个场景里，新团队的实现方式再独立，起点是那份不该拿走的文档，这一点绕不过去。

当然，闭源本身说明不了什么。源代码没公开，不等于里面全部内容都是商业秘密，权利人还得说清楚具体保护的是什么、又是怎么保护的。

反过来说，法律也确实给合法的反向工程留了空间。这个空间有两个来源。

一是《最高人民法院关于审理侵犯商业秘密民事案件适用法律若干问题的规定》第十四条：通过自行开发研制或者反向工程获得被诉侵权信息的，人民法院应当认定不属于反不正当竞争法第九条规定的侵犯商业秘密行为。它把反向工程界定为"通过技术手段对从公开渠道取得的产品进行拆卸、测绘、分析等而获得该产品的有关技术信息"。

二是《商业秘密保护规定》第十五条，把这条规则写得更具体：独立发现或者自行研发，对从公开渠道取得的产品进行拆卸、测绘、分析等而获得有关技术信息，一般不属于侵犯商业秘密。同一部规章还提到，前员工利用工作中积累的通用知识、技能、行业经验开展工作，一般也不属于侵权。

但这条规则有一道反向边界，写在《最高人民法院关于审理侵犯商业秘密民事案件适用法律若干问题的规定》第十四条第三款：被诉侵权人以不正当手段获取权利人的商业秘密后，又以反向工程为由主张未侵犯商业秘密的，人民法院不予支持。

说到底，"先偷到手、再补一个拆解过程"这条路走不通。这也解释了为什么两个技术上极其相似的项目，法律评价可能完全不同：一个从公开渠道买来正版自己拆，一个从泄露的内部资料出发。AI参与了后续开发，也改不了起点上的差别。

四、研究、破解和上线销售，要分开算

软件逆向常常要绕开加密或者其他访问限制，但"绕过了限制就一定违法"同样说不通。

《著作权法》第四十九条和第五十条要分开看。第四十九条给技术措施下了定义，并禁止故意避开或者破坏。第五十条列的是可以避开技术措施的情形，第（五）项就是"进行加密研究或者计算机软件反向工程研究"。

但第五十条在开头就设了一句限制，前面已经提到过：不得向他人提供避开技术措施的技术、装置或者部件。

所以"我在做研究"这句话，最多只覆盖整条链上的一小段。它管的是"你为了研究而绕过加密"这一步。研究本身可以，把破解工具打包发出去不行。自己看可以，传播未经授权的软件不行。为研究而拆解，和上线卖一套功能一样的产品，是两件事，要分别判断。

研究完了，项目往往还要面对另外几条线：要用的技术方案，有没有落在别人的专利权利要求里。点过的那份许可协议有没有效、管不管你的用法。交给AI的材料里，有没有你本来无权对外提供的东西。这几件事各有各的判断条件，不能靠"代码是我自己生成的"一句话一并解决。

五、AI 介入之后，"独立开发"要靠什么证明

行业里对付这件事有个老办法，叫净室。它的关键不在分工，而在制造一段可以被证明的空白：让最终写代码的人，从头到尾没有机会接触原软件——既没读过它的代码，也没看过拆解它的产物，他手上只有一份描述"这软件要做什么"的说明书。这段空白守得住，日后被诉时才拿得出来，证明新代码是独立长出来的。

问题是，AI一来，这段空白保不住了。

传统净室能成立，靠的是一个前提：读的人不写，写的人不读。AI 把这个前提取消了——分析目标软件的和生成新代码的，往往就是同一个模型、同一次会话。中间那道原本由人承担的隔离，现在没有谁来承担。模型的训练语料你也看不到，它在这一步到底"看"了什么、参照了什么，既没法审计，也没法向法庭解释。

这一点目前还没有判例支撑，理论上争议很大，但它已经足够说明：过去那套自证独立的方法，不够用了。

有人会说，那就退回去，照老办法分成两个组——一组负责分析、输出规格，一组负责实现，两组之间不互通。方向是对的，但在AI场景里，这道墙往往只是形式上的。如果两组用的是同一个模型、同一套账号、同一个工作空间，那所谓"隔离"就形同虚设：分析那一侧喂进去的反编译结果、生成的中间产物，会顺着模型侧的上下文流到写代码的那一侧。

真要隔开，隔的应该是上下文——分析用的对话、上传的文件、中间结论，一条都不能进实现组的会话。两边最好用彼此不共享记录的环境。这是过去不需要考虑、现在必须写进流程里的一条。

这不是说用了AI就一定不独立，而是说——证明独立的方式要换。能证明的东西变了，要留的材料也得变：需求文档怎么写的，提示词是哪一版，给模型喂了什么，模型输出的哪一段被人工重写过，代码从哪一次提交开始成型，谁在什么时候访问过仓库。

还有一层容易被忽略：你重写出来的那套代码，自己是不是真的拥有它。目前的主流观点是，纯AI生成、缺少人类实质创作的部分，可能根本不受著作权保护——也就是说，别人抄你的，你未必拦得住。对打算把重写成果做成产品的团队来说，这一点值得在开工之前就想清楚。