The Fedora Project Leader is willfully ignorant about Flathub

Today I woke up to a link of an interview from the current Fedora Project Leader, Matthew Miller. Brodie who conducted the interview mentioned that Miller was the one that reached out to him. The background of this video was the currently ongoing issue regarding OBS, Bottles and the Fedora project, which Niccolò made an excellent video explaining and summarizing the situation. You can also find the article over at thelibre.news. “Impressive” as this story is, it’s for another time.

What I want to talk in this post, is the outrageous, smearing and straight up slanderous statements about Flathub that the Fedora Project Leader made during the interview..

I am not directly involved with the Flathub project (A lot of my friends are), however I am a maintainer of the GNOME Flatpak Runtime, and a contributor to the Freedesktop-sdk and ElementaryOS Runtimes. I also maintain applications that get published on Flathub directly. So you can say I am someone invested in the project and that has put a lot of time into it. It was extremely frustrating to hear what would only qualify as reddit-level completely made up arguments with no base in reality coming directly from Matthew Miller.

Below is a transcript, slightly edited for brevity, of all the times Flathub and Flatpak was mentioned. You can refer to the original video as well as there were many more interesting things Miller talked about.

It starts off with an introduction and some history and around the 10-minute mark, the conversation starts to involve Flathub.

Miller: [..] long way of saying I think for something like OBS we’re not really providing anything by packaging that. Miller: I think there is an overall place for the Fedora Flatpaks, because Flathub part of the reason its so popular (there’s a double edged sword), (its) because the rules are fairly lax about what can go into Flathub and the idea is we want to make it as easy for developers to get their things to users, but there is not really much of a review

This is not the main reason why Flathub is popular, its a lot more involved and interesting in practice. I will go into this in a separate post hopefully soon.

Claiming that Flathub does not have any review process or inclusion policies is straight up wrong and incredibly damaging. It’s the kind of thing we’ve heard ad nauseam from Flathub haters, but never from a person in charge of one of the most popular distributions and that should have really really known better.

You can find the Requirements in the Flathub documentation if you spend 30 seconds to google for them, along with the submission guidelines for developers. If those documents qualify as a wild west and free for all, I can’t possibly take you seriously.

I haven’t maintained a linux distribution package myself so I won’t go to comparisons between Flathub and other distros, however you can find people, with red hats even, that do so and talked about it. Of course this is one off examples and social bias from my part. But it proves how laughable of a claim is that things are not reviewed. Additionally, the most popular story I hear from developers is how Flathub requirements are often stricter and sometimes cause annoyances.

Screenshot of the post from this link: https://social.vivaldi.net/@sesivany/114030210735848325

Additionally, Flathub has been the driving force behind encouraging applications to update their metadata, completely reworking the User Experience and handling off permissions and made them prominent to the user. (To the point where even network access is marked as potentially-unsafe).

Miller: [..] the thing that says verified just says that it’s verified from the developer themselves.

No, verified does not mean that the developer signed off into it. Let’s take another 30 seconds to look into the Flathub documentation page about exactly this.

A verified app on Flathub is one whose developer has confirmed their ownership of the app ID […]. This usually also may mean that either the app is maintained directly by the developer or a party authorized or approved by them.

It still went through the review process and all the rest of requirements and policies apply. The verified program is basically a badge to tell users this is a supported application by the upstream developers, rather than the free for all that exists currently where you may or may not get an application released from years ago depending on how stable your distribution is.

Sidenote, did you know that 1483/3003 applications on Flathub are verified as of the writing of this post? As opposed to maybe a dozen of them at best in the distributions. You can check for yourself

Miller: .. and it doesn’t necessarily verify that it was build with good practices, maybe it was built in a coffee shop on some laptop or whatever which could be infected with malware or whatever could happen

Again if Miller had done the bare minimum effort, he would have come across the Requirements page which describes exactly how an Application in Flathub is built, instead of further spreading made up takes about the infrastructure. I can’t stress enough how damaging it has been throughout the years to claim that “Flathub may be potential Malware”. Why it’s malware? Because I don’t like its vibes and I just assume so..

I am sure If I did the same about Fedora in a very very public medium with thousand of listeners I would probably end up with a Layers letter from Redhat.

