Google Artemis 複製 mobile-use 程式碼並移除來源標示 – 開源授權的影響

Google 的 Artemis 複製了行動裝置使用專案的幾乎完全相同的程式碼

結論： Google 的 Artemis 倉庫包含 228 個檔案，與開源的行動裝置使用專案完全相同，顯示出直接的程式碼搬移行為。

行動裝置使用專案（mobile-use）的創辦人，這家在 Google DeepMind 的 AndroidWorld 基準測試中取得 100 % 成績的初創公司，發現 Google 新發布的行動自動化工具 Artemis 與其專案共享幾乎全部的程式碼庫。在 Artemis 的 229 個檔案中，有 228 個與 mobile-use 完全一致，包括一個獨特命名的代理程式「hopper」及其提示內容。

原始作者的提交歷史被刻意移除

結論： Artemis 的提交歷史被修改，將三位原始 mobile-use 作者更換為另一個名字，違反了授權中的來源標示要求。

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 倉庫從 mobile-use 專案複製了 228 個檔案（共 229 個），該專案在 AndroidWorld 基準測試中排名第一。
原始作者的姓名從提交歷史中被移除，違反了 Apache 2.0 的來源標示要求。
社群共識認為，此行為既違反授權條款，也屬道德上的錯誤。
原始開發者有可行的法律途徑來強制執行來源標示或尋求補救。
此事件強調了對大型企業而言，嚴格遵守授權條款的重要性，特別是在利用開源軟體時。