本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

Did Ente Locker copy my code without attribution?

Did Ente Locker copy my code without attribution? October 12, 2026 The last blog post I wrote explained why I chose to make FairScan open source. In particular, I said I knew there was a risk when I published FairScan’s code and I was ready to accept it. I didn’t expect to face that reality so soon.

Ente Locker 是否在未署名的情况下复制了我的代码？2026 年 10 月 12 日。我在上一篇博文中解释了为何选择将 FairScan 开源。我特别提到，在发布 FairScan 代码时，我就知道存在风险，并且做好了承担的准备。但我没想到这么快就要面对现实。

What happened to me over the past few weeks I had never heard of Ente before September 16. On that day, I received an email from one of their engineers. The message thanked me for FairScan and announced that the Ente Locker app now used FairScan’s segmentation model as part of a new document scanning feature. It referred to a blog post that credited FairScan’s model and claimed that Ente “wrote the image processing around it from scratch”.

过去几周发生的事情：在 9 月 16 日之前，我从未听说过 Ente。那天，我收到了一位工程师的邮件。邮件感谢了我对 FairScan 的贡献，并宣布 Ente Locker 应用现在将 FairScan 的分割模型用作其新文档扫描功能的一部分。邮件中提到了一篇博文，该博文归功于 FairScan 的模型，并声称 Ente “从零开始编写了围绕它的图像处理代码”。

I had put significant effort into FairScan’s image processing so I was curious to see how Ente solved the same problems. What I found is that multiple image-processing implementations appeared to be almost direct translations of FairScan’s implementations from Kotlin to Rust. I replied by email on September 17. The engineer quickly answered that their blog post “could have been better phrased”, and that it was reworded. I could see that the new version replaced the “from scratch” claim with something rather vague and still insisted on the segmentation model.

我在 FairScan 的图像处理上投入了大量精力，因此我很好奇 Ente 是如何解决同样问题的。我发现，多个图像处理实现看起来几乎就是将 FairScan 的 Kotlin 实现直接翻译成了 Rust。我在 9 月 17 日回复了邮件。该工程师很快回答说，他们的博文“措辞可以更好”，并已进行了修改。我看到新版本用一些模糊的说法取代了“从零开始”的声明，但仍然坚持使用该分割模型。

The same day, I sent a list of links to compare FairScan and Ente’s code. I mentioned that I couldn’t find any attribution to FairScan in the Ente repository. On September 21, I received a reply from the same engineer that those were “fairly standard image-processing methods” and that the code had been subsequently fully rewritten. In their repository, I found a pull request affecting more than 6,000 lines. Of course, it cannot change the code that was distributed in Locker 1.0.9.

同一天，我发送了一份对比 FairScan 和 Ente 代码的链接列表。我提到在 Ente 的代码库中找不到任何对 FairScan 的署名。9 月 21 日，我收到了同一位工程师的回复，称这些是“相当标准的图像处理方法”，并且代码随后已被完全重写。在他们的代码库中，我发现了一个涉及超过 6000 行代码的合并请求。当然，这无法改变 Locker 1.0.9 版本中已经分发的代码。

On the same day, I sent an email to copyright@ente.com to ask for the company’s view on this. As of October 12, I still haven’t received an answer. On September 29, I published a post on Mastodon linking to a GitHub gist where I documented this timeline as well as code similarities.

同一天，我向 copyright@ente.com 发送了邮件，询问公司对此事的看法。截至 10 月 12 日，我仍未收到回复。9 月 29 日，我在 Mastodon 上发布了一篇文章，链接到一个 GitHub Gist，记录了这一时间线以及代码的相似之处。

Standard methods or direct translation? Feel free to have a look at the code comparisons in the gist linked above and form your own opinion, even if you’re not a developer. You can use the “split view” of your browser for side-by-side comparisons. Here’s an example: In the implementations I compared, I found the following similarities: The same overall structure, The same algorithms, The same names for functions and variables, The same hard-coded values.

是标准方法还是直接翻译？即使你不是开发人员，也欢迎查看上述 Gist 中的代码对比并形成自己的观点。你可以使用浏览器的“分屏视图”进行并排比较。举个例子：在我对比的实现中，我发现了以下相似之处：相同的整体结构、相同的算法、相同的函数和变量命名、相同的硬编码值。

To me, it looks like an almost direct translation from Kotlin to Rust. There are differences but they’re not easy to spot. Of course, I have a special position about this code. I wrote it, so I know where it comes from. I know it’s the result of a lot of effort: I researched existing techniques like multi-scale Retinex, single view metrology, or gray world white balance. I assembled an image pipeline that fits the segmentation model.

对我来说，这看起来几乎就是从 Kotlin 到 Rust 的直接翻译。虽然有差异，但并不容易发现。当然，我对这段代码有特殊的立场。是我写的，所以我知道它从何而来。我知道这是大量努力的结果：我研究了多尺度 Retinex、单视图测量或灰度世界白平衡等现有技术。我组装了一个适合该分割模型的图像流水线。