Now Applications in Flathub are all built without a network access, in Flathub’s build servers, using flatpak-builder and Flatpak Manifests which are a declarative format, which means all the sources required to build the application are known, validated/checksumed, the build is reproducible to the extend possible, you can easily inspect the resulting binaries and the manifest itself used to build the application ends up in /app/manifest.json which you can also inspect with the following command and use it to rebuild the application yourself exactly like how it’s done in Flathub.

$ flatpak run --command=cat org.gnome.TextEditor /app/manifest.json
{
  "id" : "org.gnome.TextEditor",
  "runtime" : "org.gnome.Platform",
  "runtime-version" : "47",
  "runtime-commit" : "d93ca42ee0c4ca3a84836e3ba7d34d8aba062cfaeb7d8488afbf7841c9d2646b",
  "sdk" : "org.gnome.Sdk",
  "sdk-commit" : "3d5777bdd18dfdb8ed171f5a845291b2c504d03443a5d019cad3a41c6c5d3acd",
  "command" : "gnome-text-editor",
  "modules" : [
    {
...

The exception to this, are proprietary applications naturally, and a handful of applications (under an OSI approved license) where Flathub developers helped the upstream projects integrate a direct publishing workflow into their Deployment pipelines. I am aware of Firefox and OBS as the main examples, both of which publish in Flathub through their Continues Deployment (CI/CD) pipeline the same way they generate their builds for other platforms they support and the code for how it happens is available on their repos.

If you have issues trusting Mozilla’s infrastructure, then how are you trusting Firefox in the first place and good luck auditing gecko to make sure it does not start to ship malware. Surely distribution packagers audit every single change that happens from release to release for each package they maintain and can verify no malicious code ever gets merged. The xz backdoor was very recent, and it was identified by pure chance, none of this prevented it.

Then Miller proceeds to describe the Fedora build infrastructure and afterward we get into the following:

Miller: I will give an example of something I installed in Flathub, I was trying to get some nice gui thing that would show me like my system Hardware stats […] one of them ones I picked seemed to do nothing, and turns out what it was actually doing, there was no graphical application it was just a script, it was running that script in the background and that script uploaded my system stats to a server somewhere.

Firstly we don’t really have many details to be able to identify which application it was, I would be very curious to know. Now speculating on my part, the most popular application matching that description it’s Hardware Probe and it absolutely has a GUI, no matter how minimal. It also asks you before uploading.

Maybe there is a org.upload.MySystem application that I don’t know about, and it ended up doing what was in the description, again I would love to know more and update the post if you could recall!

Miller: No one is checking for things like that and there’s no necessarily even agreement that that was was bad.

Second time! Again with the “There is no review and inclusion process in Flathub” narrative. There absolutely is, and these are the kinds of things that get brought up during it.

Miller: I am not trying to be down on Flathub because I think it is a great resource

Yes, I can see that, however in your ignorance you were something much worse than “Down”. This is pure slander and defamation, coming from the current “Fedora Project Leader”, the “Technically Voice of Fedora” (direct quote from a couple seconds later). All the statements made above are manufactured and inaccurate. Myths that you’d hear from people that never asked, looked or cared about any of these cause the moment you do you its obvious how laughable all these claims are.

Miller: And in a lot of ways Flathub is a competing distribution to Fedora’s packaging of all applications.

Precisely, he is spot on here, and I believe this is what kept Miller willfully ignorant and caused him to happily pick the first anit-flatpak/anti-flathub arguments he came across on reddit and repeat the verbatim without putting any thought into it. I do not believe Miller is malicious on purpose, I do truly believe he means well and does not know better.

However, we can’t ignore the conflict that arises from his current job position as an big influence to why incidents like this happened. Nor the influence and damage this causes when it comes from a person of Matthew Miller’s position.

Moving on:

Miller: One of the other things I wanted to talk about Flatpak, is the security and sandboxing around it. Miller: Like I said the stuff in the Flathub are not really reviewed in detail and it can do a lot of things:

Third time with the no review theme. I was fuming when I first heard this, and I am very very angry about still, If you can’t tell. Not only is this an incredibly damaging lie as covered above, it gets repeated over and over again.

With Flatpak basically the developer defines what the permissions are. So there is a sandbox, but the sandbox is what the person who put it there is, and one can imagine that if you were to put malware in there you might make your sandboxing pretty loose.

Brodie: One of the things you can say is “I want full file system access, and then you can do anything”

No, again it’s stated in the Flathub documentation, permissions are very carefully reviewed and updates get blocked when permissions change until another review has happened.

Miller: Android and Apple have pretty strong leverage against application developers to make applications work in their sandbox

Brodie: the model is the other way around where they request permissions and then the user grants them whereas Flatpak, they get the permission and then you could reject them later

This is partially correct, the first part about leverage will talk about in a bit, but here’s a primer on how permissions work in Flatpak and how it compares to the sandboxing technologies in iOS and Android.

In all of them we have a separation between Static and Dynamic permissions. Static are the ones the application always has access to, for example the network, or the ability to send you notifications. These are always there and are mentioned at install time usually. Dynamic permissions are the ones where the application has to ask the user before being able to access a resource. For example opening a file chooser dialog so the user can upload a file, the application the only gets access to the file the user consented or none. Another example is using the camera on the device and capturing photos/video from it.

Brodie here gets a bit confused and only mentions static permissions. If I had to guess it would be cause we usually refer to the dynamic permissions system in the Flatpak world as “Portals”.

Miller: it didn’t used to be that way and and in fact um Android had much weaker sandboxing like you could know read the whole file system from one app and things like that […] they slowly tightened it and then app developers had to adjust Miller: I think with the Linux ecosystem we don’t really have the way to tighten that kind of thing on app developers … Flatpak actually has that kind of functionality […] with portals […] but there’s no not really a strong incentive for developers to do that because, you know well, first of all of course my software is not going to be bad so why should I you know work on sandboxing it, it’s kind of extra work and I I don’t know I don’t know how to solve that. I would like to get to the utopian world where we have that same security for applications and it would be nice to be able to install things from completely untrusted places and know that they can’t do anything to harm your system and that’s not the case with it right now

As with any technology and adoption, we don’t get to perfection from day 1. Static permissions are necessary to provide a migration path for existing applications and until you have developed the appropriate and much more complex dynamic permissions mechanisms that are needed. For example up until iOS 18 it wasn’t possible to give applications access to a subset of your contacts list. Think of it like having to give access your entire filesystem instead of the specific files you want. Similarly partial-only access to your photos library arrived couple years ago in IOS and Android.

In an ideal world all permissions are dynamic, but this takes time and resources and adaptation for the needs of applications and the platform as development progresses.

Now about the leverage part.

I do agree that “the Linux ecosystem” as a whole does not have any leverage on applications developers. This is cause Miller is looking at the wrong place for it. There is no Linux ecosystem but rather Platforms developers target.

GNOME and KDE, as they distribute all their applications on Flathub absolutely have leverage. Similarly Flathub itself has leverage by changing the publishing requirements and inclusion guidelines. Which I kept being told they don’t exist.. Every other application that wants to publish also has to adhere by the rules on Flathub. ElementaryOS and their Appcenter has leverage on developers. Canonical does have the same pull as well with the Snapstore. Fedora on the other hand doesn’t have any leverage cause the Fedora Flatpak repository is irrelevant, broken and nobody wants to use it.

[..] The xz backdoor gets brought up when discussing dependencies and how software gets composed together.

Miller: we try to keep all of those things up to date and make sure everything is patched across the dist even when it’s even when it’s difficult. I think that really is one of the best ways to keep your system secure and because the sandboxing isn’t very strong that can really be a problem, you know like the XZ thing that happened before. If XZ is just one place it’s not that hard of an update but if you’ve got a 100 Flatpaks from different places […] and no consistency to it it’s pretty hard to manage that

I am not going to get in depth about this problem domain and the arguments over it. In fact I have been writing another blog post for a while. I hope to publish shortly. Till then I can not recommend high enough Emmanuele’s and Lennart’s blog posts, as well as one of the very early posts from Alex when Flatpak was in early design phase on the shortcomings of the current distribution model.

Now about bundled dependencies. The concept of Runtimes has served us well so far, and we have been doing a pretty decent job providing most of the things applications need but would not want to bundle themselves. This makes the Runtimes a single place for most of the high profile dependencies (curl, openssl, webkitgtk and so on) that you’d frequently update for security vulnerabilities and once it’s done they roll out to everyone without needing to do anything manual to update the applications or even rebuilt them.

Applications only need to bundle their direct dependencies,and as mentioned above, the flatpak manifest includes the exact definition of all of them. They are available to anyone to inspect and there’s tooling that can scan them and hopefully in the future alert us.

If the Docker/OCI model where you end bundling the entire toolchain, runtime, and now you have to maintain it and keep up with updates and rebuild your containers is good enough for all those enterprise distributions, then the Flatpak model which is much more efficient, streamlined and thought out and much much much less maintenance intensive, it is probably fine.

Miller: part of the idea of having a distro was to keep all those things consistent so that it’s easier for everyone, including the developers

As mentioned above, nothing that fundamentally differs from the leverage that Flathub and the Platform Developers have.

Brodie: took us 20 minutes to get to an explanation [..] but the tldr Fedora Flatpak is basically it is built off of the Fedora RPM build system and because that it is more well tested and sort of intended, even if not entirely for the Enterprise, designed in a way as if an Enterprise user was going to use it the idea is this is more well tested and more secure in a lot of cases not every case.
Miller: Yea that’s basically it

This is a question/conclusion that Brodie reaches with after the previous statements and by far the most enraging thing in this interview. This is also an excellent example of the damage Matthew Miller caused today and if I was a Flathub developer I would stop on nothing sort of a public apology from the Fedora project itself. Hell I want this just being an application developer that publishes on it. The interview has been basically shitting on both the Developers of Flathub and the people that choose to publish in it. And if that’s not enough there should be an apology just out of decency. Dear god..

Brodie: how should Fedora handle upstreams that don’t want to be packaged  like the OBS case here where they did not want there to be a package in Fedora Flatpak or another example is obviously bottles which has made a lot of noise about the packaging

Lastly I want to touch on this closing question in light of recent events.

Miller: I think we probably shouldn’t do it. We should respect people’s wishes there. At least when it is an open source project working in good faith there. There maybe some other cases where the software, say theoretically there’s somebody who has commercial interests in some thing and they only want to release it from their thing even though it’s open source. We might want to actually like, well it’s open source we can provide things, we in that case we might end up you having a different name or something but yeah I can imagine situations where it makes sense to have it packaged in Fedora still but in general especially and when it’s a you know friendly successful open source project we should be friendly yeah. The name thing is something people forget history like that’s happened before with Mozilla with Firefox and Debian.

This is an excellent idea! But it gets better:

Miller: so I understand why they strict about that but it was kind of frustrating um you know we in Fedora have basically the same rules if you want to take Fedora Linux and do something out of it, make your own thing out of it, put your own software on whatever, you can do that but we ask you not to call it Fedora if it’s a fedora remix brand you can use in some cases otherwise pick your own name it’s all open source but you know the name is ours. yeah and I the Upstream as well it make totally makes sense.

Brodie: yeah no the name is completely understandable especially if you do have a trademark to already even if you don’t like it’s it’s common courtesy to not name the thing the exact same thing

Miller: yeah I mean and depending on the legalities like you don’t necessarily have to register a trademark to have the trademark kind of protections under things so hopefully lawyers you can stay out of the whole thing because that always makes the situations a lot more complicated, and we can just get along talking like human beings who care about making good software and getting it to users.

And I completely agree with all of these, all of it. But let’s break it down a bit because no matter how nice the words and intentions it hasn’t been working out this way with the Fedora community so far.

First, Miller agrees the Fedora project should be respecting of application developer’s wishes to not have their application distributed by fedora but rather it be a renamed version if Fedora wishes to keep distributing it.

However, every single time a developer has asked for this, they have been ridiculed, laughed at and straight up bullied by Fedora packagers and the rest of the Fedora community. It has been a similar response from other distribution projects and companies as well, it’s not just Fedora. You can look at Bottle’s story for the most recent example. It is very nice to hear Miller’s intentions but means nothing in practice.

Then Miller proceeds to assure us why he understand that naming and branding is such a big deal to those projects (unlike the rest of the Fedora community again). He further informs us how Fedora has the exact same policies and asks from people that want to fork Fedora. Which makes the treatment that every single application developer has received when asking about the same exact thing ever more outrageous.

What I didn’t know is that in certain cases you don’t even need to have a trademark yet to be covered by some of the protections, depending on jurisdiction and all.

And last we come into lawyers. Neither Fedora nor application developers would want it to ever come to this, and it was stated multiple times by Bottles developers that they don’t want to have to file for a trademark so they can be taken seriously. Similarly, OBS developers said how resorting to legal action would be the last thing they would want to do and would rather have the issue resolved before that. But it took until OBS, a project of a high enough profile, with the resources required to acquire a trademark and to threaten legal action before the Fedora Leadership cared to treat application developers like human beings and get the Fedora packagers and community members to comply. (Something which they had stated multiple times they simply couldn’t do).

I hate all of this. Fedora and all the other distributions need to do better. They all claim to care about their users but happily keep shipping broken and miss configured software to them over the upstream version, just cause it’s what aligns with their current interests. In this case is the promotion of Fedora tooling and Fedora Flatpaks over the application in Flathub they have no control over. In previous incidents it was about branding applications like the rest of the system even though it was making them unusable. And I can find you and list you with a bunch of examples from other distributions just as easily.

They don’t care about their users, they care about their bottom line first and foremost. Any civil attempts at fixing issues get ignored and laughed at, up until there is a threat of a legal action or a big enough PR damage, drama and shitshow that they can’t ignore it anymore and have to backtrack on them.

This is my two angry cents. Overall I am not exactly sure how Matthew Miller managed in a rushed and desperate attempt at damage control for the OBS drama, to not only to make it worse, but to piss off the entire Flathub community at the same time. But what’s done is done, let’s see what we can do to address the issues that have festered and persisted for years now.

16 thoughts on “The Fedora Project Leader is willfully ignorant about Flathub”

  1. Excellent post!

    > They all claim to care about their users but happily keep shipping broken and miss configured software to them over the upstream version, just cause it’s what aligns with their current interests.

    This is the root of the issue. Distributions aren’t incentivized to solve user problems, they’re incentivized to have you use their package managers because that’s what distros are “supposed to do”.

    Ultimately I think it’s about numbers, 96% will always be larger than 4%, we can still build great OSes using flathub for the masses and not worry about what distros do.

  2. Thanks for sharing! I hope some publicity will help educate the Fedora folks about the harm they are causing.

    However, I think the point about permissions is not entirely wrong. There is a concerningly large number of flathubs that are effectively not sandboxed or at least not very much. Or maybe I am just having bad luck, but I had to manually adjust the permissions for many of the flathubs I installed to ensure they were actually sandboxed.
    https://flathub.org/apps/org.signal.Signal: “full file system read/write access” (so it can read my crypto keys and change ~/.bashrc and do tons of other things — this is effectively not sandboxed)
    https://flathub.org/apps/com.vscodium.codium: “full file system read/write access”
    – For some time, com.vscodium.codium gave d-bus access to org.freedesktop.Flatpak, which allows a sandbox escape (and I am not even sure if the web UI will show that, but it might; GNOME software does show it)
    https://flathub.org/apps/io.github.ungoogled_software.ungoogled_chromium: full access to “Desktop” folder — not remotely as bad as full system (or full $HOME), but still not great

    In fact, *every single one* of the flatpaks I have installed from flathub is marked as “potentially unsafe” on flathub. That does not inspire confidence in the state of sandboxing for flathub.

    To be clear, Matthew missed the mark by miles here. But there is a core truth at least to his point about permissions.

    1. – Signal is probably due to an electron regression, as the portal filepicker doesn’t work right now, depending on the used electron version.

      – from memory, the website shows that, also I think that’s now guarded against with a liter rule – but some apps have been grandfathered in e.g. https://github.com/flathub-infra/flatpak-builder-lint/blob/2e5cf72efb7317421bf633686967bcbf3e68e920/flatpak_builder_lint/staticfiles/exceptions.json#L1799

      – I’m not even sure, what the desktop folder is for, as mine is empty. we’re going from a sandbox free world into a sandboxed one, if we want apps to work at all, we need these inbetweens and keep on pushing.

  3. As a long-time Fedora user I feel emberrassed to read the FPLs questionable take on Flathub packages. I think the FPL should do some introspection, read the Flathub docs (especially the requirements and guidelines) and publicly apologise where appropriate.

    Recently the possibility of AI _tooling_ in a future Fedora release was mentioned and immediately wrongfully interpreted as AI being forced on Fedora users (which is not true but Internet does as it does). To my surprise this was not addressed by the FPL. IMHO this erroneous perception of forced AI is damaging to Fedora and I would expect the FPL to be on top of things to address this. But all we got were crickets.

    This is not a good look. As a member of the Fedora Community I expect more from the FPL. Let’s hope the new FPL does better.

  4. I understand the historical reasons for why Distros existed and why software was packaged up the way it was. Dependency hell was real, and Distros were the only way that you could keep some sort of semblance of order, while still doing dynamic linking of libraries. We didn’t have enough disk space to be able to statically link everything.

    Obviously when Go got released, and it statically linked everything, certain groups of people went ballistic at how big the binaries got, but the rest of the world seemed to have just shrugged their shoulders and counted on hard drives getting bigger and filesystems doing dedup behind the scenes. Same thing with containers. You would try as best you could to have common layers for your images but it was never perfect enough for some detractors. Regardless most of the world saw the benefit and it became dominant.

    I think that we are in the same situation here, and the problem is that the people packaging software for Distros see this as people taking away their job, rather than seeing it as the job not really being required anymore and freeing them to do something else.

  5. “However, every single time a developer has asked for this, they have been ridiculed, laughed at and straight up bullied by Fedora packagers and the rest of the Fedora community. It has been a similar response from other distribution projects and companies as well, it’s not just Fedora. You can look at Bottle’s story for the most recent example. It is very nice to hear Miller’s intentions but means nothing in practice.”

    I have to pick some bones with this. I keep seeing the claim that this ‘kind of thing’ is happening a lot, yet when you ask for details, the only case that keeps coming up seems to be Bottles. And to me, that one differs in some important ways.

    First, it’s not just about flatpaks. Upstream provides Bottles (only) as a flatpak. A Fedora packager maintains it downstream (only) as an RPM. There’s no Fedora flatpak of bottles.

    The Fedora maintainer provides it as an RPM on the – to me, entirely reasonable – basis that some people just don’t like flatpaks. They’re not going to install Bottles as a flatpak. They’ll install it as a package, build it themselves, or not use it at all. For those people, providing it as a distribution package seems reasonable.

    Unlike what initially happened in the current case, the Fedora bottles maintainer has, IMO, bent over backwards to be reasonable. They’ve patched in an explicit click-through disclaimer that this is a downstream package – https://src.fedoraproject.org/rpms/bottles/blob/rawhide/f/1003-Display-warning-regarding-issue-tracker.patch – and patched the bug tracker URL to be Fedora’s – same patch, and also https://src.fedoraproject.org/rpms/bottles/blob/rawhide/f/1002-Change-issue-URL-to-Bugzilla.patch .

    Upstream, however, is entirely adamant they they do not want anyone packaging it at all, to the point of patching in checks upstream that try to make packages not work, which the packager then has to patch out again. Of course, they’re entitled to that opinion, but it seems like a pretty…extreme opinion to me. There are hundreds of thousands of *other* projects which every distribution in the world packages and nobody complains, and this hasn’t destroyed the F/OSS world yet. To be fair, the upstream maintainer hasn’t reached for the trademark button, which they would be within their rights to do, but they’ve done everything *else*, and don’t seem to want to compromise or negotiate with downstream packagers at all, they just want to say NO.

    Aside from that case, what others are there? I think there’s a risk of going too far with the argument that there’s some kind of general upstream vs. downstream war going on. Distributions have packaged software for decades, and mostly it works. The vast majority of upstreams are generally fine with downstream packaging; it’s how their software gets to a lot of their users. Yes, flatpaks and Flathub have a chance to change this in some positive ways, and where there *is* a conflict like this we should resolve it sensibly – I don’t agree with a lot of what Matthew said on the interview, and I personally think we should mostly ditch Fedora flatpaks and go with Flathub. But I just have issues with the narrative that there’s some big conflict going on here across dozens of apps, because AFAICS there really isn’t.

    1. Yes there are plenty of examples of applications developers ending up in this state. There are fewer that have the time and are willing to keep complaining about it. Most of them want to keep making their app instead of endlessly trying to convince people like you. Because no matter how many times its stated, and Fedora having exactly the same policy the application developers ask for, you all keep ignoring and claiming you are the wronged party in all this. The notion that the Fedora packager bentover backwards is a laughable one. The request was not to just change the issue tracker links and add a popup, it was to stop using the Bottles branding completely. Instead you do what YOU dim acceptable, and refuse to listen. On top of that you keep complaining about how reasonable you are and that nobody else is seeing it and that we all should instead be thankful to you for even paying attention! If I create a Fedora Fork with the same branding but different issues url in the SUPPORT_URL= and BUG_REPORT_URL= it would be entirely unacceptable but you all act as if this is enough and we should be happy with the “compromise” the Packager has so gracefully blessed as with.

      Even when Matt himself acknowledges this situation and we went through this whole shitshow with OBS.

      You all demonstrate how the Fedora community refuses to learn or give a shit and how the OBS issue is only “resolved” as long as there is a legal threat. This is is ridiculous and exactly why people want nothing to do with the Fedora packagers and community.

    2. Claiming that the Fedora maintainer bent over backwards to update Bottles’ support links is ludicrous.

      First of all, updating support links when upstream asks for it should just be automatic and instant; if upstream claims that they’re receiving your downstream bug reports, it’s *really* not bending over backwards to accommodate that by redirecting your users to your own issue tracker. Like, seriously you’re updating a URL in a metadata file. Honestly, I’m even surprised that distributions don’t have automations set up to automatically patch the various support URLs in appstream files to point at the downstream bug tracker.

      Even ignoring the fact that updating support URLs isn’t bending over backwards in principle, it’s also just factually incorrect. I mean, it took a Bottles developer burning out, then adding code to exit outside of Flatpaks, before the Fedora maintainer did something and redirected users to the appropriate issue tracker. That’s not bending over backwards, that’s having your hand forced.

      And finally: the absolute kicker. The Bottles developers _still_ got support requests in their Discord, asking how to get rid of Fedora’s patched “Go open bug reports on Bugzilla” dialog! This isn’t shocking. The fact is people open Google and look up where to report issues, and they look up the app name. Which means that essentially _no matter what_ a downstream will do short of rebranding the app or dropping the package, upstream will still have to deal with some people asking for support for downstream packages.

      This situation is not in any way fundamentally different from OBS. OBS drew a slightly different line: they’re OK with dealing with the issue load that the RPM packages cause for them (some triage to check if the bug is easily reproducible elsewhere, then a redirect to the downstream bug tracker). Bottles decided they’re not OK with even that. Where that line is drawn doesn’t make the issue any different

  6. I was reading through https://pagure.io/fedora-workstation/issue/463 and what confused (and irritated) me was when fenrirthviti provided a perfectly reasonable decision to postpone updating the KDE runtime in OBS due to bugs which they had reported and were waiting for upstream to address (choosing to provide a stable working app rather than a broken “secure” app) then catanzaro replies with comments like:
    > “…maintainers are sometimes just bad at maintaining their packages, and, well… suffice to say I’m quite surprised we need to debate whether it’s acceptable to use an EOL runtime that no longer receives security updates.”
    > “I won’t mince words: allowing the runtime to go EOL is unacceptable and indicates terrible maintainership.”
    >”Moreover, the fact that Flathub allows the application to remain listed with an EOL runtime indicates insufficient quality control on Flathub’s part.”
    >”I wonder whether Flathub’s OBS Studio is unusually bad, or if this is representative of poor quality control on Flathub in general?”

    I’ll stop there and recommend you read the pagure.io yourself, but these comments got me thinking. Didn’t Fedora just drop python 2 in Fedora 41 (5 years after upstream extended EOL, 10 years after their initial EOL)? How can anyone in Fedora criticize having a slightly out of date dependency when they provided python 2 well past when it received security updates?

    I was also a bit disappointed with Brodie in this interview as he did not push back on Matt’s claims, read some of the comments on the pagure.io and get Matt to respond, or even do some basic background research like looking into Flathub’s packaging requirements.

    1. Michael Catanzaro, isn’t wrong. Sometime maintenance isn’t consistent. After all, it’s a volunteer effort. Nobody is getting paid here. It’s going to lag behind. I’m certainly guilty of this.

      It’s a case by case basis. But ultimately, when an app maintainer tells you, don’t package – you must listen. Even if you’re trying to advocate on the side of the users.

  7. “Any civil attempts at fixing issues get ignored and laughed at, up until there is a threat of a legal action or a big enough PR damage, drama and shitshow that they can’t ignore it anymore and have to backtrack on them.”

    Bingo, trademarks are how you protect yourself as an upstream, no trademark? Then your shit out of luck and I really do mean that.

    What he said about not needing one, its a red herring because ideally OBS wouldn’t have had one so the request wouldn’t have triggered the legal hats and he wouldn’t have had to make a formal response.

    They don’t want you to protect your brand because they know that its not as simple as forking and renaming it, if the fork simply doesn’t work properly compared to upstream then nobody will use it and they can’t damage or benefit from the goodwill that the upstream brand created with users.

    Upstream also have the opportunity to target lots of platforms that downstream are simply uninterested in targeting, this provides opportunities for fundraising and sponsorship which a single downstream doesn’t typically have.

    In other words, its more likely that a project which targets a wider audience is able to accrue more donations etc that it could then reinvest into improving the project.

    The “drama” could be avoided altogether by having clearly written distribution policy around unaltered and modified versions of an upstream project, after you secure the trademark of course.

    Trying to inflict PR damage rarely achieves the results you desire and may actually end up damaging both brands. Proactively communicating expectations is the way to go.

    I was worried about this for some time and tried broaching the topic with wider community in 2021, see – https://discourse.gnome.org/t/trademarks-codenames-and-the-gnome-foundation/7698/4

    It seems four years later things seem to be just as dire as they were back then, not a good place when downstream strips donation links from upstream but thats what happens when you don’t have a trademark, people are free to tell you to f*** yourself and you are free to spend your time putting their fires out.

    Expecting anything else is futile and imho self-destructive. So many people have burned out over this kind of stuff and it doesn’t matter to those responsible.

    Trademarks are the only protection you have from it.
    Its happened before and will happen again.

    1. I’ll preface this with: I am not a lawyer and what I’m saying isn’t legal advice.

      But, as Miller mentioned during the interview: trademarks don’t always have to be registered. In the US, as I understand it, some trademark protections happen automatically whenever you do “interstate commerce”, which, as far as I understand, is very hard to avoid if you’re an open source project. Of course, registering them gives stronger protections, but limited protections do exist.

      Thus, given my understanding of US trademarks (again, as someone who’s not a lawyer), I don’t think that GNOME Circle apps are entirely unprotected if they lack a registered trademark, and they probably would still have a right to demand that a downstream changes the branding of their redistribution.

      1. Regardless of protection or not, the issue here is that Packagers literary don’t give a shit about the developers unless there’s a Legal issue. And on top of that they keep claiming they do and how things could be resolved in a civil way when someone ends up complaining loudly than they “should”. This is unacceptable.

      2. You can’t explicitly register whatever trademark you desire, if you adopt a generic names policy then it weakens you in this regard.

        Just because you haven’t explicitly registered a trademark doesn’t mean that it will automatically be registered on your behalf.

        If you want legal certainty so that your project is in control of defining your software bill of materials and downstream treat you seriously then explicitly trademarking your project is the only way of effectively achieving that.

        Having upstream define it doesn’t mean that downstream don’t have a say, it just means that a downstream can’t act in a hostile manor without consequences, they aren’t entitled to do whatever they want to your brand.
        Your brand is your reputation after all, not theirs.

        If they want to ignore the feedback of upstream and users they are free to rename, fork and deal with the consequences.

        See the Panic® over prompt that Christian encountered. -> https://gitlab.gnome.org/chergert/ptyxis/-/issues/104

        Christian being an all around decent human being did the right thing and renamed his project instead of sticking his foot down and claiming that trademarks are anti-free software when they are not, he even pointed to the generic name portion of the desktop-entry-spec for the person who filed the issue regarding the rename.

        This spec allows you to for e.g the generic name of “web browser” for , Epiphany, Firefox, Brave, Chrome etc

        I’d go a step further and say that the generic name portion of the desktop-entry-spec was superior from another perspective as well, namely that if for e.g GNOME decided to change a default app and the original continues on then there is no reason to rename anything. E.g GNOME Music, Photos etc.

        If a user decides to use something different to the default then they still have the translated strings from desktop-entry-spec to help them organise and potentially orchestrate all their applications in the future.

        If you don’t have a registered trademark then your distribution policy holds no water and a downstream will just create one for you.

        You’ll end up getting frustrated and shouting at a wall which in turn will contribute to damaging your reputation and brand.

        It makes it difficult for your project to ever become financially viable, viable being that the maintainers and contributors aren’t constantly struggling to pay rent and put food on the table.

        There’s always going to be the threat hanging over you that a downstream will decide that they want the donations that users are directing to an upstream, see what Canonical did with banshee back in the day, directing funds away from GNOME and into their pockets.

        Do I think Canonical would do that again, no. I think they learned from that, does that stop anyone else from doing it in the future? No, not without the legal certainty that trademark laws provide.

  8. How do I report flatpaks that don’t meet the supposed requirements? CLion in particular should never have been published in its current state. It cannot build executables that run outside its own container or depend on anything not in the flatpak SDK. It is useless for embedded development. Debugging doesn’t work. And the packaging is incredibly low effort – it just provides a script that downloads the tarball release and unpacks it inside an empty container. On every update.

Leave a Reply

Your email address will not be published. Required fields are marked *