Welcome to LWN.net

The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net!

Many distributions provide support out of the proverbial box for Flatpak packages, but Fedora is unusual in that it also provides, and defaults, to its own repository of Fedora-built Flatpaks. This has been a source of confusion for Fedora users, who expect to get the Flatpak built by the original developers and hosted on Flathub. It has also been a source of conflict with upstream projects, because users complain of bugs in Flatpak packages they are not responsible for. The situation has also frustrated some Fedora developers, who would prefer to offer put Flathub’s offerings first. A new complaint that Fedora has apparently used manifests from Flathub to build the packages for Fedora—without giving credit to the original authors—has spurred discussions about Fedora’s Flatpaks once again. While no concrete changes are on the table, yet, there may be some movement toward addressing persistent complaints.

Any developer or project can provide a repository with their software in Flatpak format; however, Flathub is the de facto hosting service for Flatpaks these days. Projects that publish Flatpaks expect users to get them from Flathub, and users looking for software would generally expect to get the Flathub version of a Flatpak.

However, Fedora provides its own repository and runtime for Flatpaks, and the Workstation edition ships GNOME Software configured to install Fedora Flatpaks by default—rather than Fedora’s RPMs or Flathub Flatpaks—when they are available. LWN covered Fedora’s Flatpak offerings and priorities in February, following a disagreement with the Open Broadcaster Software (OBS) Studio project about problems with Fedora’s OBS packages.

The complaint

Every application on Flathub has a link to its manifest file: a JSON or YAML file with information on building its Flatpak. For example, the Foliate e-book reader’s Flathub page links to its manifest repository on GitHub.

Fedora’s most recent discussion around Flatpaks began with an accusation from Hari Rana on November 3, which claimed that Fedora is acting as a “hostile ‘alternative’ to Flathub”:

An indeterminate amount of their packages are, in fact, directly based on existing manifests from Flathub. Not by manually inspecting code themselves; rather, by running a script that goes through Flathub’s APIs and parses the respective apps’ manifest to generate manifests for Fedora Flatpaks: [link]

All this, without crediting the original authors.

Flathub and Fedora use different tools to build Flatpaks, and publish them using different formats: currently, Flathub uses the OSTree format, while Fedora has switched to the Open Container Initiative (OCI) image format to ship its Flatpaks. Using the OCI format allows Fedora to host its Flatpaks along with its other container images, and means Fedora does not have to host a separate Flatpak repository. It also means that Fedora can use container tooling to build its Flatpaks. The tools for building Fedora Flatpaks do not use the manifest file; they use a container.yaml file to provide the recipe for building a container to be used for the Flatpak.

The Fedora Flatpak packaging tutorial explains that the flatpak-module tool searches Flathub for an application that matches a search term. If found, it uses that application’s manifest to initialize the configuration file used by Fedora’s tools. However, in doing so, it does not provide any attribution or mention of the original manifest.

The manifest file format does not contain author or licensing metadata for itself. In the case of Foliate, for example, the manifest JSON file is in its own repository under the Flathub organization. There is no license associated with the repository, and there are nine contributors to the file throughout its history. Skimming the other manifests in Flathub repositories, I have not found any that contain a license for the manifest or provide clear attribution for the manifest. Fedora’s tooling could, however, simply provide a link back to the manifest that is used to generate the container.yaml file.

It is worth noting that there is a school of thought that such build instructions are not subject to copyright at all. However, many distributions—including Fedora—do assign a license to package build configuration files. LWN covered the topic of licensing control files in November 2024, when Arch Linux announced it would assign a license to its PKGBUILD files.

Discussion

The post was shared on Fedora’s Discourse forum on November 4, by “Victoria”. Michael Gruber replied that the responses on social media to Rana’s post were by people who did not understand Fedora or Flatpaks: “But this gives Fedora as a whole bad PR. We need to do and communicate our flatpaks right.” Victoria replied that Fedora should just drop its Flatpaks: “Fedora is the only distro that’s feeling the need to be different.”

That led to a back-and-forth discussion about the desirability of Fedora providing its own Flatpaks. Ashley Thorne said that they were glad that Fedora’s repository exists, if only to provide an alternative:

I don’t think Fedora should compromise on its ideals (security/philosophical) because people pressure them into doing so. At the very least, I would like to see some big security improvements (no EOL runtimes, more rules for vendored dependencies) from Flathub before it becomes “default”. But I have my doubts those improvements will happen. Flathub needs to be easy with little maintenance for proprietary companies to buy-in.

Kyle Gospodnetich, creator and a maintainer of the Fedora-based Bazzite distribution, complained that Fedora’s Flatpaks are “actively damaging flatpak’s reputation among the Linux community and making the out-of-box experience of Fedora as painful as possible”, and later referred to the dispute with the OBS project’s maintainers as an example of a problem with Fedora Flatpaks. He noted that the maintainers of Fedora’s Atomic Desktops had asked “multiple times to be freed from Fedora Flatpak”. Most recently, Timothée Ravier put forward a change proposal for Fedora 43 that would have limited the number of Fedora Flatpaks available on the Atomic editions of Fedora. He listed a number of disadvantages to Fedora’s Flatpaks, including “little maintenance and traction in the community”, no procedure to remove or deprecate Fedora Flatpaks, as well as technical downsides with the OCI format used by Fedora.

