Flathub has drawn one of the clearest lines yet around AI-generated software. New submissions cannot be generated, opened, automated, reviewed, or filled with AI-assisted code, documentation, manifests, metadata, patches, or build scripts. The policy even tells submitters to keep automated Copilot review out of the pull request. Exceptions may exist for mature, well-maintained projects, but the default message is blunt: do not bring the bot-written app store package to the review queue.

The easy take is that this is an anti-AI backlash from a Linux app store. That misses the useful part. Flathub is not trying to govern abstract creativity. It is protecting a distribution system where unpaid or lightly paid reviewers have to decide whether a desktop application is real, legally redistributable, maintainable, buildable, and safe enough to put in front of users. A flood of low-accountability submissions breaks that system before it breaks any compiler.

That matters because app stores are not code showcases. They are trust infrastructure. Flathub packages need app IDs, metadata, manifests, permissions, runtime choices, dependency sources, licenses, icons, screenshots, and build rules that work across the Flatpak ecosystem. The requirements page already reads like a map of maintainer scar tissue: no misleading submissions, no high-risk end-of-life dependencies, no network access during builds, proper licensing, source builds where possible, and careful control over names and trademarks. AI did not create those problems. It just makes it cheaper to generate more of them.

A capable developer using an AI assistant can produce good software. A careless submitter can also produce an app whose code they do not understand, whose dependencies are copy-pasted from somewhere else, whose license chain is muddy, and whose manifest only works because an agent guessed until a local build passed. The second case is the one distribution platforms are now trying to price in. The question is no longer whether AI helped. The question is whether a human can stand behind the result with evidence.

That is why the policy's process language is more interesting than the code language. Flathub is not only rejecting AI-written application content. It is rejecting AI-generated submission machinery: pull requests, manifests, metadata, patches, and build scripts. Those files are the paper trail. They tell reviewers where the software came from, what it depends on, how it builds, what permissions it asks for, and whether the submitter has enough control to maintain it. If that trail is synthetic and unowned, review turns into archaeology.

The better long-term answer is not a permanent ban on AI assistance. It is stronger provenance. App stores and package ecosystems need contribution records that show who reviewed the code, which files were generated or assisted, which dependencies entered the build, which license checks ran, which tests passed, which permissions changed, and why a maintainer believes the package is safe to ship. That is not bureaucracy for its own sake. It is the minimum evidence needed when generation becomes cheap.

There is a useful contrast with how serious engineering teams are already learning to use agents. The productive pattern is not a model dumping code straight into production. It is an agent inside a controlled workflow: create a patch, run tests, explain changes, pass security checks, get human review, record the decision, and leave enough context for the next maintainer. If open software stores want AI-assisted apps without drowning reviewers, they will need the same operating model.

Flathub's strictness is understandable because the review queue is a scarce resource. A small community cannot be asked to absorb every prompt-to-app experiment from the internet. The policy gives reviewers a simple rejection path when a submission looks automated, under-reviewed, legally fuzzy, or low effort. That is a pressure valve, and pressure valves matter in open infrastructure.

But the policy also points to a future product gap. The winning tooling for AI-assisted open source will not merely write code faster. It will produce reviewable artifacts. Imagine a submission bundle that carries generator disclosure, maintainer attestation, dependency lock evidence, reproducible build logs, static analysis results, license scans, permission diffs, and a human-reviewed change summary. That kind of bundle gives platforms a reason to trust the human process around AI instead of trying to divine intent from the finished code.

This is where pro-AI builders should pay attention rather than complain. If AI-generated software is going to become ordinary, the distribution layer has to get more disciplined. Cheap code pushes cost downstream unless the pipeline captures accountability at the source. The answer is not to pretend every AI-assisted app is suspicious forever. The answer is to make good AI-assisted work distinguishable from unreviewed slop.

Flathub's new line may be too broad for the world that is coming. It probably will not be the final policy. But it is an honest signal from maintainers who know exactly where the cost lands. AI can accelerate software creation. To fit inside serious public distribution systems, it also needs a paper trail.

Sources: Flathub application requirements and generative AI policy, Flathub documentation commit 992f57b, GamingOnLinux report on the policy change, Flathub verified apps documentation.