开源社区里最让人血压升高的事不是功能被别人“借鉴”了而是代码被整个搬走翻到 README 和 LICENSE 一栏一个字都没提你。最近闹得沸沸扬扬的 Minitap 与 Google Artemis 之争就是典型一例。Minitap 团队发声明指控谷歌的 Artemis 项目盗用了他们维护的开源项目 mobile-use 的代码而且没有注明出处。对不熟悉开源规则的人来说这可能只是“两家公司吵架”但如果你自己维护过项目或者在公司里写过依赖第三方代码的模块就会明白这事的分量它触及的不只是道德问题更是开源许可证和整个协作体系的底线。这篇文章我不打算急着做立场宣判谷歌到底有没有“盗用”最终要看双方摆出来的证据。我更想借这个案例把“开源代码被复用但不署名”这件事拆开讲清楚什么样的行为算违规判断依据是什么大公司为什么也会踩这种坑以及我们作为开发者怎么在平时就给自己上几道保险。无论你是个人项目维护者、企业开发者还是刚入行不久、准备参与开源的新人这篇应该都能给你一些实实在在的边界参考。1. 这起争端的主角mobile-use 和 Artemis 分别是什么既然要聊这起争端得先搞清楚两边各自是什么来头。很多圈外读者可能跟我一样第一反应是Artemis 我听过谷歌的但 mobile-use 是什么Minitap 又是谁1.1 mobile-use一个典型的移动端 AI 代理开源框架mobile-use 是 Minitap 团队维护的一个开源项目定位非常明确让大模型像人一样操作手机。你给它一句自然语言指令比如“帮我在备忘录里建一个明天的日程提醒”它就能通过视觉识别、界面解析和动作回调在 Android 设备上完成点击、滑动、输入等一系列操作。从技术架构上看这类项目通常由几个核心模块组成界面信息提取模块负责把屏幕上的控件转成结构化文本或坐标动作执行模块负责把模型决策映射成真实的触摸事件还有规划模块负责让大模型决定“下一步做什么”。mobile-use 在这条赛道里不算最早的但胜在代码组织清晰、文档齐全在 GitHub 上积累了不少关注也吸引了一批开发者参与贡献。这种项目有个特点它的核心逻辑非常“可迁移”。界面解析、坐标映射、无障碍服务调用、模型 prompt 模板这些部分几乎是任何移动端 AI 代理项目都绕不开的“基础设施”。换句话说mobile-use 提供的不是某个具体功能而是一整套“让 AI 操作手机”的基础方案谁拿过去都能快速起一个相似的产品。1.2 Artemis谷歌在移动 AI 代理方向的布局Artemis 是谷歌在移动端 AI 代理领域的项目。从公开信息来看它同样瞄准了“AI 在设备端自主完成多步操作”这个方向和 mobile-use 在能力面上有明显重叠。谷歌作为 Android 生态的主导者做这类项目有天然优势可以更深度地调用系统能力也能和自家的语音助手、系统级 AI 服务联动。问题就出在“能力重叠”和“代码重叠”是完全两回事。两家都做手机自动化这不叫抄袭但如果一个项目里出现了另一个项目的实现细节、命名习惯甚至注释原文那性质就变了。Minitap 团队这次的指控显然不是“你也做手机操作”这么空泛而是指向了更具体的代码复用。1.3 Minitap 的指控点不是“用了”而是“拿走了却没说”从社区流传的对比信息和 Minitap 团队的声明来看核心指控有两个层面第一Artemis 项目的部分代码与 mobile-use 高度相似已经超出了“巧合撞车”的范畴第二更关键的是谷歌在使用这些代码时没有保留 mobile-use 的版权声明也没有在项目文档中注明出处。这里我要特别强调一下“用了代码”和“拿走代码不署名”之间的区别。开源不等于放弃版权不等于“随便用”。绝大多数开源许可证都允许你复制、修改、再分发代码但前提是你要履行相应的义务其中最基础的一条就是保留原始版权声明和作者署名。如果你把代码搬走了然后把自己的名字一贴从法律上讲这叫“删除版权管理信息”在多个司法管辖区都是明确违规的。这也是为什么这个事件能在开源圈迅速发酵。大厂和小团队之间的代码纠纷本来就容易引发共情更何况“吃相难看”的程度——如果指控属实那就不是技术判断失误而是基本合规意识的缺失。2. 代码撞脸还是真抄袭判断“盗用”需要看什么很多人一看到“代码相似”就喊打喊杀但作为从业者我得说一句公道话代码相似本身不一定等于盗用。同一个功能成熟的开源写法就那么几种尤其是处理 JSON、解析 XML、调用系统 API 这类标准化操作十个开发者能写出九份差不多的代码。那到底怎么判断是“英雄所见略同”还是“复制粘贴”这里有一套相对客观的判据。2.1 开源许可证下的“合法借用”与“违规挪用”的边界要理解“盗用”的边界先得明白开源许可证的层级逻辑。不同许可证对使用者的约束完全不同我把最常见的几种列成一张表方便对照许可证商用修改后闭源分发必须保留原版权声明衍生作品开源典型代表MIT允许允许是不强制大量前端库、工具库Apache 2.0允许允许是且需保留 NOTICE不强制多数大厂开源项目GPL 3.0允许不允许是强制Linux 内核相关生态AGPL 3.0允许不允许是强制且包含网络服务数据库、服务端组件注意看表格里的第二列和第三列。MIT 和 Apache 2.0 这类“宽松许可证”给了使用方很大的自由你可以拿去商用可以改完以后不发源码唯独有一条不能省——保留原始版权声明。这句话看着简单但在真实项目里经常被忽略从 GitHub 上拉了一个仓库下来改了改就合进自己的代码库版权声明文件要么没拷要么被后来者的 LICENSE 覆盖了。回到 mobile-use 事件上如果 mobile-use 用的是 MIT 或 Apache 2.0 这类宽松许可证那谷歌“复用代码”这件事本身可能并不违法但“未注明出处”这一条直接踩中了许可证最核心的义务线。2.2 维护者通常靠什么证据锁定“复制粘贴”看一个项目是否真的“盗用”了另一个项目的代码不能靠感觉得靠证据。我在社区里围观过不少类似的纠纷维护者摆出来的证据一般集中在这么几类命名指纹某个项目里有一个不常见的函数名、类名、变量名在另一个项目里原样出现。命名这东西最诚实如果extract_screen_forest这种带个人风格的函数名出现在两个人各自的代码库里巧合的概率基本为零。注释残留开发者复制的往往不只是代码还包括注释。有时候原作者会在注释里写一句很个人化的吐槽或者写一个错别字结果被原封不动搬过去。很多“实锤”就是从这种细节里扒出来的。代码结构指纹两个文件的行数接近、函数顺序一致、空行位置一致、甚至某段奇怪的空格缩进都一模一样。这种结构化相似度靠肉眼可能看不全但用 diff 工具一比对一目了然。提交时间线mobile-use 的某个提交记录显示代码在 2024 年 3 月就存在了而 Artemis 项目的首次提交晚于这个时间点再加上名称和结构的高度吻合时间线就成了最有说服力的证据。Minitap 团队这次的指控按社区常见的“实锤”套路看大概率也是从这些角度切入。不需要逐行 100% 相同只要出现一两个“独占性指纹”就足够把“撞车”变成“复制”了。2.3 我见过的一些“低劣但真实”的复制场景说句实话我在这个行业里见过不少“复制代码”的案例水平参差不齐有些真的让人啼笑皆非。一种是“全量搬运型”。整个文件拷过去连文件头部的版权注释都没删只是把作者名字改成自己的。这种属于最懒的也是最容易实锤的因为只要原项目方一搜文件名立刻就能找到。另一种是“局部改造型”。把变量名改一圈、删几行注释、换一下函数顺序以为这样就不算抄了。这种稍微费点劲但核心逻辑、边界条件处理、异常分支几乎原样保留用相似度检测工具一跑还是能看出来。还有一种最隐蔽叫“二次创作型”。A 项目抄了 B 项目的核心逻辑B 项目抄了 C 项目的界面设计最后 C 维护者去质问 AA 一脸无辜说“我是从 B 那里学的”。这种追责链路长、证据容易断往往最后不了了之。说这些不是为了嘲讽而是想说明一个事实代码盗用在这个行业里并不罕见只是大多数时候没闹到明面上。这次 Minitap 和谷歌的争端能公开化对开源生态来说反而是一件有正面价值的事至少它把“复制代码不署名”这个问题重新放到了聚光灯下。3. 为什么谷歌这种体量的公司还会在这个坑里翻车很多人不理解谷歌啊世界级的科技巨头内部各种合规培训、代码审查流程怎么会犯这么低级的错误这恰恰是普通人对大公司流程的误解。大公司的“合规”通常做在最容易被审计的地方比如法务会盯着你用了什么付费软件的授权安全团队会检查你集成了哪些有已知漏洞的第三方库。但“从 GitHub 开源项目里复制了一段代码合入内部项目时没保留版权声明”这种事情在体量庞大的组织里监管起来远比想象中难。3.1 大公司开源流程的普遍盲区大公司的代码库是海量的一个项目动辄几百万行代码分布在几百个仓库里。谁来保证每一行代码都手续齐全实际上没人能保证。各个团队为了赶进度从 GitHub 上找现成代码是常态尤其是一些“基础设施类”的工具函数大家默认“网上都是这么写的”随手复制粘贴进代码库。真正的问题在于很多开发者把“开源”理解成了“无主”。他们没有恶意就是单纯缺乏许可证意识。看到一段代码试了一下能跑就直接用了。至于这段代码是什么许可证、要不要保留版权声明、能不能用在商业项目里很多人压根没想过。这不是某一个人的问题而是整个行业在培训和教育层面长期缺失的结果。谷歌内部的代码审查系统确实很严格会包头到接口设计、性能、安全性但对“知识产权痕迹”这一项的自动化检查其实非常有限。系统很难自动判断“这段代码跟 GitHub 上某某仓库的某段代码一致”尤其是经过变量重命名、函数拆并之后静态扫描工具的作用就更有限了。3.2 内部复制粘贴与“顺手搬运”的文化还有一个容易被忽略的因素内部复制粘贴。谷歌这种体量的公司内部有大量的共享代码库和通用组件库。一个工程师在某个内部仓库里看到一段现成的代码这段代码其实是两年前某个人从外部开源项目里带进来的版权声明早就被层层传递弄丢了。这位工程师不知道这段代码的外部来源以为是自家团队写的就拿去用了。这种“二级传播”特别可怕。原始来源的开源项目作者找谷歌算账的时候谷歌自己可能都查不清这段代码到底是从哪个内部仓库流出来的。每一层复制都会把版权信息抹掉一层几层之后就完全看不出来了。更有意思的是这种文化并不限于底层工程师。有些项目负责人为了赶工期会直接授意团队“先拿开源方案改造一下后面再整理版权”结果“后面”永远没有来。deadline 一到代码合并这件事就被遗忘了直到若干年后原作者来敲门。3.3 团队扩张、外包与收购带来的历史包袱谷歌也不是所有的代码都出自自家工程师之手。移动端 AI 代理这个赛道这两年中厂、大厂都在抢人团队扩张速度极快。新来的工程师把上一家公司的代码风格、使用习惯带来是很自然的事。有些甚至在跳槽前把自己上一家公司的项目“顺手”复制了一份作为“个人参考资料”带到了新环境。还有一种常见路径是收购。大厂收购小型创业团队直接把对方整个代码库接过来。被收购团队的项目里可能本身就有一部分代码来自其他开源项目而且没有做到完整合规。收购完成之后这些“隐藏债务”就自动转移到了大厂头上。一旦原作者维权承担舆论压力和法律责任的是谷歌而不是那个已经解散的创业团队。看到这里你应该能理解大厂翻车不是“因为它是谷歌所以不该翻车”恰恰相反正是因为体量太大、链路太长出了这种事反而更不稀奇。Minitap 这次选择把问题公开化某种程度上也是被逼无奈邮件、法务函在大厂内部流转几个月没有回音往往是常态。4. 从 mobile-use 事件看开源合规的核心常识聊完了八卦和背景这一节我想认真讲讲正事开源合规这件事到底牵扯哪些常识不管你是个人开发者还是公司员工这些内容都该刻进脑子里。4.1 署名到底怎么署才算“注明出处”“注明出处”这四个字看着简单实际做起来很多人把握不住分寸。以 Apache 2.0 为例标准做法是这样的复制代码文件时保留文件头部的版权声明和许可证声明原样不动如果你的项目整体使用了某开源项目代码应该在项目的 LICENSE 或 NOTICE 文件中列出该项目名称、作者、原始许可证类型如果修改了原作品需要在修改文件处显著标注“基于 XX 项目修改”说明你不独占代码贡献。很多开发者以为“在 README 里提一句感谢”就算注明出处了这是不对的。感谢和许可证义务是两回事感谢可以随便写想写多诚恳都行但从许可证角度你需要的是“可追溯”的署名当别人拿到你的项目时能通过你保留的信息找到原始作者这才是合规的完整闭环。我在实际项目里见过一个比较规范的示例对方在自己项目的根目录下放了 THIRD_PARTY_NOTICES.md 文件里面列出所有依赖的开源项目每一条都包含项目名、作者/组织名、许可证全文链接、以及“是否修改”的说明。这种文件在合规审计时可以直接作为证据避免了“你说你用了但查无实据”的尴尬。4.2 给个人维护者的自我保护清单回到 mobile-use 事件我可以想象 Minitap 团队现在的心情。自己辛辛苦苦写出来的东西被人拿走用了反而要反过来证明“这是我的”这个过程非常耗人。所以给所有个人项目维护者一条最真诚的建议不要等到被抄袭了才开始整理证据平时就要把“自我保护”做进项目里。我从自己的实践里总结了一份清单分享给大家LICENSE 文件永远是第一步项目创建第一天就要定好许可证并写进仓库。没有许可证的项目在法律上默认“保留所有权利”别人不能用但也不能证明你授权了什么。明确定下 MIT 或 Apache 2.0是后续所有维权的地基。保留完整的 git 提交历史从第一个 commit 开始就带上作者信息和时间戳。commit 历史是你的“最早的发表记录”一旦发生争议它就是最客观的证据。不要在代码里混入无法说明来源的片段你自己用别人的代码也要注明出处不然某天你反过来维别人的权对方翻你的仓库也能找到“你也抄了”的反击点。发布 release 时生成哈希值针对核心文件保存一份 SHA-256 校验值。如果某天别人把你的代码原样拿走你可以在维权材料里直接贴出“我的这段代码哈希是 A你发布版本里的这段代码哈希不是 A 就是 B对比一下就知道”。记录版本发布时间并做好存档GitHub 的 release 记录、npm 包发布时间、PyPI 上传时间都能证明你在某个时间点已经公开了代码。这些时间戳会被后续审计经常用到。这些工作看着零碎实际做一遍花不了多少时间。但真到了需要维权的时候它们就是你手里最硬的牌。4.3 给企业开发者的合规自查清单企业开发者的处境和个人维护者不一样你手里通常没有项目的完整决策权但你写出去的每一行代码都代表着公司的法律风险。不管你在什么公司都应该养成一个习惯在使用第三方代码前花一分钟确认它的许可证并在代码提交信息里注明来源。我自己在公司里做项目时会遵守一套简单的清单合并外部代码之前确认这三件事来源项目的许可证是什么如果是 MIT、Apache 2.0可以放心用但必须保留版权声明如果是 GPL/AGPL就要立刻停下来确认它是否会“感染”你的商业闭源项目。COPYING、LICENSE 或 NOTICE 文件是否被一并复制如果只是 copy 了源码文件没拷许可证文件严格来说已经不合规。是否在项目的根目录或 README 中记录了第三方依赖清单公司项目不比个人项目人员会流动三个月前“大家都知道的”第三方来源三个月后可能没有人说得清所以书面记录是唯一可靠的交接介质。日常开发中养成两个习惯把“确认许可证”变成条件反射每一次从网上复制代码都追一句“这是什么许可证”这也是我推荐给所有新人的习惯。在代码审查时留意可疑的外部代码痕迹比如不常见的命名风格、突兀的注释、无出处的工具类函数块。一旦团队成员提交了源代码中没有版权信息的片段要主动追问“这段代码哪来的”。听起来像是在公司里给自己找麻烦但换个角度想如果你的代码让公司吃了一场开源侵权的官司那才是真正的大麻烦。前期的多问一句永远比后期的解释十句更划算。4.4 自动化工具能帮你做什么人难免有疏忽且大型项目的第三方依赖数量动辄上百个单靠人工去查许可证不现实。好在业界已经积累了不少成熟的自动化扫描方案。像 FOSSA、Snyk、Black Duck 这类工具可以扫描项目依赖树自动匹配每个依赖的许可证类型并在发现有冲突的许可证时发出警告。GitHub 本身的依赖图功能也能显示仓库中依赖项的许可证信息。我的建议是不管公司有没有强制要求个人项目也都跑一遍这类扫描免费额度对开源项目基本够用。扫描结果不仅能让你知道自己用了哪些“有版权负担”的代码还能在项目页面上展示一个徽章证明你是“合规友好”的。这在社区里是加分项。5. 事件可能的走向与对 agent 开源生态的影响最后我们来聊聊这起事件接下来可能怎么走以及它对整个移动端 AI 代理开源生态会有哪些影响。这部分更多是我个人基于经验推演的趋势判断仅供参考。5.1 Minitap 的诉求路径从以往类似事件的处理惯例来看Minitap 方面的诉求通常会经历三个层次。第一个层次要求公开承认并补充署名。这是在开源社区最常见的第一步。维护者的核心诉求一般是“你可以用我的代码但你必须告诉大家这段代码是从哪来的”方式是修改项目仓库补上版权声明和 NOTICE 文件并在发布声明里致谢原始作者。第二个层次要求删除侵权代码。如果双方沟通不畅或者使用方拒绝承认那诉求就会升级为“请删除所有涉事代码”恢复到独立开发的状态。这一步对使用方代价极高因为你要在短时间内在不影响项目进度的前提下重写自己已经迭代过一段时间的关键模块。第三个层次正式法律途径。这一步成本最高、周期最长、对双方消耗也最大但在 License 明确且证据链完整的情况下原告的胜率并不低。所以通常在这个阶段大厂更倾向于庭前和解毕竟打官司的律师费往往高于“重新招人把代码重写一遍”的费用。根据我的观察像 Google 这种体量的公司对外回应通常会走“道歉 补署名 加强内部流程审查”的路线承认存在个别团队合规疏漏然后强调公司整体尊重开源的立场。Minitap 这边大概率也能得到自己想要的形式上的说法——包括在项目文档中补上 credits以及一篇有诚意的致歉声明。至于更进一步的赔偿围绕代码许可纠纷的案例里不是没有但比例相对有限。5.2 谷歌可能的回应与项目后续谷歌应该不会因为这件事就砍掉 Artemis 项目毕竟放眼全球几乎所有头部科技公司都在快速布局移动端 AI 代理。这个方向的战略价值太大了不太可能因为一次开源合规纠纷就放弃整条赛道。更可能的是团队会切割掉有争议的部分在内部做一次彻底的代码审查把与 mobile-use 相关的模块换成自己独立实现或基于其他合规第三方的替代方案。除此之外谷歌大概率会在内部强化一轮“开源许可证合规”培训和工具落地。实际上这类事件之后大厂都会做一轮流程补课一方面是真为了降低法律风险另一方面也要给外界一个“我们改进了”的信号。比较讽刺的是类似的事件在这几年并不少每次发生后都能短暂地引起行业对合规的重视但热度一过又会回到原来的状态。5.3 对整个开源协作体系的警示如果让我说这起事件真正的价值我觉得不是“谷歌如何回应”而是它给整个行业敲了一声警示钟。移动端 AI 代理是过去一两年增长最快的开源赛道之一。大量新项目像雨后春笋一样出现很多团队为了快速入场会去研究甚至直接借鉴头部项目的实现。从 mobile-use 这类基础框架被大规模复用的概率来看类似“未署名使用”的情况可能不少只是绝大多数没有浮出水面。这起事件之后预计会有两个层面的正向变化。在维护者层面更多项目负责人会开始认真对待许可证版权声明不会再把“开源”两个字当成“无版权”的同义词。在企业层面技术决策者会在引入外部开源代码前加入更严格的许可证审查流程尤其是在那些会被用于商业产品和对外发布的项目上一步都不该省。开源的本质是协作不是掠夺。协作的前提是彼此尊重版权这也是 mobile-use 事件最值得被记住的一点。最后再分享一点个人的体会。我自己的小项目也曾经被人整段搬走过对方把 LICENSE 文件删了然后冒充成自己的东西挂到另一个平台。我当时气得好几天睡不着但后来想明白了与其生气不如把项目做得更好、更独特让后来者一眼就能看出谁才是正主。同时我也更加坚定地在每一个新项目里把 LICENSE、NOTICE、CONTRIBUTING 和 release 记录做得完整不是为了炫耀什么就是为了哪天真要上场对质的时候手里有牌可打。希望 mobile-use 事件最终能有一个体面的结局也希望每一位开发者的劳动成果都能得到应有的署名。毕竟代码可以被复制但署名是创作者该有的尊严。
从mobile-use与Artemis之争看开源代码署名与许可证合规
开源社区里最让人血压升高的事不是功能被别人“借鉴”了而是代码被整个搬走翻到 README 和 LICENSE 一栏一个字都没提你。最近闹得沸沸扬扬的 Minitap 与 Google Artemis 之争就是典型一例。Minitap 团队发声明指控谷歌的 Artemis 项目盗用了他们维护的开源项目 mobile-use 的代码而且没有注明出处。对不熟悉开源规则的人来说这可能只是“两家公司吵架”但如果你自己维护过项目或者在公司里写过依赖第三方代码的模块就会明白这事的分量它触及的不只是道德问题更是开源许可证和整个协作体系的底线。这篇文章我不打算急着做立场宣判谷歌到底有没有“盗用”最终要看双方摆出来的证据。我更想借这个案例把“开源代码被复用但不署名”这件事拆开讲清楚什么样的行为算违规判断依据是什么大公司为什么也会踩这种坑以及我们作为开发者怎么在平时就给自己上几道保险。无论你是个人项目维护者、企业开发者还是刚入行不久、准备参与开源的新人这篇应该都能给你一些实实在在的边界参考。1. 这起争端的主角mobile-use 和 Artemis 分别是什么既然要聊这起争端得先搞清楚两边各自是什么来头。很多圈外读者可能跟我一样第一反应是Artemis 我听过谷歌的但 mobile-use 是什么Minitap 又是谁1.1 mobile-use一个典型的移动端 AI 代理开源框架mobile-use 是 Minitap 团队维护的一个开源项目定位非常明确让大模型像人一样操作手机。你给它一句自然语言指令比如“帮我在备忘录里建一个明天的日程提醒”它就能通过视觉识别、界面解析和动作回调在 Android 设备上完成点击、滑动、输入等一系列操作。从技术架构上看这类项目通常由几个核心模块组成界面信息提取模块负责把屏幕上的控件转成结构化文本或坐标动作执行模块负责把模型决策映射成真实的触摸事件还有规划模块负责让大模型决定“下一步做什么”。mobile-use 在这条赛道里不算最早的但胜在代码组织清晰、文档齐全在 GitHub 上积累了不少关注也吸引了一批开发者参与贡献。这种项目有个特点它的核心逻辑非常“可迁移”。界面解析、坐标映射、无障碍服务调用、模型 prompt 模板这些部分几乎是任何移动端 AI 代理项目都绕不开的“基础设施”。换句话说mobile-use 提供的不是某个具体功能而是一整套“让 AI 操作手机”的基础方案谁拿过去都能快速起一个相似的产品。1.2 Artemis谷歌在移动 AI 代理方向的布局Artemis 是谷歌在移动端 AI 代理领域的项目。从公开信息来看它同样瞄准了“AI 在设备端自主完成多步操作”这个方向和 mobile-use 在能力面上有明显重叠。谷歌作为 Android 生态的主导者做这类项目有天然优势可以更深度地调用系统能力也能和自家的语音助手、系统级 AI 服务联动。问题就出在“能力重叠”和“代码重叠”是完全两回事。两家都做手机自动化这不叫抄袭但如果一个项目里出现了另一个项目的实现细节、命名习惯甚至注释原文那性质就变了。Minitap 团队这次的指控显然不是“你也做手机操作”这么空泛而是指向了更具体的代码复用。1.3 Minitap 的指控点不是“用了”而是“拿走了却没说”从社区流传的对比信息和 Minitap 团队的声明来看核心指控有两个层面第一Artemis 项目的部分代码与 mobile-use 高度相似已经超出了“巧合撞车”的范畴第二更关键的是谷歌在使用这些代码时没有保留 mobile-use 的版权声明也没有在项目文档中注明出处。这里我要特别强调一下“用了代码”和“拿走代码不署名”之间的区别。开源不等于放弃版权不等于“随便用”。绝大多数开源许可证都允许你复制、修改、再分发代码但前提是你要履行相应的义务其中最基础的一条就是保留原始版权声明和作者署名。如果你把代码搬走了然后把自己的名字一贴从法律上讲这叫“删除版权管理信息”在多个司法管辖区都是明确违规的。这也是为什么这个事件能在开源圈迅速发酵。大厂和小团队之间的代码纠纷本来就容易引发共情更何况“吃相难看”的程度——如果指控属实那就不是技术判断失误而是基本合规意识的缺失。2. 代码撞脸还是真抄袭判断“盗用”需要看什么很多人一看到“代码相似”就喊打喊杀但作为从业者我得说一句公道话代码相似本身不一定等于盗用。同一个功能成熟的开源写法就那么几种尤其是处理 JSON、解析 XML、调用系统 API 这类标准化操作十个开发者能写出九份差不多的代码。那到底怎么判断是“英雄所见略同”还是“复制粘贴”这里有一套相对客观的判据。2.1 开源许可证下的“合法借用”与“违规挪用”的边界要理解“盗用”的边界先得明白开源许可证的层级逻辑。不同许可证对使用者的约束完全不同我把最常见的几种列成一张表方便对照许可证商用修改后闭源分发必须保留原版权声明衍生作品开源典型代表MIT允许允许是不强制大量前端库、工具库Apache 2.0允许允许是且需保留 NOTICE不强制多数大厂开源项目GPL 3.0允许不允许是强制Linux 内核相关生态AGPL 3.0允许不允许是强制且包含网络服务数据库、服务端组件注意看表格里的第二列和第三列。MIT 和 Apache 2.0 这类“宽松许可证”给了使用方很大的自由你可以拿去商用可以改完以后不发源码唯独有一条不能省——保留原始版权声明。这句话看着简单但在真实项目里经常被忽略从 GitHub 上拉了一个仓库下来改了改就合进自己的代码库版权声明文件要么没拷要么被后来者的 LICENSE 覆盖了。回到 mobile-use 事件上如果 mobile-use 用的是 MIT 或 Apache 2.0 这类宽松许可证那谷歌“复用代码”这件事本身可能并不违法但“未注明出处”这一条直接踩中了许可证最核心的义务线。2.2 维护者通常靠什么证据锁定“复制粘贴”看一个项目是否真的“盗用”了另一个项目的代码不能靠感觉得靠证据。我在社区里围观过不少类似的纠纷维护者摆出来的证据一般集中在这么几类命名指纹某个项目里有一个不常见的函数名、类名、变量名在另一个项目里原样出现。命名这东西最诚实如果extract_screen_forest这种带个人风格的函数名出现在两个人各自的代码库里巧合的概率基本为零。注释残留开发者复制的往往不只是代码还包括注释。有时候原作者会在注释里写一句很个人化的吐槽或者写一个错别字结果被原封不动搬过去。很多“实锤”就是从这种细节里扒出来的。代码结构指纹两个文件的行数接近、函数顺序一致、空行位置一致、甚至某段奇怪的空格缩进都一模一样。这种结构化相似度靠肉眼可能看不全但用 diff 工具一比对一目了然。提交时间线mobile-use 的某个提交记录显示代码在 2024 年 3 月就存在了而 Artemis 项目的首次提交晚于这个时间点再加上名称和结构的高度吻合时间线就成了最有说服力的证据。Minitap 团队这次的指控按社区常见的“实锤”套路看大概率也是从这些角度切入。不需要逐行 100% 相同只要出现一两个“独占性指纹”就足够把“撞车”变成“复制”了。2.3 我见过的一些“低劣但真实”的复制场景说句实话我在这个行业里见过不少“复制代码”的案例水平参差不齐有些真的让人啼笑皆非。一种是“全量搬运型”。整个文件拷过去连文件头部的版权注释都没删只是把作者名字改成自己的。这种属于最懒的也是最容易实锤的因为只要原项目方一搜文件名立刻就能找到。另一种是“局部改造型”。把变量名改一圈、删几行注释、换一下函数顺序以为这样就不算抄了。这种稍微费点劲但核心逻辑、边界条件处理、异常分支几乎原样保留用相似度检测工具一跑还是能看出来。还有一种最隐蔽叫“二次创作型”。A 项目抄了 B 项目的核心逻辑B 项目抄了 C 项目的界面设计最后 C 维护者去质问 AA 一脸无辜说“我是从 B 那里学的”。这种追责链路长、证据容易断往往最后不了了之。说这些不是为了嘲讽而是想说明一个事实代码盗用在这个行业里并不罕见只是大多数时候没闹到明面上。这次 Minitap 和谷歌的争端能公开化对开源生态来说反而是一件有正面价值的事至少它把“复制代码不署名”这个问题重新放到了聚光灯下。3. 为什么谷歌这种体量的公司还会在这个坑里翻车很多人不理解谷歌啊世界级的科技巨头内部各种合规培训、代码审查流程怎么会犯这么低级的错误这恰恰是普通人对大公司流程的误解。大公司的“合规”通常做在最容易被审计的地方比如法务会盯着你用了什么付费软件的授权安全团队会检查你集成了哪些有已知漏洞的第三方库。但“从 GitHub 开源项目里复制了一段代码合入内部项目时没保留版权声明”这种事情在体量庞大的组织里监管起来远比想象中难。3.1 大公司开源流程的普遍盲区大公司的代码库是海量的一个项目动辄几百万行代码分布在几百个仓库里。谁来保证每一行代码都手续齐全实际上没人能保证。各个团队为了赶进度从 GitHub 上找现成代码是常态尤其是一些“基础设施类”的工具函数大家默认“网上都是这么写的”随手复制粘贴进代码库。真正的问题在于很多开发者把“开源”理解成了“无主”。他们没有恶意就是单纯缺乏许可证意识。看到一段代码试了一下能跑就直接用了。至于这段代码是什么许可证、要不要保留版权声明、能不能用在商业项目里很多人压根没想过。这不是某一个人的问题而是整个行业在培训和教育层面长期缺失的结果。谷歌内部的代码审查系统确实很严格会包头到接口设计、性能、安全性但对“知识产权痕迹”这一项的自动化检查其实非常有限。系统很难自动判断“这段代码跟 GitHub 上某某仓库的某段代码一致”尤其是经过变量重命名、函数拆并之后静态扫描工具的作用就更有限了。3.2 内部复制粘贴与“顺手搬运”的文化还有一个容易被忽略的因素内部复制粘贴。谷歌这种体量的公司内部有大量的共享代码库和通用组件库。一个工程师在某个内部仓库里看到一段现成的代码这段代码其实是两年前某个人从外部开源项目里带进来的版权声明早就被层层传递弄丢了。这位工程师不知道这段代码的外部来源以为是自家团队写的就拿去用了。这种“二级传播”特别可怕。原始来源的开源项目作者找谷歌算账的时候谷歌自己可能都查不清这段代码到底是从哪个内部仓库流出来的。每一层复制都会把版权信息抹掉一层几层之后就完全看不出来了。更有意思的是这种文化并不限于底层工程师。有些项目负责人为了赶工期会直接授意团队“先拿开源方案改造一下后面再整理版权”结果“后面”永远没有来。deadline 一到代码合并这件事就被遗忘了直到若干年后原作者来敲门。3.3 团队扩张、外包与收购带来的历史包袱谷歌也不是所有的代码都出自自家工程师之手。移动端 AI 代理这个赛道这两年中厂、大厂都在抢人团队扩张速度极快。新来的工程师把上一家公司的代码风格、使用习惯带来是很自然的事。有些甚至在跳槽前把自己上一家公司的项目“顺手”复制了一份作为“个人参考资料”带到了新环境。还有一种常见路径是收购。大厂收购小型创业团队直接把对方整个代码库接过来。被收购团队的项目里可能本身就有一部分代码来自其他开源项目而且没有做到完整合规。收购完成之后这些“隐藏债务”就自动转移到了大厂头上。一旦原作者维权承担舆论压力和法律责任的是谷歌而不是那个已经解散的创业团队。看到这里你应该能理解大厂翻车不是“因为它是谷歌所以不该翻车”恰恰相反正是因为体量太大、链路太长出了这种事反而更不稀奇。Minitap 这次选择把问题公开化某种程度上也是被逼无奈邮件、法务函在大厂内部流转几个月没有回音往往是常态。4. 从 mobile-use 事件看开源合规的核心常识聊完了八卦和背景这一节我想认真讲讲正事开源合规这件事到底牵扯哪些常识不管你是个人开发者还是公司员工这些内容都该刻进脑子里。4.1 署名到底怎么署才算“注明出处”“注明出处”这四个字看着简单实际做起来很多人把握不住分寸。以 Apache 2.0 为例标准做法是这样的复制代码文件时保留文件头部的版权声明和许可证声明原样不动如果你的项目整体使用了某开源项目代码应该在项目的 LICENSE 或 NOTICE 文件中列出该项目名称、作者、原始许可证类型如果修改了原作品需要在修改文件处显著标注“基于 XX 项目修改”说明你不独占代码贡献。很多开发者以为“在 README 里提一句感谢”就算注明出处了这是不对的。感谢和许可证义务是两回事感谢可以随便写想写多诚恳都行但从许可证角度你需要的是“可追溯”的署名当别人拿到你的项目时能通过你保留的信息找到原始作者这才是合规的完整闭环。我在实际项目里见过一个比较规范的示例对方在自己项目的根目录下放了 THIRD_PARTY_NOTICES.md 文件里面列出所有依赖的开源项目每一条都包含项目名、作者/组织名、许可证全文链接、以及“是否修改”的说明。这种文件在合规审计时可以直接作为证据避免了“你说你用了但查无实据”的尴尬。4.2 给个人维护者的自我保护清单回到 mobile-use 事件我可以想象 Minitap 团队现在的心情。自己辛辛苦苦写出来的东西被人拿走用了反而要反过来证明“这是我的”这个过程非常耗人。所以给所有个人项目维护者一条最真诚的建议不要等到被抄袭了才开始整理证据平时就要把“自我保护”做进项目里。我从自己的实践里总结了一份清单分享给大家LICENSE 文件永远是第一步项目创建第一天就要定好许可证并写进仓库。没有许可证的项目在法律上默认“保留所有权利”别人不能用但也不能证明你授权了什么。明确定下 MIT 或 Apache 2.0是后续所有维权的地基。保留完整的 git 提交历史从第一个 commit 开始就带上作者信息和时间戳。commit 历史是你的“最早的发表记录”一旦发生争议它就是最客观的证据。不要在代码里混入无法说明来源的片段你自己用别人的代码也要注明出处不然某天你反过来维别人的权对方翻你的仓库也能找到“你也抄了”的反击点。发布 release 时生成哈希值针对核心文件保存一份 SHA-256 校验值。如果某天别人把你的代码原样拿走你可以在维权材料里直接贴出“我的这段代码哈希是 A你发布版本里的这段代码哈希不是 A 就是 B对比一下就知道”。记录版本发布时间并做好存档GitHub 的 release 记录、npm 包发布时间、PyPI 上传时间都能证明你在某个时间点已经公开了代码。这些时间戳会被后续审计经常用到。这些工作看着零碎实际做一遍花不了多少时间。但真到了需要维权的时候它们就是你手里最硬的牌。4.3 给企业开发者的合规自查清单企业开发者的处境和个人维护者不一样你手里通常没有项目的完整决策权但你写出去的每一行代码都代表着公司的法律风险。不管你在什么公司都应该养成一个习惯在使用第三方代码前花一分钟确认它的许可证并在代码提交信息里注明来源。我自己在公司里做项目时会遵守一套简单的清单合并外部代码之前确认这三件事来源项目的许可证是什么如果是 MIT、Apache 2.0可以放心用但必须保留版权声明如果是 GPL/AGPL就要立刻停下来确认它是否会“感染”你的商业闭源项目。COPYING、LICENSE 或 NOTICE 文件是否被一并复制如果只是 copy 了源码文件没拷许可证文件严格来说已经不合规。是否在项目的根目录或 README 中记录了第三方依赖清单公司项目不比个人项目人员会流动三个月前“大家都知道的”第三方来源三个月后可能没有人说得清所以书面记录是唯一可靠的交接介质。日常开发中养成两个习惯把“确认许可证”变成条件反射每一次从网上复制代码都追一句“这是什么许可证”这也是我推荐给所有新人的习惯。在代码审查时留意可疑的外部代码痕迹比如不常见的命名风格、突兀的注释、无出处的工具类函数块。一旦团队成员提交了源代码中没有版权信息的片段要主动追问“这段代码哪来的”。听起来像是在公司里给自己找麻烦但换个角度想如果你的代码让公司吃了一场开源侵权的官司那才是真正的大麻烦。前期的多问一句永远比后期的解释十句更划算。4.4 自动化工具能帮你做什么人难免有疏忽且大型项目的第三方依赖数量动辄上百个单靠人工去查许可证不现实。好在业界已经积累了不少成熟的自动化扫描方案。像 FOSSA、Snyk、Black Duck 这类工具可以扫描项目依赖树自动匹配每个依赖的许可证类型并在发现有冲突的许可证时发出警告。GitHub 本身的依赖图功能也能显示仓库中依赖项的许可证信息。我的建议是不管公司有没有强制要求个人项目也都跑一遍这类扫描免费额度对开源项目基本够用。扫描结果不仅能让你知道自己用了哪些“有版权负担”的代码还能在项目页面上展示一个徽章证明你是“合规友好”的。这在社区里是加分项。5. 事件可能的走向与对 agent 开源生态的影响最后我们来聊聊这起事件接下来可能怎么走以及它对整个移动端 AI 代理开源生态会有哪些影响。这部分更多是我个人基于经验推演的趋势判断仅供参考。5.1 Minitap 的诉求路径从以往类似事件的处理惯例来看Minitap 方面的诉求通常会经历三个层次。第一个层次要求公开承认并补充署名。这是在开源社区最常见的第一步。维护者的核心诉求一般是“你可以用我的代码但你必须告诉大家这段代码是从哪来的”方式是修改项目仓库补上版权声明和 NOTICE 文件并在发布声明里致谢原始作者。第二个层次要求删除侵权代码。如果双方沟通不畅或者使用方拒绝承认那诉求就会升级为“请删除所有涉事代码”恢复到独立开发的状态。这一步对使用方代价极高因为你要在短时间内在不影响项目进度的前提下重写自己已经迭代过一段时间的关键模块。第三个层次正式法律途径。这一步成本最高、周期最长、对双方消耗也最大但在 License 明确且证据链完整的情况下原告的胜率并不低。所以通常在这个阶段大厂更倾向于庭前和解毕竟打官司的律师费往往高于“重新招人把代码重写一遍”的费用。根据我的观察像 Google 这种体量的公司对外回应通常会走“道歉 补署名 加强内部流程审查”的路线承认存在个别团队合规疏漏然后强调公司整体尊重开源的立场。Minitap 这边大概率也能得到自己想要的形式上的说法——包括在项目文档中补上 credits以及一篇有诚意的致歉声明。至于更进一步的赔偿围绕代码许可纠纷的案例里不是没有但比例相对有限。5.2 谷歌可能的回应与项目后续谷歌应该不会因为这件事就砍掉 Artemis 项目毕竟放眼全球几乎所有头部科技公司都在快速布局移动端 AI 代理。这个方向的战略价值太大了不太可能因为一次开源合规纠纷就放弃整条赛道。更可能的是团队会切割掉有争议的部分在内部做一次彻底的代码审查把与 mobile-use 相关的模块换成自己独立实现或基于其他合规第三方的替代方案。除此之外谷歌大概率会在内部强化一轮“开源许可证合规”培训和工具落地。实际上这类事件之后大厂都会做一轮流程补课一方面是真为了降低法律风险另一方面也要给外界一个“我们改进了”的信号。比较讽刺的是类似的事件在这几年并不少每次发生后都能短暂地引起行业对合规的重视但热度一过又会回到原来的状态。5.3 对整个开源协作体系的警示如果让我说这起事件真正的价值我觉得不是“谷歌如何回应”而是它给整个行业敲了一声警示钟。移动端 AI 代理是过去一两年增长最快的开源赛道之一。大量新项目像雨后春笋一样出现很多团队为了快速入场会去研究甚至直接借鉴头部项目的实现。从 mobile-use 这类基础框架被大规模复用的概率来看类似“未署名使用”的情况可能不少只是绝大多数没有浮出水面。这起事件之后预计会有两个层面的正向变化。在维护者层面更多项目负责人会开始认真对待许可证版权声明不会再把“开源”两个字当成“无版权”的同义词。在企业层面技术决策者会在引入外部开源代码前加入更严格的许可证审查流程尤其是在那些会被用于商业产品和对外发布的项目上一步都不该省。开源的本质是协作不是掠夺。协作的前提是彼此尊重版权这也是 mobile-use 事件最值得被记住的一点。最后再分享一点个人的体会。我自己的小项目也曾经被人整段搬走过对方把 LICENSE 文件删了然后冒充成自己的东西挂到另一个平台。我当时气得好几天睡不着但后来想明白了与其生气不如把项目做得更好、更独特让后来者一眼就能看出谁才是正主。同时我也更加坚定地在每一个新项目里把 LICENSE、NOTICE、CONTRIBUTING 和 release 记录做得完整不是为了炫耀什么就是为了哪天真要上场对质的时候手里有牌可打。希望 mobile-use 事件最终能有一个体面的结局也希望每一位开发者的劳动成果都能得到应有的署名。毕竟代码可以被复制但署名是创作者该有的尊严。
