A developer spent fourteen years writing a photo editor. One person, one project, algorithm after algorithm, since 2012. This week someone else shipped his work on GitHub as a polished desktop app under a new name, and when the original author showed up in the issue tracker with proof, the response was not an apology. It was a ban.
If you publish open source, or you install it, this story matters to you directly. The tools that made this clone possible are the same ones on your machine. And the defense against it costs ten minutes of license hygiene, not a lawyer.
What actually happened
The story broke on Hacker News when Ivan Kutskir, the creator of Photopea, filed issue #77 against a project called PhotoSuite. Photopea is his browser-based Photoshop alternative. He built and has run it alone since 2012, and it reportedly earns him millions of dollars a year from ads and premium subscriptions.
His accusation was specific. He wrote that PhotoSuite started from a mirrored copy of his code, and that he could show copied logic for every line in the app. In his own words from the thread, he said that a project like this can be made from his main JavaScript file in two hours using Claude. The PhotoSuite author's own reply, quoted in the thread, confirmed the lineage: the project began from an unofficial offline mirror of Photopea, was then rewritten and restructured into roughly 330 source files, and shipped with a GPL-3.0 license and a website presenting it as original work.
The details that make this a pattern rather than a one-off:
- The rewrite does not clean the provenance. Changing variable names and restructuring files into 330 modules does not create new copyright. The derivative chain still runs back to code published with no license at all, which means full copyright, which means no reuse rights.
- The instructions trailed the capability. AI tools happily rewrite entire codebases, but none of them checks whether the input code was licensed for reuse. The bottleneck moved to a judgment call the model never makes.
- Enforcement is manual and slow. Kutskir told the thread he had tried reporting similar repos before and was ignored by GitHub. The copied project kept its stars and its website throughout the dispute.
- The community response was messy. Before the thread was deleted, the PhotoSuite author accused Kutskir of spamming the issue tracker and banned him. Several commenters noted that sub-agent accounts had shown up arguing on the author's behalf.
Kutskir's summary is the line worth remembering: AI can now de-obfuscate code that was ever published, convert binaries to readable source, and recreate software on request. But none of that would be possible if a real person had not spent thousands of hours building the original years sooner. He said he loves seeing AI create things that did not exist before. What he keeps seeing instead is approximations and disguised forks.
Why clean-room is doing heavy lifting here
Defenders of AI rewrites lean on the clean-room concept, so it is worth being precise about what it means. A genuine clean-room reimplementation never exposes the implementing team to the original source code. Engineers work from a written specification of behavior, and a separation reviewer certifies nobody saw the code. That is how legitimate compatible implementations get built.
An AI rewrite inverts every part of that. The model reads the original source directly, all the way through. The output is a transformation of a copyrighted work performed by a tool that has no license to hold and no liability to carry. Calling the result clean-room because a model touched it, rather than a human, has no basis in copyright law anywhere.
The related confusion is inspiration versus derivation. Reimplementing Photoshop's behavior from public documentation and screen observation, the way Photopea itself was originally built, is original work. Feeding Photopea's own bundle into a rewrite pipeline is not. The input determines the classification, not the effort applied afterward.
One more trap: an OSI-approved license file in a repo proves nothing about the code inside it. Anyone can drop GPL-3.0 into a directory. A license is a grant from the copyright holder, and if the committer never held rights to the code, the grant is void. Users and downstream packagers inherit that void.
The checklist
Run this on any repo you publish, and in reverse on any repo you are about to depend on or ship.
Before you publish anything:
- Write the LICENSE file first. No license means all rights reserved, for everyone, including people who want to legitimize your work later. Pick MIT, Apache-2.0, or GPL-3.0 deliberately.
- Record provenance where the code can see it. A NOTICE or PROVENANCE file listing major inputs, inspirations, and copied snippets with their licenses. If a chunk comes from Stack Overflow or a blog, note it. Future-you and future-acquirers both need this.
- Never commit code whose origin you cannot state. "It came out of the model" is not an origin. If generated code is substantially similar to something you have seen, treat it as a copy of that thing.
- Audit before you promote. If you built on a mirror, a scraped bundle, or an unlicensed fork, the burden sits with you. Renaming files afterward does not move it.
Before you install or adopt anything:
- Check the earliest commit, not the README. A project whose first commit is a full application with no history deserves suspicion. Growth rings matter.
- Search the codebase for the original's fingerprints. Unique identifier names, error strings, compression tables, asset files. In this case the copied bundles were found intact inside the repo.
- Verify the claimed license against the actual holders. GPL code in a repo whose upstream has no license is a liability you are importing, not a freedom you are gaining.
- Check who can receive reports. A project whose maintainer bans the original author from the issue tracker is telling you how disputes get handled.
What I would tell the platforms
I have not been through anything like this myself, and I want to be explicit about that. What follows is opinion from watching this dispute, not experience.
The gap that made this week ugly is procedural. GitHub's DMCA process exists, but it was built for copied binaries and verbatim file trees, and it takes a month. An AI-assisted derivative has neither, so the burden falls on a solo developer to argue line-by-line similarity in public, in a thread controlled by the person accused.
Platforms could fix the cheap parts. Fingerprint provenance at push time and flag repos whose code is a near-transform of a known project. Make license attestation a metadata field rather than a text file anyone can drop in. Route reports about renamed-but-structurally-identical code to a human faster than the standard copyright queue. None of this requires solving AI authorship in general. It requires treating "structurally similar to an existing project, history starts last month" as the review trigger it obviously is.
Until then, the realistic defense is what Kutskir did, only faster: publish with clear licenses, keep provenance records, and build a public trail showing your authorship over time. Fourteen years of public history is ultimately what made his case unignorable.
The takeaway
The uncomfortable summary of this week: AI can now clone a maintained software product fast enough that the clone reaches production polish before the legal process even starts. The clone inherits none of the obligations and all of the upside unless something in the pipeline pushes back. That something is currently a human being with a GitHub issue and a decade of receipts.
Ten minutes of license hygiene on your own repos, and one earliest-commit check before you star or install someone else's, is the whole checklist. Do both this week.
I write about AI engineering, open source, and backend development every week. Subscribe, it is free.
Have you found AI-rewritten copies of your own projects, or been burned by an unlicensed dependency? What did you do about it?
If this was useful, save it. The checklist above is the part worth keeping.
Top comments (0)