There's nothing like that, as far as I know. You'd need a designer input and an upstream gnome-software bug to have this addressed. It's already known whether the remote is filtered or not, thus it might be easy to show a special icon or anything like that beside the remote name (both in the Sources combo and in the Software Repositories dialog), to indicate the apps from the repo is limited.

Isn't there supposed to be some UI to clarify this?

We discussed this at various points, but I guess it never happened. :disappointed:

The main thing we likely need is to differentiate the filtered version in the repo settings, as well as from the flatpak command line when you list remotes. It's less needed in the source drop down because the source is actually Flathub.

Could we give the filtered version a different name, like "Fedora Flathub Selection"?

Could we give the filtered version a different name, like "Fedora Flathub Selection"?

That seems like the path of least resistance, if it is possible.

as well as from the flatpak command line when you list remotes.

The default output of the flatpak remotes does differentiate it:

   $ flatpak remotes
   Name    Options
   fedora  system,oci
   flathub system,filtered

extending to titles (which GNOME Software also uses):

$ flatpak remotes --columns=name,title,options
Name    Title           Options
fedora  Fedora Flatpaks system,oci
flathub Flathub         system,filtered

Could we give the filtered version a different name, like "Fedora Flathub Selection"?

That could work as long as the user doesn't install a full Flathub remote over the existing one. In such case the filter is removed (or inherited) in the existing remote, which can invalidate the title.

Due to this I believe something more explicit inside the GNOME Software would be better, because it can react to the remote changes much easily. Whether it would be with a special remote/repo icon, or changed title to $TITLE + " (Filtered)" or anything else doesn't matter that much.

Due to this I believe something more explicit inside the GNOME Software would be better, because it can react to the remote changes much easily. Whether it would be with a special remote/repo icon, or changed title to $TITLE + " (Filtered)" or anything else doesn't matter that much.

OK. Maybe @aday can help come up with a design for how this should look, or ask another designer to do so? (I understand Tobias has done recent work on GNOME Software.)

In the absence of a design, $TITLE + " (Filtered)" sounds like a good enough solution.

I opened an upstream bug for it:
https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1689

it would be good to continue any further discussion there (and eventually close this one, unless somebody is going to take care of the sync between the two issue trackers).

We'll keep this one open until the upstream ticket is fixed just as a reminder, so we don't lose track of it.

I was hit by that bug and I am a little surprised after reading the guidelines around filtering for the flathub repo. I remembered some initial concerns about proprietary software being mixed with free software years ago and so expected guidelines in that vein but the current guidelines have extended far beyond that.

You're actively blocking people from installing freesoftware, that's worse than what Canonical are doing ranking snaps above flatpaks imho, at least they show up.

If the user makes a conscious decision to use flathub then that is their decision to make.

I think that it would be better if you either disabled the regular repo by default and provided a warning when enabling it or didn't include it at all.

Flathub is a registered trademark that was generously provided by a Red Hat employee to the GNOME foundation. So Red Hat and Fedora have a lot to be proud of.
Trademarks exist to protect brands and this filter will do damage to the flathub brand.

It will probably do damage to the Fedora and Red Hat brand as well as more people start to hit issues like this and wonder why the apps they saw on the flathub website don't seem to show up on the flathub remote on gnome-software.

The fedora community already have a flathub repository they can curate, messing around with the flathub one like this just looks incredibly bad.

We think allowing users to install some software from flathub is better than not having anything from flathub available at all, which is the only alternative acceptable to Fedora Legal.

However, the nature of the filtered repo needs to be clear: it should not look like it's the full unfiltered flathub.

I think trademarks should be treated differently and respected tbh, even if it's between friends and there is no legal repercussions. This whole proposal hasn't been thought out. It's surprising that fedora legal gave the go ahead.

A lot of the guidelines listed seem kind of arbitrary, whitelisting apps that you feel best target your intended audience? How is that determined? How is Minecraft better suited than Shortwave or Portfolio.

My first reaction was to double check with flathub directly that everything was working on their end. Are users that experience issues going to have to go between fedora and flathub to try and determine the cause and find resolutions?

Want an app, get it on flathub and then convince fedora to allow it to be distributed from flathub?

At the end of the day, the Fedora community has its own set of guidelines for software shipped from official sources.
Flathub is not an official source, it has its own guidelines for what is accepted.

