曼昆普法 | AI开始重做Adobe,软件创业的门槛真的降低了吗?

10 月初，一个名为 ArtCraft 的开发者项目引发了软件行业的讨论：开发者借助 Claude，推出了七款开源工具，分别尝试复现 Photoshop、Premiere 等 Adobe 产品的核心功能和操作体验。

这套工具尚未达到全面替代原厂软件的程度，但它提出了一个值得认真讨论的问题：过去需要大团队、长期投入才能实现的软件功能，现在是否正在变得更容易复制？

对创业者而言，这可能意味着新的产品机会；对软件企业而言，则意味着一个更现实的问题——当竞争对手能够以更低成本重新实现核心功能，原有的技术壁垒和商业模式还剩下什么？

不过，功能可以被重新实现，不代表原厂代码已经公开，更不代表这种实现方式当然合法。要回答这个问题，需要把技术能力、知识产权和商业竞争分开来看。

据开发者介绍，ArtCraft 相关工具是基于公开信息和独立开发构建的，并未使用原厂专有代码或素材。这属于开发者的自述，并不等于其开发过程和法律合规性已经得到独立验证。公开报道及实际测试也显示，相关工具仍处于早期开发阶段，在部分功能精度、文件兼容性和稳定性方面，与成熟的专业软件仍有差距。

真正值得关注的，不是 AI 已经复制了多少软件，而是它正在如何改变软件开发的成本、竞争壁垒与法律风险。

做出类似功能、拿到原始代码、获得开源授权，是三件不同的事。

比如，两款图片软件都能裁剪照片，背后的代码完全可能不同。开发者可以研究产品的公开规范和可观察行为，再尝试独立实现类似功能。看到一款软件被“复刻”，不能就断定原程序已经被反编译，更不能断定原始源代码已经公开。

开源也不等于没有权利限制。开源软件仍然受到相应许可证的约束，修改、复制和再分发通常需要遵守具体的许可条件。即使有人合法开发了替代品并将其开源，原厂软件也不会因此变成开源软件。

AI 可能降低的，是部分功能的实现门槛。但对于商业软件而言，能实现功能，只是产品竞争的起点。

企业采购软件，购买的往往不只是一个功能按钮，还包括稳定性、兼容性、持续更新和售后支持。文件能否正常打开，数据会不会丢失，旧有工作流程能否延续，出了问题能否及时解决，都影响着用户是否愿意付费。

从与初创团队及投资方的沟通来看，我认为，小团队不一定要从一开始就复制整套成熟软件，更值得尝试的路径，是先解决一群用户的具体问题。

例如，面向电商商家的图片批处理工具，可以先解决商品图统一尺寸、批量调整背景、按不同平台要求导出等需求。假设一家网店每周需要处理数千张商品图，如果工具能减少重复操作和返工成本，就可能形成真实的付费需求。

当 AI 降低了功能实现的成本，创业机会未必在于做出一个更大的软件，而可能在于更快、更准确地解决一个具体问题。

对于中国创业团队，首先要看著作权。

《计算机软件保护条例》第六条规定：

但这不意味着所有与软件有关的内容都可以自由复制。具体代码、文档，以及可能具有独创性的图标、插画等界面元素，仍可能受到著作权保护。将他人的代码交给 AI 换一种编程语言、修改变量名，也不当然意味着形成了独立成果。

其次，要看商业秘密。

研究从公开渠道取得的产品、通过符合条件的反向工程获得技术信息，与取得竞争对手泄露的内部代码、技术文档后再开发，性质不同。

《最高人民法院关于审理侵犯商业秘密民事案件适用法律若干问题的规定》第十四条明确：

但如果开发者先以不正当手段获取他人的商业秘密，再以反向工程为由抗辩，法院不予支持。

当然，一份资料也不会因为被标上“内部资料”就自动成为商业秘密。通常还需要考察相关信息是否不为公众所知悉、是否具有商业价值，以及权利人是否采取了相应的保密措施。具体信息的性质、取得方式和后续使用情况，都需要结合事实判断。

法律也没有一概禁止反编译或技术分析。《著作权法》第五十条列明：

最后，代码自己写，也还要看怎么竞争。

冒充官方产品、夸大兼容能力、使用户误以为双方存在合作关系，或者以不正当方式获取和使用他人数据，都可能引发其他法律争议。反过来，原厂也不能仅凭“我投入很多、你卖得便宜”，就当然要求竞争对手退出市场。

例如，开发兼容某种文件格式的工具，可以如实说明实际测试过的文件类型和功能范围；但如果连产品名称、图标和宣传页面都刻意做得像官方产品，让用户误以为双方存在授权或合作关系，争议就已经超出了代码本身。

判断软件复刻是否存在法律风险，不能只看功能像不像，还要看具体表达、信息来源、开发过程和市场竞争方式。

不要只给 AI 一句“照着某某软件做”。

