# Vibecoding Isn't a Crime. How to Deal with Flatpak Flathub Refusals and Actually Distribute Your App on Linux
> Source:
> Published: 2026-09-21 19:58:08+00:00
# Vibecoding Isn't a Crime. How to Deal with Flatpak Flathub Refusals and Actually Distribute Your App on Linux
You built something. Maybe you used Cursor, Claude Code, or just had a long conversation with an LLM that ended up generating most of your codebase. Your app works. It solves a problem. You packaged it as a Flatpak because that's what you're supposed to do on Linux in 2026: one format, every distro, sandboxed, clean.
Then Flathub rejects you.
Because a reviewer *suspected* you used AI to write your README.
## What happened
On May 29, 2026, Flathub updated its Generative AI policy. The old version had nuance. It restricted submissions where "most code was AI-generated without meaningful human involvement." The new version is a wall:
Applications containing AI-generated or AI-assisted code, documentation, or other content are not allowed.
This covers everything: the app itself, the Flatpak manifest, the metadata, the build scripts, the docs, and the text of your pull request. Automated Copilot reviews on GitHub? Banned. Asking an AI to review your submission? Also banned.
The policy allows "exceptions for mature, well-maintained projects," but nobody can tell you how to get one. There's no application form, no clear criteria. It's an escape hatch that everyone is told exists but nobody can find.
Flathub maintainer Bart Piotrowski described the reasoning bluntly: he's tired of "entitled submitters acting as if they were bestowing their brilliant software upon us idiots who are rejecting it." The enforcement, he says, is about managing a flood of low-quality submissions from people who don't understand what they're submitting.
Fair enough. But the policy doesn't distinguish between someone who prompted an LLM to generate an entire app in five minutes and a developer who used Copilot for autocomplete while writing 90% of the code themselves. A throwaway vibecoded tool and a serious project with 80,000 lines of hand-reviewed Rust get the same treatment.
## The problem is structural
The policy is asymmetric, and that's what makes it harmful.
Open-source code is public. A Flathub reviewer can open your repo, run some heuristics, spot "signs of AI generation" (verbose commit messages, suspiciously clean code with no TODOs) and reject you. Fair game.
Proprietary apps, though. Closed-source Electron tools. They can't be inspected. A company submits an AI-assisted app under a proprietary license, and nobody can prove anything. The policy punishes transparency. If you're honest about using AI tools, you're out. If you hide it, you're fine.
The community noticed. On Tildes, one commenter put it directly: "Banning one-shot vibecoded apps from submitters who don't understand them is one thing, but banning anything that looks like it *might* have used AI in some part of the process is efficient, and generally correct for Flathub. It's also terrible for developers."
Reddit's r/flatpak has developer after developer describing the chilling effect. One shared that they were flagged for using Claude Code to *submit the pull request*, not to write the app. Another had their submission rejected because a moderator thought the README "looked AI-written."
## The alternatives exist
Flathub isn't the only Flatpak repository. You can add any remote that hosts a valid repo. Here's what's emerged since the ban.
### FlatPark: the AI-native hub
Website: [flatpark.org](https://flatpark.org/?ref=grigio.org) | GitHub: [github.com/flatpark/flatpark](https://github.com/flatpark/flatpark?ref=grigio.org)
FlatPark is the most interesting option because it didn't just accept AI-assisted apps. It was designed around them from the start. Onboarding, review, publishing, upgrading, and cleanup are all meant to be driven by AI agents.
FlatPark hosts extra-data apps only. It downloads official Linux releases (.deb, .rpm, .tar.gz) and repackages them. It never builds the app from source. The app binary is always the vendor's own. This keeps the security model clean while letting you install anything from one place.
Vibe-coded apps are welcome "under clear rules enforced by AI review that weighs development history and app quality." There's an explicit de-listing process if something turns out to be garbage.
They even built a discovery pipeline that actively crawls Flathub's `AI Slop`-labelled rejected PRs to find real apps that got caught in the crossfire.
```
flatpak --user remote-add --if-not-exists flatpark https://dl.flatpark.org/flatpark.flatpakrepo
flatpak --user install flatpark
```
### FlatFree: no moral policing
GitHub: [github.com/spivanatalie64/FlatFree](https://github.com/spivanatalie64/FlatFree?ref=grigio.org)
FlatFree's pitch is simple and direct:
We accept AI-assisted submissions. We do not police how code is written. If it builds, if it's free software, it belongs here.
Their philosophy: "Any tool used by a human is human work. AI assistance, Stack Overflow, linters, code generators, compilers, they are all tools." No review board. No moral policing. Just free software.
Submissions are open via pull request. You add a directory with your app ID and a flatpak-builder manifest.
### FriendlyHub: safety first, style second
Website: [friendlyhub.org](https://friendlyhub.org/?ref=grigio.org) | GitHub: [github.com/friendlyhub/friendlyhub](https://github.com/friendlyhub/friendlyhub?ref=grigio.org)
FriendlyHub takes a different angle. Their reviews focus on safety, accuracy, and whether the app works. They don't reject you for icon quality, toolkit choice, or coding style.
They have automated CI/CD builds for x86_64 and aarch64, and a web UI for submissions. The whole stack is open source.
### The usual suspects
Fedora has its own Flatpak repository for Fedora-specific apps. KDE has one too, though there's active discussion about reactivating it as a first-party backup to Flathub. Various vendor repos exist for proprietary software. You can always `flatpak remote-add` any of them.
## What to do if your app got rejected
Don't panic. Your app isn't dead. Flatpak is a format, not a store. The whole point of `flatpak remote-add` is that there's no single chokepoint.
Pick your alternative. FlatPark if you want the most polished experience and AI-native tooling. FlatFree if you want zero bureaucracy. FriendlyHub if you want automated builds and a web UI. There's nothing stopping you from listing on multiple repos.
Keep your Flathub manifest. The policy says it's not retroactive. Apps already published stay published. And someday the policy might change. Don't throw away your packaging work.
Document your process. If you used AI tools, say so in your README, in your `AGENTS.md`, in your repo description. The repos that welcome you will appreciate the transparency.
Consider the direct route. For niche tools, a raw Flatpak repo on your own server or GitHub Pages might be more effective than any hub. You host the repo, users add it with one command, and you control the entire pipeline.
## The bigger picture
Flathub's ban is a symptom of a larger tension in open source. The community is splitting between people who see AI as a tool to be used and people who see it as a contamination to be quarantined.
Both sides have points. Low-quality AI-generated submissions are a real problem. Flathub's reviewers were drowning in them. But blanket bans that treat a junior developer using Copilot the same as a bot spamming LLM-generated slop push serious developers away.
The Tildes discussion nailed it: "This creates a need for an unrestricted, community-run FlatHub alternative with less restrictions. Which probably won't be good for anybody." Or maybe it will. FlatPark, FlatFree, and FriendlyHub are all trying to prove that you can have quality without gatekeeping.
The Linux desktop has always been about choice. Flathub made theirs. Now developers are making theirs.