A new F-Droid forum thread argues that Godot’s move from its open-source Asset Library toward a new Asset Store should change how Godot 4 is treated in F-Droid. The claim is narrow but important: the editor may remain open source, while a networked package-discovery and distribution component becomes closed-source infrastructure.
That distinction matters. For users who install tools from F-Droid because they want binaries to correspond to visible source, a closed asset service is not a cosmetic change. It shifts part of the development workflow from auditable code to a hosted service whose behavior must be trusted from the outside.
What the forum post claims#
The F-Droid post says Godot is migrating away from the current Asset Library and toward a new Asset Store planned for Godot 4.7. The existing Asset Library has a public source repository at godotengine/godot-asset-library. The new Asset Store, according to the post, does not have a public source repository and instead has a public issue tracker at godotengine/godot-asset-store-tracker.
The author’s practical request is that F-Droid consider adding the NonFreeNet anti-feature to Godot 4. In F-Droid terms, that label is used when an app promotes or depends on a network service that is not free software. The argument is not that the Godot editor itself has suddenly become proprietary. It is that the asset/package manager path may begin pointing users toward a closed server-side system.
The thread also points to Godot’s roadmap around paid assets. The author argues that paid assets will likely require closed-source payment providers, and that paid marketplaces tend to create incentives for low-quality submissions. That second point is a judgment, not a demonstrated outcome. The first point is plausible but still depends on implementation details that are not established in the forum excerpt.
The sharpest factual point in the post is simpler: the old asset library source is public; the new asset store appears to be tracked through issues, not published as source. If true, that is enough to change the audit story for users who care about free software infrastructure, even before paid assets arrive.
Why this matters to F-Droid users#
F-Droid users often make a stronger claim than “the app is free to download.” They care about whether the build can be traced to source, whether bundled services are free software, and whether the app pushes users into opaque network dependencies.
That is why the proposed NonFreeNet label is the real issue. It would not necessarily say “do not use Godot.” It would warn that part of the experience may rely on non-free network infrastructure. For a game engine, that can be more than a sidebar. Asset discovery, package metadata, submission rules, account systems, ranking, licensing, and payments can shape what developers see and use.
There is also a supply-chain angle. Developers increasingly pull templates, plugins, scripts, and example projects from package ecosystems. If the client is open but the index, ranking, moderation, and delivery service are opaque, the risk does not disappear. It moves. Users can inspect the editor, but not the full path that decides what the editor offers, promotes, or fetches.
This is the same reason some Android users prefer F-Droid builds over APKs attached to GitHub releases. A release attachment can be legitimate, but the trust model is weaker when the binary is not clearly tied to the source and reproducible build process the user can inspect. A closed asset store creates a similar trust gap at the service layer rather than the APK layer.
What not to overclaim#
The forum thread is one post by one participant. It should not be treated as a full investigation or as proof that Godot as a project is “closing source.” The source material does not show exploit risk, malware, a licensing violation, or a confirmed final implementation for Godot 4.7.
It also does not prove that paid assets will necessarily flood the store with low-quality content. Marketplaces often have that failure mode, but moderation, review policy, pricing design, and submission rules matter. The post’s concern is reasonable. It is not evidence by itself.
The same caution applies to payment providers. Paid assets usually involve payment processors, and those systems are commonly closed. But the security and free-software implications depend on where those integrations live, what the editor contacts by default, whether users can disable them, and whether the store protocol can be independently implemented.
The strongest supported concern is not about payments. It is about source availability for the replacement service. If Godot is deprecating an open-source asset library in favor of a closed-source hosted asset store, that deserves scrutiny from free-software distributors.
What to check next#
For users and packagers, the next checks are concrete:
- Whether Godot 4.7 or later contacts the new Asset Store by default.
- Whether the asset browsing feature can be disabled or removed in F-Droid builds.
- Whether the new Asset Store server code is published anywhere, not just its issue tracker.
- Whether the old open-source Asset Library remains usable after deprecation.
- Whether paid assets require accounts, telemetry, payment scripts, or proprietary endpoints inside the editor workflow.
- Whether F-Droid maintainers consider the new integration enough to trigger
NonFreeNet.
For developers who want the strictest free-software workflow, staying on Godot 4.6.x until the store design is clearer is a defensible conservative choice. The forum author goes further and calls 4.6.x the last “good” fully open version. That may prove true for their threat model, but it is too early to treat it as a settled technical fact for every user.
The better short version is this: Godot’s editor can remain open while its asset ecosystem becomes less auditable. That is not the same as a proprietary engine. It is still a meaningful trust-model change.