Google Artemis 复制移动使用代码并移除署名 – 开源许可的影响

Google 的 Artemis 与移动使用项目几乎完全相同的文件

结论： Google 的 Artemis 仓库包含 228 个文件，这些文件与开源移动使用项目中的代码一字不差，表明存在直接的代码复制行为。

移动使用项目的创始人（一家在 Google DeepMind 的 AndroidWorld 基准测试中取得 100% 成绩的初创公司）发现，Google 新发布的用于移动自动化工具 Artemis 与他的项目共享了几乎全部代码库。在 Artemis 的 229 个文件中，有 228 个与移动使用项目完全一致，包括一个独特命名的代理“hopper”及其提示。

原作者被故意从提交历史中移除

结论： Artemis 的提交历史被修改，将三位原始移动使用项目作者替换为其他名字，违反了署名要求。

Artemis 仓库中的一个提交显示，原始作者 Pierre-Louis Favreau、Jean-Pierre Lo 和 Nicolas Dehandschoewercker 被替换为另一个作者的名字。提交差异中可以明显看出这一更改，并且直到问题被公开提出后才得到修正。

mobile-use 项目所用许可证及其署名条款

结论： mobile-use 项目采用 Apache 2.0 许可证，并包含一个 NOTICE 文件，明确要求保留署名，而 Google 未能遵守这一要求。

mobile-use 仓库声明其采用 Apache 2.0 许可证，并包含一个 NOTICE 文件，要求下游用户保留署名通知。Apache 2.0 第 4 条规定：“所有版权、专利、商标和署名通知”必须保留在衍生作品中。从文件头和 README 中移除作者姓名违反了这一条款。

"您必须在您分发的任何衍生作品的源代码形式中保留原始作品源代码形式中的所有版权、专利、商标和署名通知……" – Apache 许可证 2.0，第 4 条。

社区反应：法律与伦理视角

结论： 评论者一致认为，尽管在宽松许可证下复制代码可能合法，但移除署名是明确的违规行为，且在伦理上不可接受。

多位 Reddit 用户指出，Apache 2.0 许可证不允许移除署名，提交历史的修改是直接违规。
其他人指出，即使代码可以使用，未承认原始创作者就声称成果，属于剽窃，会损害开源生态系统的信任。
有少数评论建议，Google 可通过正确分叉仓库并保留 NOTICE 文件来避免问题，他们最终在争议后确实这样做了。

署名修复的时间线

结论： 在社区压力下，Google 添加了最低限度的署名，但修复是在问题被公开曝光后才进行的。

2026 年 9 月 11 日 – 在 Artemis GitHub 仓库中打开问题 #40，记录了署名缺失的问题。
2026 年 9 月 12 日 – 一个提交（371aa6df568...）在 README 中添加了简短的致谢，声明该项目包含 Minitap, Inc. 的代码。
提交历史仍然显示原始作者姓名被移除，表明修复是表面的。

原作者的法律救济与实际应对措施

结论： mobile-use 团队可以基于 Apache 2.0 的署名要求提起版权诉讼，他们应考虑发起 DMCA 下架请求或提出和解要求。

根据 Apache 2.0，未能保留署名即构成许可证违约，原始版权持有者有权要求合规。
向 GitHub 发送正式的 DMCA 通知，可要求移除侵权代码或要求正确署名。
如评论者所建议，聘请版权律师可能促成和解，尤其考虑到 Google 的资源。

对开源治理的更广泛影响

结论： 此案例凸显了在大型企业采用宽松许可代码时，需要更清晰的执行机制和社区警惕性。

企业必须对其使用的开源组件进行审计，以确保遵守署名条款。
项目维护者应考虑添加明确的署名执行条款，或使用具有更强 copyleft 规定的许可证，以防止此类滥用。
开源社区受益于透明的报告和快速的问题追踪，正如 Reddit 和 Hacker News 上的讨论所展示的那样。

关键要点

Google 的 Artemis 仓库复制了移动使用项目 229 个文件中的 228 个，该项目在 AndroidWorld 基准测试中排名第一。
原作者姓名从提交历史中被移除，违反了 Apache 2.0 的署名要求。
社区共识认为，该行为既违反了许可证的法律条款，也构成伦理上的不当。
原始开发者拥有可行的法律途径来强制署名或寻求补救。
该事件强调了在大型企业利用开源软件时，必须严格遵守许可证条款的重要性。