Ente Locker 是否抄袭了 FairScan 的代码?开发者公开对比证据
Did Ente Locker copy my code without attribution?
FairScan 开发者称 Ente Locker 1.0.9 的图像处理代码疑似从 FairScan 的 Kotlin 实现近乎直接翻译为 Rust,包括相同结构、算法、函数与变量命名及硬编码值。
2026年10月12日
我上一篇博客文章解释了为什么我选择将 FairScan 开源。我特别提到,在发布 FairScan 的代码时,我知道存在风险,并且我已准备好接受它。我没想到这么快就要面对这一现实。
过去几周发生在我身上的事
在9月16日之前,我从未听说过 Ente。那天,我收到了他们一位工程师发来的邮件。邮件感谢我开发了 FairScan,并宣布 Ente Locker 应用现在将 FairScan 的分割模型作为新文档扫描功能的一部分。邮件提到了一篇博客文章,该文章对 FairScan 的模型表示了致谢,并声称Ente“从头编写了围绕它的图像处理”。
我在 FairScan 的图像处理上投入了大量精力,所以我很好奇 Ente 是如何解决同样的问题的。我发现,多个图像处理的实现似乎几乎是将 FairScan 的实现从 Kotlin 直接翻译成 Rust。
我在9月17日通过邮件回复。那位工程师很快回复说,他们的博客文章“措辞可以更好”,并且已经重新措辞。我看到新版本用相当模糊的说法替换了“从头编写”的说法,但仍然坚持分割模型。
同一天,我发送了一组链接来比较 FairScan 和 Ente 的代码。我提到,我在 Ente 仓库中找不到任何对 FairScan 的署名。
9月21日,我收到了同一位工程师的回复,称那些是“相当标准的图像处理方法”,并且代码随后已被完全重写。在他们的仓库中,我发现一个影响超过6,000行的拉取请求。当然,它无法改变 Locker 1.0.9 中分发的代码。
同一天,我向 copyright@ente.com 发送了一封邮件,询问公司对此事的看法。截至10月12日,我仍未收到回复。
9月29日,我在 Mastodon 上发布一篇帖子,链接到一个 GitHub gist,其中记录了这个时间线以及代码相似之处。
标准方法还是直接翻译?
欢迎查看上面链接的 gist 中的代码比较,形成你自己的看法,即使你不是开发者。你可以使用浏览器的“分屏视图”进行并排比较。这里有一个例子:
在我比较的实现中,我发现了以下相似之处:
- 相同的整体结构
- 相同的算法
- 相同的函数和变量名称
- 相同的硬编码值
对我来说,这看起来几乎是从 Kotlin 到 Rust 的直接翻译。有差异,但不容易发现。
当然,我对这段代码有特殊的立场。我写了它,所以我知道它来自哪里。我知道这是大量努力的结果:
- 我研究了现有的技术,如多尺度 Retinex、单视图测量或灰度世界白平衡。
- 我组装了一个适合分割模型的图像处理管线。
- 我从一些简单的技术开始(如 Douglas Peucker),后来替换了它们。
- 我开发了自己的算法,根据轮廓方向来近似四边形(这可能不是最优的)。
- 我不得不就扫描应该是什么样子做出选择:并非所有应用都做出相同的选择。
- 我在数百张图像上测试了我的实现的行为及其参数值。
- 我在自己的实现中修复了许多 bug。
- 我写了一些博客文章,讲述我所做的众多迭代中的一部分,展示我的试错过程。
这怎么能被称为“标准方法”?我想知道在哪里可以找到类似的代码,因为那会省去我很多工作。事实上,如果它已经存在,我可能就不会开始 FairScan 了。
沉默让我气馁
Ente 没有公开或私下承认代码相似性是一个问题。针对我的对比,那位工程师将代码描述为“相当标准的图像处理方法”,但这并没有回应我指出的相似之处。如果没有问题,为什么他们在收到我的邮件后 3 天内重写了 6000 多行代码?为什么他们不回答我的问题?
关键在于:如果 Ente 的代码源自 FairScan,从而使其受 GPL 约束,那么它的分发就引发了关于是否遵守该许可证的疑问。
我应该采取法律行动吗?这不是我想要的 FairScan 的结果。但我也不希望这个问题一直得不到解决,让别人仅凭 Ente 的公开声明来形成自己的看法。
Ente 在社交媒体和 Reddit 等平台上大力宣传这一新功能。其 CEO 公开称赞 Locker,称:“我用过的最好的开源文档扫描仪”。
就我而言,到目前为止我一直非常谨慎。我最初只与 Ente 私下沟通。当我在 Mastodon 上发帖时,内容非常客观:我没有做出耸人听闻的指控,也许正因为如此,几乎没有引起什么反应。
我怀疑很少有人知道这个情况。从外部看,Ente 可以继续推广其扫描功能,而不必回应我提出的担忧。问题仍未解决,Ente 可以继续无视我。
几乎没有人反应,这让我感到气馁。过去几周,我花在这件事上的时间比花在 FairScan 其余部分上的还多。它可能不值得这样,但我就是无法接受这种情况。开源的透明度和问责制意义何在?
我真心希望听到其他看过这些对比的开发者的意见。这些相似之处是否表明 Ente 的代码源自 FairScan?我将感激任何能就此案分享独立观点的人。
开源不等于尊重
这段经历让我重新审视自己对开源的立场。
FairScan 是我尝试打造的一款尊重他人的应用:一款既尊重其用户、又在制作方式上尊重他人的应用。我想我现在更清楚地认识到,这两个方面并不一定相辅相成。我仍然相信,开源是用户评估一款应用是否可信的最佳方式之一(注意:它仍可能包含反功能)。然而,完全有可能以不尊重他人的方式制作开源应用,例如复制粘贴代码而不注明其来源。
是的,我在发布代码之前所识别的风险是真实存在的。事实上,任何开源代码都可能被复制而不注明出处。我知道闭源软件可能会在不符合其许可证的情况下使用开源代码,而且证明这种违规行为可能很困难。也许我接受了这个风险,因为我无法知道它何时真正发生。我没有考虑到的是,开源软件也可能这样做,而在那种情况下,我能够亲眼看到。
我知道其他项目可以重用 FairScan 的代码,即使他们不认同我的愿景,但我确实期望代码的来源会被诚实地承认。
所发生的事情是我没有准备好的。我在 FairScan 上投入了很多自己,也许太多了:看到我的工作被贬低得好像毫无价值,很难不往心里去。今天,这让我质疑自己为开源软件做贡献的动力。
来源:Hacker News · fairscan.org