If users are not happy with the guidelines which the fedora community employ on official sources then they have a third party source which they can use whilst remaining on fedora. How is that a problem for fedora?

This is going to create unnecessary issues.

Maybe there is a different route here, a way of showing a curated list of applications from third party repo's which fedora recommends. The current approach looks like a bait and switch.

@oilipheist The user interface in the GNOME Software repository dialog is certainly not ideal - I apologize for that! But I think you are fundamentally misunderstanding the idea of the filtered repository. The idea is not to block people from accessing all of Flathub, but to provide certain portions of Flathub out of the box without the user having to install the Flathub remote. If the user does install the Flathub remote (following the instructions on flathub.org), the filter is removed and they get everything shipped on Flathub.

I think trademarks should be treated differently and respected tbh, even if it's between friends and there is no legal repercussions. This whole proposal hasn't been thought out. It's surprising that fedora legal gave the go ahead.

Hi, we're not concerned about being sued by the GNOME Foundation.

A lot of the guidelines listed seem kind of arbitrary, whitelisting apps that you feel best target your intended audience? How is that determined? How is Minecraft better suited than Shortwave or Portfolio.

I think we can include anything that is not likely to be legally problematic. In practice, this means (1) no naughty multimedia stuff, and (2) no proprietary software except with permission of the copyright holder. We also need to be sure that new software doesn't appear unexpectedly, to ensure nothing violating these conditions sneaks in.

I'm not sure what the process for deciding what to include or what not to include, but I bet contributions that add more apps would be welcomed. Maybe Owen could expand on this.

My first reaction was to double check with flathub directly that everything was working on their end. Are users that experience issues going to have to go between fedora and flathub to try and determine the cause and find resolutions?

Again, this is just a bug. I'm rather surprised that nobody noticed this was broken until half a year after we released the filtered flathub remote, but whatever. The filtered flathub needs to always be presented as such, so that it's unambiguous that it's not the full flathub and so users will hopefully not be confused. Are any of your concerns not resolved by fixing this?

We've discussed with Flathub the possibility of splitting its content into multiple repos, so problematic content can be segregated from safe content. But Flathub does not want to do that. So if we want to provide users who don't know how to install the full Flathub easy access to as much software from Flathub as we can -- and we do -- the filtered approach is required.

I think we can include anything that is not likely to be legally problematic. In practice, this means (1) no naughty multimedia stuff, and (2) no proprietary software except with permission of the copyright holder. We also need to be sure that new software doesn't appear unexpectedly, to ensure nothing violating these conditions sneaks in.

Maybe a better summary would be: "ensure Fedora does not offer software that is obviously illegal." As long as we're confident we're not violating that rule, we can include it.

What's the story with verified apps, donations and purchases moving forward. Will downstream packaged apps take priority over upstream? How would that impact that infrastructure?

How frequently will the filter be updated?

There have been cases in the past where projects have removed functionality from applications to discourage distributors from removing other critical functionality and shipping to their users in a broken state.

This has lead some developers to prefer shipping on flathub as they avoid bug reports on their trackers from software which has been configured incorrectly and distributed to their users despite objections.

It's not a problem for fedora to have policies around how apps are distributed on its official repos but this policy with flathub is overreach.

I'm unsure as to why legal teams working for companies like Valve deem it acceptable to endorse flathub as is while fedora feel the need to add these filters.

To say that its disappointing is an understatement.

Hi, we're not concerned about being sued by the GNOME Foundation.

I know you aren't, what I am saying is that trademarks exist for a reason though. Mozilla knows that, Google know that, Fedora and Red Hat know that. This flathub filter != flathub. Issues that this flathub filter create will negatively affect its brand. Thats not cool.

I think we can include anything that is not likely to be legally problematic. In practice, this means (1) no naughty multimedia stuff, and (2) no proprietary software except with permission of the copyright holder. We also need to be sure that new software doesn't appear unexpectedly, to ensure nothing violating these conditions sneaks in.

I'm not sure what the process for deciding what to include or what not to include, but I bet contributions that add more apps would be welcomed. Maybe Owen could expand on this.

That is not what the guidelines describe though.

Guidelines

We initially want to keep the set of included applications small. We will concentrate on including:
The most popular applications on Flathub

Applications of interest to Fedora's developer target audience

