Flathub and the bundled software policy

[vilmasvensson]

Greetings!

There have been previous discussions regarding the Fedora Flatpak repository and why Flathub cannot be used by default. However, there have been talks to address the inclusion of proprietary software over on GitHub by creating a sort of “Librehub”.

This seems like a great idea, but even if there was a “Librehub”, Fedora couldn’t include it because of the bundled software policy. This policy made sense when it was put in place, but is incompatible with the whole idea of Flatpak.

I think a review of this policy would make sense since Flatpak is one of the cornerstones of Silverblue and Flathub is the place to get them. Fragmenting the Flatpak ecosystem is not a long-term solution.

What are your thoughts on this? I’d love to hear them.

[bcotton (Ben Cotton)]

I don’t see Fedora having its own Flatpak repo to be fragmenting the ecosystem any more than Fedora having its own rpm repo is. It’s not just about FLOSS-versus-proprietary applications, but also trust in the build system, etc. If anything, I’d like to see more Flatpaks in our repo, not fewer.

I do agree that the Bundled Software policy doesn’t make sense for Flatpaks. I think the answer is to make it clear that it applies to RPMs. We may need to define a similar, more relaxed set of rules for building Flatpaks, but I leave that to people who understand the build mechanisms better.

[toMeloos (Tom Verdaat)]

@bcotton

I don’t see Fedora having its own Flatpak repo to be fragmenting the ecosystem any more than Fedora having its own rpm repo is.

RPM’s aren’t quite comparable. These include core system components that aren’t exchangeable between distro’s due to differences between those distro’s. Flatpaks are aimed at GUI user applications, which are distro agnostic. In fact, with a Flatpak future your RPM repo’s should see the removal of GUI application packages and become focussed on those core OS packages and CLI tools.

Why would more fragmentation be better? That fragmentation in both technologies (deb/prm/apk/etc. and now flatpak vs snap) been a massive gripe for vendors, developers to users alike for decades. Flatpak is THE opportunity to consolidate application distribution. Vendors and developers aren’t looking to CI/CD to numerous destinations. They prefer to have one. Users aren’t looking for multiple application stores or sources. They too prefer to have one that contains everything.

@bcotton

It’s not just about FLOSS-versus-proprietary applications, but also trust in the build system, etc.

Hate to say it, but this sounds like FUD rhetoric from Microsoft’s proprietary glory days to me. I’m not even aware of any trust issues. Why not abandon your own repo and throw your weight behind Flathub? That would immediately resolve any reservations one might have, like trust issues with regards to the build system…

@bcotton

If anything, I’d like to see more Flatpaks in our repo, not fewer.

Have you considered that this might not be within your control? Vendors and developers all seem to settle on publishing to Flathub only. That means it’ll be up to Red Hat to add these applications to your own repository. It has 1150 entries already so small chance that you’re going to be able to catch up and keep up if nobody pushes anything and it’s all up to you to pull. Firefox for example is already better from Flathub than from your registry. Not a very economic way to spend Red Hat’s limited and expensive capacity. Especially considering the much more efficient alternative of adopting Flathub and throwing your weight behind it to remove any doubts around the reliability of its build system and add a feature to distinguish between free and non-free entries.

@bcotton

I do agree that the Bundled Software policy doesn’t make sense for Flatpaks. I think the answer is to make it clear that it applies to RPMs. We may need to define a similar, more relaxed set of rules for building Flatpaks

for this!

[otaylor (Owen Taylor)]

The plan that has been approved for quite some time, but not yet implemented is to to include a filtered view of Flathub in the 3rd-party repositories that users can opt-into when they start using Fedora. See: Issue #108: Add selected Flathub apps to the third-party repos - fedora-workstation - Pagure.io - we really hope to have this done for Fedora 35.

Filtered here means that apps would only be included when they passed a light-weight review process to make sure that we aren’t implicitly including something in Fedora that could be a problem legally. Having a filter also means that if a problem was reported, Fedora would be able to remove an application from being distributed to its users without having to block all of Flathub. The review process is being handled through the fedora-flathub-filter repository on Pagure.

I don’t think the bundled software policy is at all relevant to 3rd party repositories - existing 3rd party repositories certainly distribute RPMs that include extensive bundling.

Right now, Fedora Flatpaks are made up of Fedora RPMs, so they just inherit the general packaging policies of Fedora - if we were ever to add direct-to-Flatpak builds from source, then policies for that would have to be worked out from scratch to try to ensure the same level of goals that the current Fedora packaging policies have, without carrying over bits that just aren’t applicable.

[vilmasvensson]

@otaylor

The plan that has been approved for quite some time, but not yet implemented is to to include a filtered view of Flathub in the 3rd-party repositories that users can opt-into when they start using Fedora.

This is great!

@otaylor

I don’t think the bundled software policy is at all relevant to 3rd party repositories - existing 3rd party repositories certainly distribute RPMs that include extensive bundling.

For a third-party repo, no, it’s not relevant. But my hoping was to see a filtered Flathub by default, replacing the Fedora Flatpak repo. One of the main purposes of Flatpak is to be distro-agnostic, having a distro-specific repo is working against that.