PhotoSuite DMCA Takedown and PhotoSplice Relaunch: What Windows Users Should Know

What happened​

PhotoSuite went public on GitHub in late September. According to XDA-Developers, Photopea creator Ivan Kutskir then accused it of repackaging his work. The developer, who goes by eolix, admitted PhotoSuite began from an unofficial offline copy of Photopea that someone else had posted to GitHub. A Hacker News thread quotes eolix as saying the README credits Photopea as the primary inspiration and prior art.

Photopea is a browser-based editor. It is not open source. Kutskir's DMCA notice says it is a website of around 5 MB of code, mostly JavaScript, and because it is a web app that code is accessible to anyone. Being able to see code in a browser is not the same as having permission to reuse it.

What the takedown record shows​

The notice is published in GitHub's public DMCA repository, dated October 14, 2026. It lists the PhotoSuite repository alongside several other Photopea copies and mirrors. XDA says GitHub disabled PhotoSuite in mid-October, along with copies other users had already made.

Some caveats matter here:

• A notice is a claim, not a verdict. It is the claimant's sworn statement. It is not a court finding.
• GitHub is not the judge. Its guidance says it exercises little discretion beyond checking that a notice meets the DMCA's minimum requirements. The parties have to evaluate the merits themselves.
• The takedown covered whole networks. The notice says GitHub processed networks of 170, 206 and 118 repositories because each exceeded 100. So the action was not aimed at PhotoSuite alone.
• Affected users can respond. GitHub says it re-enables content within 10–14 days after a counter-notice unless the claimant says it has started legal action.

Disputed claims​

Several points in the public discussion are contested and unproven:

• One GitHub commenter said they compared the codebases and found over 99% of PhotoSuite original. Kutskir says he can trace every line back to Photopea. Neither side's methodology is independently reviewable here.
• Kutskir believes AI did most of the work. XDA notes eolix never confirmed that, so it is a suspicion. In a GitHub issue, eolix wrote that PhotoSuite was "very clearly custom work (even if LLMs were involved)."
• A separate GitHub issue on the Photopea repository, opened by another user, alleges license violations in Photopea's own code. Those are allegations in a thread, not verified findings. The issue was closed in early October.

PhotoSplice: the relaunch​

The old repository was taken down. The same developer then published PhotoSplice. The current repository describes it as built on PhotoCraft rather than on any Photopea lineage, and it is licensed MIT or Apache-2.0. According to its README, it ships:

• A Windows 10+ x64 .msi installer and a portable .zip.
• macOS 11+ and Linux packages.
• Claims of PSD/PSB compatibility, local processing, and no account or telemetry.

Linux Creators reported on October 20 that the README still carried the PhotoSuite title, which suggests the same project under a new name. It also cautioned that nothing it reviewed rebuts Kutskir's accusation with public technical evidence. That site added that MIT and Apache-2.0 permit modifying and redistributing PhotoCraft's code as long as notices are kept. So the licensing of the new engine looks properly attributed, but that does not settle what the earlier history contained.

A user opened an issue on the PhotoSplice repository calling it a copy of PhotoCraft. In reply, eolix said PhotoSplice aims to simplify the UI and avoid resembling PhotoCraft. Treat all of this as project claims, not audited facts. No independent security or performance validation turned up.

A vetting checklist for any open-source app​

XDA's author argues you don't need to read code to ask better questions. These checks fit that view, with some limits added.

1. Read the license for what it covers. A license shows the terms a publisher offers for material they can license. It does not prove every included component is theirs. If a README credits another app, check whether that app is itself open source. A thank-you is not permission.
2. Scroll back to the first commit. GitHub's Insights and commit views show activity, contributions and additions and deletions. XDA reports that PhotoSuite's public history opened with roughly 1,000 files at once and four releases in five days. That is a reason to ask questions, not proof of copying. Developers often work privately first, import history, or automate builds.
3. Open the closed issues. How a maintainer handles awkward provenance questions is informative. Banned commenters and vanished Issues tabs are red flags, but they are not evidence of infringement.
4. Search outside the repository. Look up the project name with words like "copy", "license" or "DMCA" on Reddit and Hacker News. Treat hits as leads and confirm them against primary records such as the project itself or GitHub's DMCA repository.
5. Separate looks from code. Copying Photoshop's layout is a long-accepted practice. The dispute here concerns code reuse, not interface resemblance. Equally, clean, documented code doesn't show the code is original.

What this means for Windows users​

For Windows 11 and Windows 10 users, installing a desktop editor from a young repository is a trust decision. A provenance dispute adds legal and reputational risk on top of the usual security questions. For work involving client files, a sensible approach is to:

• Test on copies of your files.
• Wait for community scrutiny.
• Consider legal advice where the stakes are high.

The broader point is that an open-source license is useful licensing information. It is not a provenance audit or a trust certificate. GitHub's own policy leaves much of the checking to the parties involved. Kutskir has also said earlier reports about similar copies were ignored, per a Hacker News comment. In practice, that leaves some of the diligence with whoever is about to click Install.