Applications that fill a role not satisfied by any available application for Fedora.

Once a Flathub Flatpak is included, it should only be excluded if there are urgent reasons to do so. The reason for this, is that users that have installed that Flatpak will have a leftover Flatpak with no update stream.

Applications that have equivalent Fedora Flatpaks should, generally speaking, not be included. But an application shouldn't be removed if a Fedora Flatpak is subsequently created (see above.)

Some Flatpaks on Flatpaks are wrappers that download the actual program via the Flatpak extra-data mechanism. If the program is coming from an established, well-known commercial entity, you can assume they have obtained all necessary patent and other licenses.

Open source code hosted on Flathub needs to be checked that it doesn't contain:
Codecs and other potentially patent-encumbered technology that aren't shipped in Fedora.

Other Forbidden Items
As a non-lawyer, you should not be doing extra new research to check for patent problems. Some appropriate checks:

If the application is shipped in RPM form in Fedora, does Fedora do anything special to strip it down?

If the application is not shipped in Fedora, does it contain multimedia codecs? Are there any that are not shipped in Fedora?

Keep notes in Comments non-speculative. Something like: "Contains h264, not currently shipped with Fedora" is appropriate.

OK, I forgot we had more guidelines on what we should or should not include.

Maybe a better summary would be: "ensure Fedora does not offer software that is obviously illegal." As long as we're confident we're not violating that rule, we can include it.

These are the rules regarding what we must not include. I can assure you that Flathub contains a lot of stuff that violates this rule.

What's the story with verified apps, donations and purchases moving forward. Will downstream packaged apps take priority over upstream? How would that impact that infrastructure?

We don't plan to include apps in the filter if they are already packaged in Fedora. The goal is to include stuff that is not available from Fedora. We don't intend to alter how GNOME Software displays donation links. I'm not aware of any plans to offer purchases.

How frequently will the filter be updated?

I think that depends on how often contributions are received. :)

There have been cases in the past where projects have removed functionality from applications to discourage distributors from removing other critical functionality and shipping to their users in a broken state.

This has lead some developers to prefer shipping on flathub as they avoid bug reports on their trackers from software which has been configured incorrectly and distributed to their users despite objections.

We're not altering software from flathub.

It's not a problem for fedora to have policies around how apps are distributed on its official repos but this policy with flathub is overreach.

Then we cannot include anything from Flathub at all.

I'm unsure as to why legal teams working for companies like Valve deem it acceptable to endorse flathub as is while fedora feel the need to add these filters.

To say that its disappointing is an understatement.

We would need Flathub to remove stuff that is obviously problematic. Rest assured there is a lot of very obviously problematic stuff on Flathub, and pointing Fedora users to it exceeds the level of risk that we are willing to accept. Valve can decide for itself what level of risk it is willing to tolerate.

We've discussed with Flathub the possibility of splitting its content into multiple repos, so problematic content can be segregated from safe content. But Flathub does not want to do that. So if we want to provide users who don't know how to install the full Flathub easy access to as much software from Flathub as we can -- and we do -- the filtered approach is required.

They made the right choice because if they had done the extra work and created a separate repo and followed all the guidelines you wanted then there would still be a filtered flathub repo as applications would be excluded if they had equivalent fedora packages available.

We don't plan to include apps in the filter if they are already packaged in Fedora. The goal is to include stuff that is not available from Fedora. We don't intend to alter how GNOME Software displays donation links. I'm not aware of any plans to offer purchases

https://discourse.flathub.org/t/situation-report-new-flathub-website-work-app-verifications-logins-etc/2259

We would need Flathub to remove stuff that is obviously problematic. Rest assured there is a lot of very obviously problematic stuff on Flathub, and pointing Fedora users to it exceeds the level of risk that we are willing to accept. Valve can decide for itself what level of risk it is willing to tolerate.

If it exceeds the level of risk you are willing to tolerate and if the guidlines are essentially the same as software users can already get from fedora maintained repositories then users would be better served by simply removing the filtered repository.

That would remove the unnecessary confusion, delays and issues that it will inevitably create for flathub.

Is there something stopping people from using fedora's flatpak repository elsewhere? Could be advertised as a more legally compliant version of flathub.

They made the right choice because if they had done the extra work and created a separate repo and followed all the guidelines you wanted then there would still be a filtered flathub repo as applications would be excluded if they had equivalent fedora packages available.