I started with some simple techniques (such as Douglas Peucker) that I later replaced. I developed my own algorithm to approximate a quad based on contour orientation (which is probably not optimal). I had to make choices about what a scan should look like: not all apps make the same choices. I tested the behavior of my implementations and their parameter values on hundreds of images. I fixed many bugs in my implementations. I wrote blog posts about some of the numerous iterations I made, illustrating my trial and error process.

我最初使用了一些简单的技术（例如 Douglas Peucker），后来又将其替换了。我开发了自己的算法，根据轮廓方向来近似四边形（这可能不是最优的）。我必须对扫描结果的外观做出选择：并非所有应用都会做出相同的选择。我在数百张图像上测试了我的实现行为及其参数值。我修复了实现中的许多错误。我写过关于我所做的大量迭代的博文，阐述了我的试错过程。

How can that be called “standard methods”? I would like to know where similar code can be found because it would have saved me a lot of work. Actually, if it already existed, I would probably not have started FairScan.

这怎么能被称为“标准方法”呢？我很想知道在哪里可以找到类似的代码，因为那会节省我大量的工作。事实上，如果它已经存在，我可能就不会启动 FairScan 了。

Silence discourages me. Ente has not acknowledged the code similarities as an issue, publicly or privately. In response to my comparisons, the engineer described the code as “fairly standard image-processing methods”, but this didn’t address the similarities I had pointed out. If there’s no problem, why did they rewrite more than 6,000 lines in 3 days after my email? Why don’t they answer my questions?

沉默让我感到沮丧。Ente 无论是在公开场合还是私下里，都没有承认代码相似性是一个问题。针对我的对比，那位工程师将代码描述为“相当标准的图像处理方法”，但这并没有解决我指出的相似性问题。如果没问题，为什么他们在收到我的邮件后 3 天内重写了 6000 多行代码？为什么他们不回答我的问题？

Here’s the key: if Ente’s code was derived from FairScan in a way that makes it subject to the GPL, its distribution raises questions about compliance with that license. Should I take legal action? That’s not what I want for FairScan. But I also don’t want this issue to remain unaddressed, leaving others to form their opinion based on Ente’s public statements alone.

关键在于：如果 Ente 的代码是从 FairScan 衍生而来，使其受 GPL 协议约束，那么其分发行为就引发了关于是否遵守该许可的问题。我应该采取法律行动吗？这不是我希望 FairScan 面对的。但我也不希望这个问题被搁置，让其他人仅凭 Ente 的公开声明来形成自己的观点。

Ente widely promoted the new feature on social media and platforms such as Reddit. Its CEO praised Locker publicly with these words: “Best opensource document scanner I’ve ever used”. On my side, I’ve been very careful until now. I initially communicated only privately with Ente. When I published a Mastodon post, it was very factual: I didn’t make spectacular accusations and maybe because of that, there were almost no reactions. I suspect very few people know about this situation.

Ente 在社交媒体和 Reddit 等平台上广泛宣传了这一新功能。其首席执行官公开称赞 Locker：“这是我用过最好的开源文档扫描仪”。就我而言，到目前为止我一直非常谨慎。我最初只与 Ente 进行私下沟通。当我发布 Mastodon 帖子时，内容非常客观：我没有进行耸人听闻的指控，也许正因如此，几乎没有人做出反应。我怀疑很少有人知道这种情况。

From the outside, Ente can continue promoting its scanning feature without having to address the concerns I’ve raised. The issue remains unresolved and Ente can continue ignoring me. The fact that almost no one reacted is discouraging to me. Over the past few weeks, I’ve spent more time thinking about this than working on the rest of FairScan. It probably doesn’t deserve it but I simply can’t accept that situation. What’s the point of open-source transparency and accountability?

从外部看，Ente 可以继续推广其扫描功能，而无需解决我提出的担忧。问题仍未解决，Ente 可以继续无视我。几乎没有人做出反应的事实让我感到沮丧。在过去的几周里，我花在思考这件事上的时间比处理 FairScan 其他工作的时间还要多。它可能不值得我这样做，但我实在无法接受这种情况。开源的透明度和问责制还有什么意义？

I’d genuinely like to hear from other developers who have looked at these comparisons. Do these similarities suggest that Ente’s code was derived from FairScan? I would be grateful to anyone who can share an independent perspective on this case.

我真心希望听到其他看过这些对比的开发者的意见。这些相似之处是否表明 Ente 的代码源自 FairScan？如果有人能分享对此案的独立看法，我将不胜感激。

Open source doesn’t equal respect. This episode makes me take another look at my position about open source. FairScan is my attempt to make a respectful app: an app that is both respectful to its users and respectful in the way it’s made. I think it’s now clearer to me that those two.

开源并不等于尊重。这件事让我重新审视了自己对开源的立场。FairScan 是我尝试制作的一款尊重他人的应用：一款既尊重用户，又在制作方式上尊重他人的应用。我想我现在更清楚了，这两者……