In considering the proposal, Fedora Engineering Steering Committee (FESCo) member Stephen Gallagher outlined his perspective on why Fedora needed to offer its own repository. He cited a need to vet any application shipped by Fedora:

As a distributor of software, we have an obligation to our users to validate what we provide in some way. This does not necessarily mean that it has to be built directly by us, but it does mean that at some point Fedora needs to evaluate the delivery pipeline of any application we ship.

He said that there was “definitely room for improvement on both the Fedora side and the Flathub side”, and was optimistic that things could be improved. He voted against the proposal, and FESCo rejected the proposal.

Flathub problems

On November 5, Fedora Project Leader (FPL) Jef Spaleta replied to the thread. He said that he had been specifically unable to talk about Flathub for about three months, “because I found a very significant copyright license violation problem with the flatpak runtimes they host” in July. Spaleta said that if he had wanted “an actively hostile relationship” with Flathub, he could have made noise about the copyright violations. Instead, “I had some quiet conversations” with people who could resolve the problem and gave them time to do so.

The problem Spaleta referred to was announced by Bartłomiej Piotrowski of the Flathub project on October 24. Copyright notices and license files were being omitted when software was being bundled as a Flatpak and distributed via Flathub. He said that the problem was “a genuine oversight”, and that the project had worked with GNOME, KDE, Flatpak developers, and the freedesktop-sdk teams to “make it easier than ever for developers to ensure their applications properly include license and copyright notices”.

Spaleta said that he would love nothing more than to make a case that Fedora could stop providing its own Flatpaks. However, he said that Fedora could not live with the amount of time it takes Flathub to address compliance problems. Fedora has “a higher risk profile than either Flathub or other projects that depend on it”, and taking months to address copyright-compliance issues is not acceptable.

I have to have a way to address the inherent liability associated with license compliance from a distributor point of view for any flatpaks that Fedora pre-installs as part of any composed images.

Aside from license-compliance concerns, he noted that Fedora also needed its own solution because it builds Flatpaks for architectures that Flathub does not support.

Ravier replied that his change proposal for Flatpaks on Atomic desktops specifically addressed those concerns, but was rejected. Spaleta replied that he was aware of that, but the proposal had not addressed other spins and editions that might preinstall other Flatpaks that could cause Fedora liability.

Discussion

Victoria asked if Spaleta would commit to working with Flathub to resolve problems. He replied: “do you think I was looking at the internals of the flatpak runtimes for fun when I found the compliance problem?” He said that he was trying to build a bridge with Flathub to improve the relationship, and it would help if people stopped starting fires.

In that spirit, Gospodnetich asked if Fedora could change the way Flatpak itself is packaged for Fedora. Currently, the package includes a systemd service that enables Fedora’s Flatpak repository. He pointed to a pull request to make the Fedora Flatpaks service an optional package. Spaleta said that he had no power to decide if the pull request would be accepted, but “it seems a reasonable adjustment to me without a lot of risk”.

Spaleta said later that he had discussed the original complaint about uncredited use of Flathub manifests with Rob McQueen of the GNOME Foundation. “Neither of us identify this as something expected to be attributed.” However, if Flathub decides later that it should be documented “we’ll try to figure it out”.

There was a lengthy discussion, and a fair amount of finger pointing and airing of past grievances. The thread was set to “slow mode” which only allowed participants to comment once every two hours. Rana joined the conversation and recounted their previous involvement with Fedora’s Flatpaks and reasons for losing interest in the effort. Spaleta replied to say that he was not around during Rana’s tenure with Fedora, but sympathized with their frustration.

Eventually, Spaleta floated the idea that Fedora’s Flatpak special interest group (SIG) could be organized more like EPEL, which provides extra packages for Red Hat Enterprise Linux (RHEL) and its derivatives like AlmaLinux and Rocky Linux. He also suggested that Ravier’s proposal could be revived and approved for the Fedora 44 release.

Spaleta did not provide a concrete plan but he did say that a proposal to get Fedora’s Flatpak SIG “in a healthier place overall” could show up as a change proposal in the release cycle for Fedora 44 “if we can get it together”. The “if” in that comment is doing a lot of work; depending on the scope of the eventual proposal, the deadline for submission could be as early as December 17.

With luck, Fedora will be able to address some of the persistent complaints from its users, upstream open-source projects, and downstream projects that use Fedora as a base. In particular, ensuring that users are aware of the difference between Fedora and Flathub Flatpaks, and have full control over which repositories and packages are installed, would go a long way toward reducing (if not eliminating) complaints.

---