Hm, well perhaps we could get rid of the filter in that case. GNOME Software will prefer Fedora sources vs. Flathub anyway. Doesn't really matter since this is all hypothetical anyway.

If it exceeds the level of risk you are willing to tolerate and if the guidlines are essentially the same as software users can already get from fedora maintained repositories then users would be better served by simply removing the filtered repository.

The difference is that Fedora repos do not include proprietary software. But including proprietary software via third-party repos (like Flathub) is allowed.

That would remove the unnecessary confusion, delays and issues that it will inevitably create for flathub.

All we need to do is fix the bug so that it's clear that the filtered Flathub is not the same as the real Flathub.

Is there something stopping people from using fedora's flatpak repository elsewhere? Could be advertised as a more legally compliant version of flathub.

Feel free to use it in other distros, but Fedora's flatpaks are not intended to compete with Flathub.

GNOME Software will prefer Fedora sources vs. Flathub anyway.

There is an option for it (which source should be preferred, when there are more choices for an app). The gnome-software.spec doesn't set it. I can add it, to prefer rpm over flatpak.

There is an option for it (which source should be preferred, when there are more choices for an app). The gnome-software.spec doesn't set it. I can add it, to prefer rpm over flatpak.

See ->

Applications of interest to Fedora's developer target audience

Applications that fill a role not satisfied by any available application for Fedora.

Applications that have equivalent Fedora Flatpaks should, generally speaking, not be included. But an application shouldn't be removed if a Fedora Flatpak is subsequently created (see above.)

I don't have an issue with software preferring an rpm or flatpak packaged by fedora over one produced by flathub(there are benefits and drawbacks to each and I understand the appeal of having a distro packaged version) but that's not what the guidelines describe, the guidelines are about not whitelisting applications packaged on flathub if there is an equivalent flatpak produced by the fedora community.

Maybe I am misunderstanding here but doesn't this mean that the user won't be given a choice at all. Thats different from setting a source or package format as preferred and allowing the user to select a non-preferred source.

This is why I said it would have been a waste of time for flathub to implement the fedora communities recommendations, the guideline isn't hypothetical, it's right there in black and white.
Flathub's repo would have been sliced and diced regardless.

Thats why I originally stated that I was surprised reading the guidelines as I remembered the original issue was about the mix of proprietary and patent encumbered software.

I'm finding it difficult to understand the value proposition of this, if your users were asking to have access to the flathub repo the next step would be to try and figure out why.

If you don't have an answer to that then how can you gauge whether you are satisfying their underlying issues.

If you do have an answer and its regarding your policies for the fedora repo then the filtered repo isn't going to address the underlying issues.

Maybe a better summary would be: "ensure Fedora does not offer software that is obviously illegal." As long as we're confident we're not violating that rule, we can include it.

As an aside it would be great if the messaging around patents/laws was cleared up. I don't live in the US and so as far as I am aware allot of the policies which fedora enforces around US patents/law don't actually apply to me.

I'm not breaking the law by downloading and installing freesoftware and the messaging around all of this has been far too murky over the years. I don't want to have my rights affected in the future if e.g the US decides to pass a regressive bill like EARN IT as I'm not a US Citizen.

Im sure the mirror's which Red Hat operate for China are vetted by the legal team to ensure regional compliance and so maybe it would be a good idea to implement similar mirrors with similar regional compliance checks for other regions.

It may be necessary to isolate regions on an infrastructural level anyway (which affects both flathub and fedora), maybe its time for the policies to be reviewed in order to give greater legal clarity based on the region in which the user is based.

There is an option for it (which source should be preferred, when there are more choices for an app). The gnome-software.spec doesn't set it. I can add it, to prefer rpm over flatpak.

Milan, the WG wants flatpaks to be preferred over RPMs. Please don't change that.

I don't have an issue with software preferring an rpm or flatpak packaged by fedora over one produced by flathub(there are benefits and drawbacks to each and I understand the appeal of having a distro packaged version) but that's not what the guidelines describe, the guidelines are about not whitelisting applications packaged on flathub if there is an equivalent flatpak produced by the fedora community.

Maybe I am misunderstanding here but doesn't this mean that the user won't be given a choice at all. Thats different from setting a source or package format as preferred and allowing the user to select a non-preferred source.

