I’d like to propose enabling Flathub by default in Fedora, with a filter in place that respects Fedora’s free/libre software policies.
I fully understand and support Fedora’s commitment to software freedom. The idea here isn’t to introduce proprietary software into the experience by default — but rather to leverage existing tools to offer a better user experience while staying within Fedora’s values.
Here’s what I’m suggesting:
Enable Flathub by default,
Filter out non-free/proprietary apps by default using GNOME Software’s existing license filtering capabilities,
And keep the current behavior where users can enable full Flathub (including proprietary apps) via a toggle during installation — just like it works today.
GNOME Software already supports filtering apps by license tags (e.g. metadata_license, SPDX identifiers), and Flathub apps already include this metadata. This means we could show only verified free/libre software to users by default, keeping Fedora’s principles intact.
This approach improves app availability out of the box — especially for newcomers — while still giving full control to those who want to expand beyond Fedora’s freedom guidelines.
Let me know what you think — I’d love to hear the community’s thoughts!
Is there any method to filter out Flatpaks that are not built at source?
Not certain if it’s still a major thing but remember a few years ago a lot of Flathub apps there just repackaged .debs or pre-compiled binaries.
My feeling at the moment is to say keep disabled by default. Not like it’s extremely difficult to enable and I know that Workstation & KDE both prompt for it to be enabled in the as part of the post-install setup.
Flathub exposes “niche” apps with a small user base that doesn’t warrant distro packaging.
Many new users are unlikely to enable flathub, or even know what it is. Then they struggle to find a niche app they need but isn’t in a Fedora repo. There is also the opportunity for Fedora users to experiment with Flathub apps. This that work well may be candidates for removal from Fedora repos which allows packagers to focus on apps where flatpak/flathub version have limitations.
Maybe when the LSB was somewhat useful! There was a .deb to .rpm tool that allowed me to use some Debian packages when we need something newer than was available from our RHEL version.
I’d say it’s not such a big difference between Flathub being enabled by default (as suggested here), and the way the user is currently being presented at initial setup stage with the option to enable third-party repos (which, in turn, would enable Flathub remote as well).
It’s true that many users don’t realize when they’re installing Flatpaks from fedora and when from flathub remote, when using GNOME Software for example.
There was this really long discussion about deprioritizing Fedora Flatpaks in favor of Flathub Flatpaks in Fedora Workstation, in which you @linuxkernel94, have actively participated, IIRC. If, following some of the ideas from that topic, the number Fedora Flatpaks will be significantly reduced, then enabling Flathub by default might become mandatory. I am not sure though, if a decision has been made.
On the atomic side of things, there is this change request in the baking regarding filtering Fedora Flatpaks, I am curious if it will make it into a proposal.
But even if the difference seems small, enabling Flathub by default has a real impact, especially for new or less technical users. A few key reasons why I think it matters:
Many users skip or misunderstand the third-party toggle during setup. Default access to Flathub means fewer barriers to just installing the apps they need.
Flatpaks are being reduced on Fedora’s side, so Flathub becomes the essential fallback — not just a convenience anymore.
On Atomic, it’s critical. Flatpaks are the main way to install apps there — without Flathub, you’re left with a pretty empty system unless you know how to manually add remotes.
So yeah, to me this is less about a policy tweak and more about making sure Fedora stays usable and competitive — especially as Atomic grows.
I would support this proposal if and only if open source software that is not built from source is also filtered out. That’s currently unfortunately common on Flathub. Fedora users deserve better, and excuses are not acceptable.
How exactly would a user verify that a given flatpak from any flatpak repo is (re)buildable from source? Even fedora’s flatpaks?
I’m sure some of this is my inexperience with flatpaks compared to rpms in general. But I have questions about how a user is expected to find and make use of corresponding source associated with flatpaks, even the ones produced by Fedora.
I take the commitment to provide user corresponding source very seriously. It seems to me there’s room for improvement in the tooling around flatpak around this point.
But because Fedora has a policy of building flatpaks from rpms, Fedora should be able to make coherent headway on this if we find there is a need to enhance the tooling around corresponding sources. Because we’ve started from a packaging ecosystem that treats this as important, and we are not doing adhoc “compose containers however you want” we should be able to reinforce project policy that demands corresponding source with tooling that users can use to verify that we are following our own policy.
As it stands, when you enable Flathub / 3rd Party Repos in setup, it gives access to the full Flathub repo, including proprietary software.
Suppose the default behavior is changed to be a filtered Flathub list. Would there still be a setup option that would enable the full Flathub library? ie Default is Flathub “open source”, with an option for third party/full Flathub. Second, would enabling the full repository later require going to Flathub’s website and following their steps for enabling their repo, as I believe it does now?
There is still the question of patents and liabilities that arise from them. IIRC, that was the main reason for not enabling Flathub by default, and I have no knowledge of a recent substantial legislative change that would have changed the status quo.
While possible, I think it’s not realistic to expect the users in general to go to the Flathub located Flatpak app’s manifest file used to build the Flatpaks and inspect the links to the source code. For GNOME Calendar, taken as an example, I can find this json file indicating locations of the source code, but this is as far as I would go investigating.
Users rather put their trust in Fedora, and in Flathub to some extent, when using Flatpaks fom Flathub. So my question is if Fedora can reassure users regarding Flathub safety, or if they could/should trust Flathub directly. This is an excerpt from a Flathub blog post about that ecosystem’s safety approach:
Once an app has been approved and passes initial tests, it is built using the open source and publicly-available flatpak-builder utility from the approved public manifest, on Flathub’s infrastructure, and without network access. Sources for the app are validated against the documented checksums, and the build fails if they do not match.
For further auditability, we specify the git commit of the manifest repo used for the build in the Flatpak build subject. The build itself is signed by Flathub’s key, and Flatpak/OSTree verify these signatures when installing and updating apps.
We mirror the exact sources each app is built against in case the original source goes down or there is some other issue, and anyone can build the Flatpak back from those mirrored sources to reproduce or audit the build. The manifest used to build the app is hosted on Flathub’s GitHub org, plus distributed to every user in the app’s sandbox at /app/manifest.json—both of which can be compared, inspected, and used to rebuild the app exactly as it was built by Flathub.
This gives some reassurance.
I wonder if such apps were still considered open source. Because if they would be marked as proprietary by Flathub, then this should be no issue, since the user is provided with the information that no source code is available. Those could even be filtered out by default, and given an opt-in option.
Citation needed. This is a commonly repeated argument without actual proofs or statistics. if there are so many, it should be easy to make a list of those.
Each Flatpak (at least the Flathub ones, I don’t know about that for the Fedora ones) come with the manifest that has been used to build it /app/manifest.json, with all the dependencies and all the commands, so you should always be able reproduce them.
I understand the way how Fedora provides their own Flatpaks, created from the sources the distributor uses for general RPM packaging. Silverblue should be a product that behaves as close as possible like Fedora Workstation.
IMHO, the current situation is not ideal from an end-user perspective.
When I turn Flathub off, my software selection is quite limited. Some applications I use are not available in the Fedora repository, but on Flathub. This also includes free software. But in case of an issue, I know that I can centrally use the Fedora support channels to get that issue fixed.
When I turn Flathub on, I have to decide for every single software installation, if a Flathub or a Fedora flatpak should be used. As an average user, I’m not able to make the right decision here. It feels like flipping a coin. Which repository provides the latest or “better” package for me? Which of the repositories receives updates to which time? Does the Fedora package contain bugs, the developer’s package does not have? Or vice versa? Who do I have to contact in case of an error?
I like the idea of having a choice. But with a good default value, as an user I don’t have to think about that and it reduces complexity to me.
An ideal solution would look something like that to me in gnome-software.
The Fedora repository is turned on by default.
Flathub is enabled. It only shows FLOSS & Verified software subsets and also hides packages already provided by Fedora.
You have to enable full featured Flathub manually. Once enabled, you can select between Fedora or Flathub packages.
Can somebody provide documentation why Fedora decided to create their own repository in the first place? Would be an interesting read for me.
Larger communities mean apps get “tested” on a wider range of hardware, use cases, and linux distros, so unless there are version differences or bug reports, I prefer flathub. If the flathub version of an app works well, maybe Fedora can drop the flatpak and redirect effort elsewhere, so there can be benefits from trying flathub first and switching to the Fedora flatpak if there are issues.
If the versions differ, I generally choose the repository with the latest version after checking upstream for issues. I assume some Fedora flatpaks may have Fedora-specific changes due to newer kernels or when a library the app uses has been replaced by something newer.
I also wonder why there are repositories for nightly branches of both, KDE and GNOME software, but no generic stable repositories for both environments. I think a shared repository that can be used by Aeon, Silverblue, VanillaOS, Endless OS, etc. would help reducing redundant packaging.
Legality: Fedora has strict requirements when it comes to legal stuff. They do not ship patented software, unlike Flathub.
Ideology: Fedora only ships FOSS software. And since everything is built from source on Fedora infrastructure, there’s less likely be some overlooked binary being included.
Security: Fedora has complete control over Fedora Flatpaks. All apps and dependencies come from the rpms in Fedora’s repos. If there’s a security vulnerability, the Fedora Flatpak will automatically have the fix once the flatpak is rebuilt. In contrast, Flathub gives control to the app’s publisher to handle updates. They may not update vendored dependencies in a timely fashion and may use end of life runtimes. Flathub currently does not have a policy to remove apps or hide apps that use end of life runtimes.
reproduce is an interesting word. That’s an interesting change from the word I use…rebuild.
Yes its clear that flathub flatpaks can be.. reproduced. But that’s not what I’m talking about.
I’m talking about build from corresponding sources, which is a specific way, but not the only way to reproduce the final output.
For example the brave flathub manifest merely pulls the binary zip release from git with a checksum check. Not actually doing the build even though its foss. In this respect flathub policy is treating brave, even though the source is available, exactly the same as if it were a proprietary binary.
Whether or not corresponding source is used in the reproduction of a flatpak is a distinct policy difference between the fedora as a distributor and flathub as a distributor of foss code.
Fedora as policy verifies that the corresponding source code builds by actually using the source code for the foss code it distributes. Flathub does not. And I have concerns about a distribution policy that doesn’t make use of the corresponding source when its available to build its consumable outputs. I think failing to make use of corresponding source actually weakens the foss ecosystem. I also think it undercuts what flathub is trying to do with its verified tagging. If the source hasn’t been used to build the thing, what exactly hve you verified?
But because Fedora does require making use of corresponding source in the rpm context, Fedora has subsequently built tools around making it reasonable easy for users to use the corresponding source provided in the rpm context. With that history in mind I’m hopeful that Fedora’s approach to flatpaks will strengthen over time with tooling so flatpak users can make use of the corresponding source in the fedora flatpak context with similar (but different) ease.
It’s an unfortunate change of wording that I did not do intentionally. You can rebuild the Flatpak like Flathub did it. Whether or not it’s fully built from source is indeed dependent on how the build is described in the manifest, and that’s a per app question.
There is a general policy for Flathub submissions that apps should be built from source as much as possible: Requirements | Flathub Documentation. The difference is that Flathub allows exceptions.
Apps can be verified on Flathub; this process confirms that an app is published by the original developer or an authorized party by proving ownership of the app ID. While all apps are held to the same high standards of safety and review on Flathub, this extra layer helps users confirm that the app they are getting is also provided or authorized by its developer.
The above comparisons (built from source) would make more sense IMO to be limited to such Flatpaks which are also provided by Fedora (Brave is not shipped by Fedora). There will always be packages that Fedora cannot ship for legal reasons, but Flathub will.
Besides, Flathub is also needed because there are lots of FLOSS apps that are not shipped by Fedora, including GNOME Circle apps such as Errands, Newsflash, etc.