美团AI浏览器涉嫌抄袭开发者开源代码引发争议,最终双方达成和解并开源

美团AI浏览器被指抄袭开源项目,开发者维权后双方和解,相关代码已开源。开源协议再次引发关注。

原文标题:美团 AI 浏览器遭开发者公开维权!目前双方已和解,相关代码已完成开源处理

原文作者:AI前线

冷月清谈:

美团旗下光年之外团队发布的新产品Tabbit AI浏览器,被独立开发者@梦溪睡了吗 指控抄袭其开源项目“陪读蛙”。开发者展示了Tabbit浏览器和陪读蛙的对比图,指出两者界面和布局相似,甚至图标文件名都未修改。该开发者认为,美团未遵守GPL开源协议,未开源其产品。Tabbit官方回应称,因未及时关注到开源协议变更而使用了该项目代码,并表示将移除相关代码并开源项目,同时寻求作者授权。目前,双方已达成和解,相关代码已完成开源处理。此次事件引发了关于开源协议合规性的讨论,提醒开发者在使用开源代码时务必仔细阅读并遵守相关协议。美团官方的处理态度较为积极,在一定程度上挽回了声誉。

怜星夜思:

1、这次美团AI浏览器被指抄袭开源项目,最终和解并开源了相关代码,你觉得这件事对开源社区有什么影响?以后大家在用开源项目的时候会不会更谨慎了?
2、GPL协议要求使用其代码的产品必须开源,但如果一个商业公司想利用GPL协议的代码,但又不想开源自己的全部产品,有什么办法可以规避吗?
3、作为开发者,你经历过或者听说过哪些利用开源项目但不遵守开源协议的事件?

原文内容

左右滑动查看更多图片

整理|华卫

“市值几千亿美元的公司,竟然直接来蹭我的代码,真不要脸。”

昨日,美团旗下的光年之外团队宣布,其全新产品Tabbit AI浏览器已进入公测。据介绍,Tabbit的核心突破在于通过“智能代理”“妙招”“脚本”等自动化执行能力,在浏览器上实现了“人机并行”的高效协作。为了让AI能力无缝融入工作流,光年之外团队还对Tabbit浏览器的核心交互组件进行了全面重构。

今天凌晨,独立开发者@梦溪睡了吗突然在 X 上喊话称:“美团这么大一家公司,居然把我的代码抄去做他们自家的 AI 浏览器,而且连赞助都不给我?”

据悉,该开发者做了一款AI驱动的浏览器语言学习扩展插件,支持沉浸式翻译、文章解析、多 AI 模型切换等功能,名为陪读蛙,并且在Github上开源已久。从代码提交记录来看,该项目最早的代码提交可追溯至9个月前。截止目前,该项目已获了3.9k stars。

陪读蛙开源项目链接:https://github.com/mengxi-ream/read-frog

这位开发者放出了多张Tabbit AI浏览器和陪读蛙的产品对比图,两者的界面和布局极为相似,图标文件名也完全没改,“居然还是 read-frog”。并且其称,“我的代码中有充分的证据链。”目前还未放出,但该开发者表示“稍后会做个视频”。

有网友说,“开源不就是为了让别人复制吗?”该开发者则表示,根据其用的 GPL 开源协议,任何使用其代码的产品都必须开源。他还隔空喊话道,“所以美团,你们这款新 AI 产品开源了吗?”值得一提的是,这位独立开发者的个人主页信息显示,其曾担任字节跳动高级软件工程师。

下午,Tabbit 官方在小红书平台发布声明称,第一时间对项目的开源和合规情况进行了深度自查,2025年12月30日团队在开发翻译功能时关注到该项目仓库中并未包含任何开源协议声明,后经评估进行了项目fork,项目原作者是在1月2日为其添加了GPLv3协议,并称“由于未继续合并原项目的后续代码,未能及时关注到此次协议变更”。当时,这名开发者回应道:“建议您先删除这份声明,和我沟通完毕之后再发。不然我可能要给您在小红书科普为什么您这个说法站不住脚了。”

刚刚,Tabbit 官方再次发布声明称,他们将从Tabbit 浏览器新版中移除此翻译项目代码,并已将此项目完整开源;已跟read frog的作者沟通项目License的正式授权,授权后再更新代码并恢复此功能。这次该开发者表示,“对方态度积极,处理及时,可以确认本次问题并非出于主观恶意,而是对开源协议理解和合规流程不够严谨所致。”

维权成功,狠狠地支持一波!估计以后大厂用开源项目之前会更仔细地review一下compliance流程了,对整个行业来说都是好事。不过,小作坊项目可能还是防不胜防,只能说开源协议真的要好好写清楚啊!

从法律角度来说,规避GPL协议最好的办法就是不违反它。如果一定要用,又不想开源全部代码,可以考虑双重许可(dual licensing),一部分代码用GPL,另一部分采用更宽松的许可协议。但这需要与代码的版权所有者协商。

听说过一个更离谱的,某大厂直接把一个开源项目fork下来,删掉了原作者的版权声明,换上了自己的。结果被原作者发现了,直接发了个帖子曝光,引发了很多人的关注,最后大厂不得不道歉并恢复了原作者的版权声明。这种行为简直是太low了!

其实我觉得最简单的办法就是…抄袭啊! 把代码读懂了,自己重新写一遍,就没GPL什么事儿了(狗头)。当然这是个玩笑,各位大佬千万别当真!还是要尊重开源协议。

这问题问得好!GPL的传染性确实让不少商业公司头疼。规避方法嘛,主要有几种:

1. 不直接使用GPL代码:这是最干净利落的方法,自己重写或者找其他协议的代码替代。
2. 模块化隔离:将GPL代码做成独立的模块,通过API或者其他接口与商业代码交互,避免直接链接。
3. 获得商业许可:如果原作者允许,可以购买商业许可,这样就可以不受GPL约束了。

当然,具体怎么操作还得看实际情况,必要时可以咨询法律人士。

我之前在一家小公司实习的时候,他们直接拿了一个AGPL的库,改了改就用到商业项目里了,也没开源,也没买授权。后来被原作者发现了,直接发律师函,赔了不少钱,老板差点跑路。

之前在GitHub上看到过一个项目,是几个大学生做的,用了不少其他的开源库。结果有个库的作者发现他们的项目闭源,就去提了issue,要求他们遵守协议。结果那几个大学生直接把issue关了,还把作者拉黑了… 只能说,有些人是真的不懂…

我觉得这事儿对开源社区是个警醒。以后用开源项目肯定得更谨慎,不光要看代码,还得仔细研究License,免得踩坑。同时,也提醒开源作者要明确标明License,最好在项目初期就搞定,省得后续扯皮。

这事儿短期内可能会让一些公司在使用开源项目时更小心,但长期来看,我觉得影响不大。毕竟开源的本质还是为了促进共享和创新。重要的是建立更完善的开源合规机制,让企业和开发者都能更好地参与其中。