This is why I said it would have been a waste of time for flathub to implement the fedora communities recommendations, the guideline isn't hypothetical, it's right there in black and white.
Flathub's repo would have been sliced and diced regardless.

Again, these guidelines exist only because the filter is required for our legal protection. We'd love to be able to remove the filter. Keeping the filter around just to be able to filter out flatpaks that are already built by Fedora would not be worthwhile. But this entire line of discussion is kind of pointless, because it's based on a hypothetical that is unlikely to happen.

Thats why I originally stated that I was surprised reading the guidelines as I remembered the original issue was about the mix of proprietary and patent encumbered software.

I'm finding it difficult to understand the value proposition of this, if your users were asking to have access to the flathub repo the next step would be to try and figure out why.

If you don't have an answer to that then how can you gauge whether you are satisfying their underlying issues.

If you do have an answer and its regarding your policies for the fedora repo then the filtered repo isn't going to address the underlying issues.

Our users want to install software offered from Flathub that would not otherwise be available in Fedora. The filter is the ONLY way to accomplish this goal. If more software from Flathub is desired, you can simply add it to the filter.

As an aside it would be great if the messaging around patents/laws was cleared up. I don't live in the US and so as far as I am aware allot of the policies which fedora enforces around US patents/law don't actually apply to me.

This really doesn't matter.

I'm not breaking the law by downloading and installing freesoftware and the messaging around all of this has been far too murky over the years. I don't want to have my rights affected in the future if e.g the US decides to pass a regressive bill like EARN IT as I'm not a US Citizen.

Im sure the mirror's which Red Hat operate for China are vetted by the legal team to ensure regional compliance and so maybe it would be a good idea to implement similar mirrors with similar regional compliance checks for other regions.

It may be necessary to isolate regions on an infrastructural level anyway (which affects both flathub and fedora), maybe its time for the policies to be reviewed in order to give greater legal clarity based on the region in which the user is based.

We are not going to be involved in distributing unlicensed multimedia codecs anywhere in the world. Instead, we are focused on making Fedora work well for users everywhere and bringing as many codecs to Fedora as possible, as aggressively as we can.

At this point, I think we're starting to get far afield from the original issue, which is just to make sure the remote is properly labeled. I'm going to suggest that we focus further conversation here on resolving the issue https://gitlab.gnome.org/GNOME/gnome-software/-/issues/1689

Duplicating my comment from the gnome-software issue:

So, this is closer to working than it might seem:

• When we create the repository, the .flatpakrepo has Title=Fedora Flathub Selection
• If someone follows the directions from https://flatpak.org/setup/Fedora and clicks on the repository file to install it, that will do all of:
• Remove the filter
• Change the title to "Flathub"
• Cause fedora-third-party to no longer "claim" it, so it appears in the main section of Flatpak repositories in the GNOME Software dialog

The main problem we have is that when fedora-third-party runs:

flatpak remote-add flathub --from /usr/lib/fedora-third-party/conf.d/fedora-flathub.flatpakrepo

that downloads the metadata from the remote and overrides the title, so it gets added as "Flathub". I can basically fix this in fedora-third-party by making it parse the title out of the flatpakrepo and run:

flatpak remote-add flathub --from /usr/lib/fedora-third-party/conf.d/fedora-flathub.flatpakrepo --title="Fedora Flathub Selection"

Since the title on the command line will take precedence over the downloaded metadata.

The above problem is not something we knew about.

There's a second problem that did know about and wanted to fix for Fedora 36, but forgot: if the user follows the other branch of the quick setup instructions and runs (from the command line)

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

That will:

• Remove the filter
• Not change the title to "Flathub"
• Cause fedora-third-party to no longer "claim" it, so it appears in the main section of Flatpak repositories in the GNOME Software dialog

This would require a fix in the flatpak code base to reset the title when overriding the filter during a --if-not-exists installation.

Created a new flatpak-module-utils build that should fix this for new installs, can't do anything about existing installs:

https://bodhi.fedoraproject.org/updates/FEDORA-2022-f2efc42252

I filed:

https://github.com/flatpak/flatpak/issues/4831

about the 'flatpak remote-add' case. (Another thing that can be done in the short term is to update the quick setup docs on flathub for Fedora.)

Thank you Owen!

Update: https://pagure.io/fedora-workstation/issue/300