Google Artemis陷开源署名争议：复用代码时，Apache 2.0究竟要求什么？

事件概况：争议焦点不是能否复用，而是是否正确署名

法国AI创业公司Minitap近日公开指称，Google发布的开源移动自动化项目Artemis大量使用了其mobile-use项目的代码，却在最初发布时没有清楚标注来源，并移除了原作者信息。

Minitap强调，公司并不反对其他团队使用、修改或继续开发mobile-use。该项目采用Apache License 2.0，本身就允许广泛复用，甚至可用于商业项目。团队质疑的核心是：代码进入新项目后，原有版权和归属信息是否得到保留。

目前，Google的Artemis仓库已补充对Minitap代码的说明，相关GitHub议题也已关闭。但公开信息中尚未看到Google对作者信息为何发生变化作出完整解释。因此，更准确的说法是“出现开源署名与许可证合规争议”，而不是在缺少司法或独立审计结论时直接认定侵权。

Minitap公布了哪些证据

大量文件和实现被指高度一致

Minitap在公开博客和GitHub议题中表示，Artemis早期版本共有229个文件，其中一次替换提交只修改了作者列表，另外228个文件保持不变。团队还列出多处具体相似内容：

• Android设备连接相关实现相同
• 名为Hopper的Agent及其提示词逐字一致
• WhatsApp示例使用相同任务、人物名称、注释和清理步骤
• 两套代码曾出现可复现的相同历史问题
• 部分文件保留了与mobile-use相关的描述和工具引用

这些材料来自Minitap方面的比对和公开仓库历史。它们为代码来源关系提供了可核查线索，但是否构成许可证违反，仍需结合具体文件、版权声明、NOTICE内容、分发方式和后续修正进行专业判断。

Git历史中曾出现三位原作者

争议最受关注的部分，是Artemis某个较早版本的项目配置文件曾列出Pierre-Louis Favreau、Jean-Pierre Lo和Nicolas Dehandschoewercker三位mobile-use作者。Minitap称，后续版本用另一位作者替换了这三个名字，而对应提交的其他代码基本未变。

Minitap还表示，这次变化发生在2026年8月的一次强制推送中。旧版本后来处于脱离主分支的状态，但仍能通过仓库记录和归档材料找到。

mobile-use与Artemis分别是什么

mobile-use面向Android设备智能体

mobile-use是Minitap在2025年推出的开源研究项目，目标是让AI智能体通过自然语言操作真实Android设备。项目围绕设备连接、界面理解、任务规划和动作执行构建了一套移动自动化能力。

Minitap称，其系统在AndroidWorld评测中完成全部116项任务并达到100%成功率。不过，该评测榜单注明相关结果为项目方自行报告，未经过独立验证。Minitap在自己的博客中也明确承认，这项限定同样适用于其100%的成绩。

Artemis同样聚焦移动设备自动化

Artemis是Google开源的移动自动化项目，帮助智能体与Android设备交互并执行多步骤任务。项目发布后，Minitap团队在查看代码时发现了熟悉的实现、Agent名称和示例内容，随后发起公开质疑。

从产品方向看，两者都处于Android自动化和智能体工具链的交叉地带。代码复用本身并不罕见，关键在于新项目是否遵循上游许可证规定，并让使用者清楚了解代码来源和各方贡献。

Apache 2.0允许什么，又要求什么

允许修改、分发和商业使用

Apache 2.0是一种较宽松的开源许可证。通常情况下，使用者可以复制、修改和分发代码，也可以把代码用于商业产品，无须公开整个衍生项目的源代码。

这也是Minitap反复强调“不反对Google使用代码”的原因。开源项目的价值之一，就是允许其他开发者在已有成果上继续创新。

宽松许可证不等于无条件使用

Apache 2.0第4条对再分发提出了一系列条件。概括而言，分发源代码形式的作品或衍生作品时，需要保留适用的版权、专利、商标和归属声明；修改过的文件应提供明显说明；如果上游分发包包含NOTICE文件，衍生作品通常还需以许可证允许的方式保留其中相关的归属信息。

具体义务取决于上游文件实际包含哪些声明，以及下游如何复制、修改和分发。README中的感谢说明可能是重要补救，但是否足以满足所有文件层面的要求，不能只凭一句声明判断。

署名不仅是礼貌，也是工程信息

作者、版权声明、提交历史和NOTICE并非可有可无的装饰。它们可以帮助后来者：

• 找到上游项目和维护者
• 理解设计背景与历史问题
• 确认不同模块的许可证来源
• 正确报告漏洞和提交修复
• 区分原始贡献与后续改进

对开源作者而言，署名还是其技术贡献和职业信誉的重要记录。因此，代码署名既涉及许可证义务，也关系到社区信任。

Google已经采取了哪些动作

事件公开后，Artemis仓库在README底部增加说明，表示项目包含由Minitap开发的源代码。GitHub上编号为40的“缺少对mobile-use及贡献者署名”议题随后关闭。

这表明项目维护方已经补充了来源信息。不过，社区仍在讨论声明覆盖范围、各文件中的版权信息是否完整，以及为何早期作者名单被替换。Minitap则认为，后续补充说明印证了Artemis确实使用了mobile-use代码。

需要区分的是，承认使用上游代码与承认违法并不是同一件事。最终合规结论要依据许可证文本和完整事实，而非仅凭社交媒体观点。

这场争议给企业哪些提醒

引入开源代码前建立来源清单

企业应记录每个第三方组件的项目地址、版本、许可证、版权方和修改范围。不要等产品发布后，再依赖个人记忆寻找代码来源。

不要随意删除文件头与作者信息

重构目录、复制代码或自动生成新仓库时，很容易丢失原文件中的版权头、NOTICE和作者字段。CI流程可以加入许可证扫描和差异检查，在发布前发现异常。

Fork、复制和重写都要留证据

如果基于上游项目开发，应保留导入提交、变更记录和依赖关系。即使最终代码经过大量修改，清晰的历史也能说明哪些部分来自上游，哪些是团队新增。

AI生成代码同样需要溯源意识

随着AI编码工具普及，开发者可能在不知情的情况下引入与公开仓库高度相似的代码。企业需要把开源合规检查延伸到AI生成内容，不能因为代码由模型输出就忽略许可证风险。

总结

Google Artemis与Minitap mobile-use的争议，再次说明“开源”不等于“无主”。Apache 2.0允许自由复用和商业开发，但仍要求使用者尊重适用的版权与归属信息。

对大型企业而言，补充一行致谢并不困难，真正困难的是建立可靠的代码来源管理机制。对开发团队而言，最稳妥的做法是从代码引入之初就保留许可证、NOTICE、作者和修改记录。这样既能保护原作者，也能避免产品发布后陷入不必要的法律与声誉风险。