先把需求说具体：谁来使用，输入什么，要得到什么结果，哪些功能是必须的，哪些只是参考。

公开规范、合法取得的产品和在正常使用中观察到的行为，可以作为研究起点；未经授权泄露的代码、员工无权带出的前雇主内部文档，则应排除在开发材料之外。

参考了什么、从哪里取得，建议随手记录。软件许可协议也要提前审查，尤其是涉及逆向分析、自动化使用和数据提取的限制。相关条款是否有效、适用到什么范围，需要结合具体情况判断，不能一概忽略，也不能一概视为绝对禁令。

公开规范和正常测试已经足以支持开发的，就先据此实现。

确需反编译或绕过技术措施时，应先核对研究目的、必要性和具体法律依据，不能仅凭“为了开发兼容产品”就认定行为合法。

对于高度接近竞品的项目，可以考虑建立独立开发机制：由研究人员整理不包含对方受保护代码、商业秘密等内容的功能说明，再由另一团队依据合法材料独立实现。

这类机制的价值，在于控制不当信息进入开发流程的风险，并为后续事实核查留下依据。仅在网站上声明“独立开发”，却无法说明实际过程，并不足以解决问题。

AI 的会话记录、知识库、代码仓库和访问权限，也应纳入同一套管理机制。

如果团队已经接触了不应取得的资料，另开一个 AI 对话并不能消除之前的事实。应先查清资料涉及哪些模块、是否已经被使用，再评估后续开发和上线的风险。

“这是 AI 写的”，回答不了材料从哪里来、代码是怎样形成的。

建议保留关键需求文档、提示词及附件、模型输出、人工修改记录和代码提交记录，尤其是与核心功能有关的开发过程。

这些记录有助于还原信息来源、实现路径和人工贡献，但并不当然证明独立开发，也不能自动排除侵权责任。商业秘密纠纷中，在符合法定条件时，举证责任可能发生转移；连续、真实的开发记录，通常比争议发生后才补写的说明更有助于查明事实。

还要注意，不能把客户或前雇主的保密资料随手上传模型。即使服务商承诺不将相关内容用于训练，也不代表上传者本身就有权披露这些资料。

招聘、外包和合作开发合同中，也可以明确材料来源、保密义务、代码归属及成果交接要求，避免产品即将上线，团队却说不清关键模块由谁提供、依据什么取得。

界面设计得顺手，与照搬别人的图标、文案，是不同的问题。产品名称和标识也应让用户清楚分辨产品来源，避免造成混淆。

AI 引入的开源代码，需要核对许可证及具体使用方式。有些许可证要求保留版权声明和许可文本，有些许可证则可能在特定分发条件下要求提供相应源代码或履行其他义务。

不能把“网上公开”理解为“任意使用”，也不能简单认定用了某段开源代码，整个产品就必须公开。是否需要开放源代码、需要履行哪些义务，要看具体许可证及其适用条件。

决定开源自己的产品时，也要确认哪些代码、素材和依赖项有权许可给别人。把未经授权的代码放进公开仓库，再附上一份开源许可证，并不能补上原本缺失的授权。

“能打开部分文件”，就不要写成“全面兼容”；完成了演示，也不等于能够承担专业生产任务。

对外宣传时，应明确产品已经支持的功能、测试过的范围和已知限制，避免夸大性能或作出无法兑现的兼容性承诺。

同时，针对产品涉及的关键技术，还应根据实际情况排查可能相关的有效专利。代码独立开发，并不当然排除专利侵权风险；文件格式、接口和功能实现，也不能只凭“大家都这么做”就认定没有法律问题。

对于计划商业化的软件，建议在发布前形成一份基本的合规检查清单，覆盖代码来源、开源许可证、第三方素材、商标与界面、数据使用、专利风险和产品宣传。

当软件功能的实现成本不断下降，用户选择一款产品的理由，可能不再只是它能完成什么功能，还包括它是否足够稳定、能否融入现有工作流、是否便于团队协作，以及能否持续提供可靠的服务。

对于软件企业而言，这意味着竞争优势可能逐渐从单一功能，转向产品体验、生态兼容、服务能力与用户信任。

这也带来另一个值得讨论的问题：用户在使用软件的过程中贡献的反馈、模板、工作流和数据，能否通过明确的协议或治理机制，进一步参与产品决策，甚至分享产品发展带来的收益？

当然，用户贡献并不自动转化为软件所有权或收益分配权。相关权利如何产生、如何分配，仍需结合知识产权归属、合同安排及具体治理机制判断。

当软件越来越容易被重新实现，产品如何建立持续的竞争优势，以及用户贡献的价值应当如何界定，或许值得在下一篇文章中继续讨论。

*本文为上海曼昆律师事务所的原创文章，仅代表本文作者个人观点，不构成对特定事项的法律咨询和法律意见。如需转载及法律咨询，请添加客服：mankunlawyer / MankunLawFirm（WhatsApp）