“人工智能提出了一个令人尴尬的问题：房间到底有多干净？”
AI 工具可以帮助开发者重现现有软件的功能。但在构建替代方案与复制他人作品之间，存在着一个重要区别。
一位开发者最近声称，其开发的这款“氛围编码”版Photoshop替代品已吸引了2万名用户，这引发了一个有趣的问题：如果人工智能能帮助某人开发出竞争性产品，原软件所有者是否有理由提出异议？
人们本能的反应可能是：复制一款已有的产品必然会侵犯其著作权。毕竟，原始开发者可能为此投入了数年的时间。然而，著作权并不会赋予软件企业对其产品功能的垄断权。在人工智能编码工具出现之前，关于复制功能与复制该功能表现形式之间的区别，法院早已进行了多次裁决。
结果相同，软件不同
以一款照片编辑器为例。开发人员可能希望用户能够裁剪图片、调整颜色以及操作图层。这些需求描述的是功能。而为实现这些功能所编写的代码则是另一回事。
这一区分是软件著作权的核心。源代码和目标代码可以受到保护，但程序所依据的想法和原理本身并不受保护。因此，竞争性程序仅因接受相同的输入或产生相同的结果，并不必然构成侵权。
英国法院在“Navitaire 诉 easyJet”案 [2004] EWHC 1725 (Ch) 中对此进行了裁决。当时，一家公司特意开发了一套替代性的航空预订系统，使其运行方式与现有系统极为相似，但并未获取后者的源代码。法院驳回了关于复制其功能行为构成版权侵权的主要主张。但值得注意的是，部分涉及图形界面和图标的主张获得了支持。功能性与艺术设计需要不同的处理方式。
对于任何开发替代软件的人来说，这是一个有用的起点：重现产品的功能，并不等同于获得了复制用户所见所有内容的许可。
洁净室的建设有何不同之处？
“洁净室”流程的设计初衷正是为了明确区分这两者。通常，一个团队负责研究现有软件，并根据其功能行为编写一份规格说明书；另一个从未接触过原始代码的团队则根据该规格说明书编写新的实现代码。该流程的记录有助于证明开发工作的独立性。
这并不是让原始著作权消失的一种方式。此外，“清洁室”也不是一个能保证获得有利结果的法律术语。其价值在于表明新产品复制的是不受保护的功能，而非受保护的表达形式。
人工智能提出了一个令人尴尬的问题：房间有多干净？
从一个空的代码库开始，并不一定能解答这个问题。提供给编码工具的素材很重要，它检索到的任何源素材同样重要。此外，还可能存在这样的疑问：模型在训练过程中是否接触过相关代码？这些问题虽不能直接证明存在侵权，但使得“AI是从零开始编写的”这一简单说法，其可信度不如乍看之下那么高。
因此，开发人员应当区分“要求人工智能实现功能规格说明”与“要求其重写现有代码库”这两种情况。这两项工作不应被视为可以互换。
欧洲法律
最具参考价值的判决之一是“SAS Institute诉World Programming案”（案号：C‑406/10）。该竞争性软件旨在运行与原系统使用相同编程语言编写的程序，并产生相同的输出结果。其开发者研究了原产品，但没有任何迹象表明其曾访问或复制过原系统的源代码。
在C-406/10案中，欧洲联盟法院裁定，程序的功能、编程语言及相关数据文件格式不属于《软件指令》下计算机程序著作权所保护的表达形式。这种区分既保障了开发兼容软件的可能性，又避免了使首位开发者对底层创意拥有排他性控制权。
在随后的英国上诉案件“SAS Institute 诉 World Programming”案（[2013] EWCA Civ 1482）中，法院维持了支持功能性重新实现的判决结果。然而，关于手册之间存在抄袭行为的侵权认定仍被部分维持。通过文档理解产品是一回事；从该文档中复制受保护的表达则是另一回事。
对于照片编辑软件而言，这提供了一个有用的类比。编写独立代码来支持现有的文件格式，并不等同于复制原始程序。但这并不意味着，与该格式相关的代码、文档或其他受保护的材料就可以随意拿走。
关于API的争论，不是谷歌赢了吗？
人们常将谷歌与甲骨文在美国法院之间旷日持久的纠纷视为确立了应用程序接口（API）不能受版权保护的先例。但这并非美国最高法院最终作出的裁决。
API 允许程序员调用函数，而无需自己编写底层实现代码。在开发 Android 时，谷歌虽然编写了自己的实现代码，但从 Java 平台复制了大约 11,500 行声明代码及相关组织结构，从而使程序员能够使用熟悉的命令。
在各级法院作出相互矛盾的判决后，最高法院于2021年4月在“谷歌诉甲骨文”案中裁定，该复制行为属于合理使用（摘要见此）。关键在于，最高法院在审理本案时，是假定版权保护存在，而非旨在确定该材料是否受版权保护。
因此，该裁决并未确立API可被普遍自由复制的原则。此外，也不应将其在美国的“合理使用”推理与欧洲在“SAS Institute诉World Programming”案中的做法混为一谈——该案涉及软件著作权的范围，并允许对程序进行研究。这些案例虽均支持兼容性和重新实现，但所依据的法律途径各不相同。
新法规并未解决这一问题
开发人员可能会避免复制原始代码，却能非常接近地重现其接口。这便引发了另一个问题。
在“安全软件协会”（C‑393/09）一案中，欧洲法院裁定，图形用户界面不属于《软件指令》所指的计算机程序的表达形式，因此不受保护。不过，如果界面是作者自身的智力创作，则可以作为独立作品获得著作权保护。仅由技术功能决定的组成部分不符合这一原创性要求。
就基于人工智能的图片编辑器而言，关键区别在于：是提供熟悉的编辑功能，还是再现原始图形或其他受保护的界面表现形式。不应仅仅因为生成的代码是新的，就认为让编码工具根据图片重现屏幕是安全的。这就是将界面与实现该界面的程序区分开来的实际意义所在。
开发人员和软件企业应该怎么做？
对于开发者，我们的建议是在生成实现代码之前先明确所需的功能。请记录所使用的规格说明、提示词和源材料，并分别审查生成的代码和视觉素材。有文档记录的开发流程比仅依赖“AI生成”或“从零开始编写”等描述更为有用。
对于成熟的软件企业而言，这些案例也凸显了仅依赖著作权的局限性。著作权虽能保护有价值的代码、图形和文档，但并不一定能阻止竞争对手独立实现相同的功能。其他权利和义务，包括专利、商业秘密和合同限制，需要另行考虑。
“氛围编码”领域的最新进展应能引发这一讨论。
核心问题依然是那个老生常谈的问题：开发者是开创了一种实现相同功能的新方法，还是复制了他人受保护的作品？人工智能或许会改变软件的开发方式，但“这是人工智能写的”这一说法并不能替代对该问题的回答。
如果您正在开发一款竞争性或兼容性软件产品，或者担心某款产品抄袭了您的产品，请联系您惯常合作的巴克·布雷特尔律师事务所律师，以商讨相关知识产权问题。
