|
|
Log in / Subscribe / Register

Fedora discusses Flatpak priorities

By Joe Brockmeier
February 28, 2025

Differences of opinion, as well as outright disputes, between upstream open-source projects and Linux distribution packagers over packaging practices are nothing new. It is rarer, though, for those disputes to boil over to threats of legal action—but a disagreement between the Open Broadcaster Software (OBS) Studio project and Fedora packagers reached that point in mid-February. After escalation to a higher authority, things have been worked out to the satisfaction of the OBS project, but some lingering questions remain. How Fedora should prioritize Flatpak repositories, how to handle conflicts between upstreams and Fedora packagers, and the mechanics of removing or retiring Flatpaks all remain open questions.

Flatpak

Flatpak has been in development for more than a decade, and its earliest origins date back to 2007. Originally it was called xdg-app, and is designed to bundle individual applications and their dependencies into an easy-to-install format that works on any Linux distribution.

It is more than just a packaging format, though. Flatpaks are sandboxed, which means that an application installed as a Flatpak can be limited or restricted entirely from accessing user files, graphics sockets, networking, devices, and so forth. They are also self-contained, so installing an application using a Flatpak won't disrupt other applications and libraries on a user's system. Flatpaks can be distributed as OStree repositories or Open Container Initiative (OCI) images.

Flatpak is meant to provide a number of benefits for projects, Linux distributions, and users over Debian packages, RPMs, and other distribution-specific formats. A project can target a single packaging format and distribute the software with the project's preferred defaults. Users don't have to depend on their distribution to package the application, or for distribution packagers to stay up to date with the most recent releases. The upstream can release major updates at whatever cadence it pleases, for example, and users don't have to wait for the next distribution major release for the upgrade.

Projects can also make use of runtimes that provide libraries and toolchains, such as the GNOME and KDE runtimes, which free developers from having to package all those dependencies or worry about things like "which version of GTK or Qt is available on the user's system?" Linux distributions, and their users, benefit from a wider selection of software without the need for the distribution to package everything under the sun.

Adoption of Flatpak has been on the upswing in the past few years. Some are even pushing for it to be the de facto method for installing software on the Linux desktop. Work on Flathub as a central repository for Flatpaks started in 2017, and it passed the one million active user mark last January. Flatpaks are being prioritized by GNOME as a way for distributing GNOME software, and it is the preferred and most expedient way to install applications on image-based distributions like Fedora's Atomic desktops, Bluefin, Aeon Desktop (based on openSUSE), and others because Flatpaks can be installed in the user's home directory and do not need to be installed system-wide. Fedora has its own Flatpak repository, which contains Flatpaks built from Fedora RPMs and distributed as OCI images. Fedora serves its Flatpak images and Linux container images from the same registry, and provides its own runtimes for applications rather than using the Freedesktop, KDE, or GNOME runtimes.

The complaint

OBS Studio is a popular open-source, multi-platform project for live streaming and screen recording. The project provides its own Flatpak package via Flathub and recommends installing that package prominently on its download page. Fedora enables the Flathub repository in the GNOME Software package-management application, but also provides OBS Studio as an RPM and as a Fedora-packaged Flatpak in the Fedora Flatpak repository. Users searching for OBS Studio using GNOME Software will be offered the Fedora Flatpak as the default, then the Fedora RPM, and finally the OBS Studio official Flatpak from Flathub.

OBS contributor Joel Bethke created a ticket with the Fedora Flatpak special interest group (SIG) on January 21. He complained that the OBS Studio Flatpak from Fedora was "poorly packaged and broken" which, in turn, led users to complain to the upstream project because they thought they were getting the official OBS Flatpak. The initial report did not specify what those issues might be, but later in the thread Angaddeep Singh pointed to a bug filed with OBS Studio that complained about problems using the H.264 encoder, and a complaint in the OBS forum that the Twitch chat and streaming interface were missing. In both cases, users were using Fedora-packaged versions of OBS and complaining upstream about problems that were not present in the OBS builds. Bethke later said that the project had received complaints specifically about the Fedora Flatpak that included regressions due to the Qt version bump, hardware acceleration not working, OpenH264 encoder failures, and even failure to launch the application at all. He said that the OBS Project's Flatpaks, and "in some cases, even the RPM" did not have the same issues. The reason Bethke requested that the Flatpak either be removed, or that the Fedora Flatpak be clearly identified as a third-party package, is that users were not even aware they were using Fedora's instead of the OBS project's. He also wanted an explanation why Fedora would publish its package at a higher priority than OBS's official builds.

In response, Michael Catanzaro proposed in a ticket for the Fedora Workstation's working group that Fedora deprioritize or remove Fedora Flatpaks from GNOME Software. He made the case that Fedora Flatpaks have been "a significant source of quality problems and have frankly been generally unsuccessful". Users want Flatpaks created by upstreams, but are confused by the way they are displayed in GNOME Software. He recommended that the priority be changed to display software from Flathub first, then Fedora Flatpaks, and finally Fedora RPMs.

On February 4, Catanzaro posted an update to his ticket with notes from the Workstation working group's meeting (minutes). He said that the working group had not reached any final conclusions, but had consensus on a few points. One was that Fedora Flatpaks "are generally the worst software source for users to install", so they should not have the highest priority in GNOME Software. He also acknowledged that there are problems with the user interface for GNOME Software, because it was easy for users to be confused about the source for software. However, he had some critical words for the OBS Studio project's packaging: he preferred the RPM version to the OBS Flatpak because OBS version "notably depends on an EOL runtime that no longer receives security updates".

Currently OBS Studio's Flatpak depends version 6.6 of the KDE/Qt runtime, which reached end-of-life when the 6.8 runtime was made available in October 2024. The KDE project only maintains branches with the two most recent versions of Qt (currently 6.7 and 6.8), as well as long-term-support branches for Qt 5.15. This means that a 6.x version of the runtime has a shelf life of about a year. According to the list of vulnerabilities for Qt, there seem to be a few vulnerabilities that would impact the 6.6 runtime, but it's unclear if any would present a real security problem for users of OBS Studio. Bethke replied that OBS Studio had well-documented reasons for not updating the KDE runtime due to regressions in Qt. "We made the choice to have a functional application, report the bugs upstream, and update the dependency once they have been fixed." He also said that the project had the impression that the concerns of OBS Studio as an upstream were being dismissed.

I have said this before, but I will say again it should not be upstream's responsibility to track and report on downstream packaging issues, and the fact that we have and it's been ignored has been frustrating. I still don't have a good understanding on why Fedora is so adamant about repackaging and redistributing Flatpaks wholesale without proper testing or validation.

He also pointed out that Yaakov Selkowitz, who owned the obs-studio Flatpak package for Fedora, was maintaining hundreds of packages. "In what world is a single person able to maintain, test, and support, that many packages and applications?" The Fedora Flatpak initiative, he said, seemed poorly planned, badly implemented, and largely unsustainable.

Catanzaro agreed with several points that Bethke made, but ultimately said, on February 12, that allowing a runtime to reach end of life "is unacceptable and indicates terrible maintainership". That seemed to be the proverbial straw that broke the camel's back, and prompted Bethke to issue a formal request that Fedora remove any OBS Studio branding from the distribution and threatened legal action if Fedora failed to comply.

Resolution

On February 14 Fedora Project Leader (FPL) Matthew Miller stepped in to deescalate the situation, which brought Bethke back to the table to talk. Bethke said that, as an outsider, it was difficult to navigate Fedora's processes and groups when he didn't even know what some of the acronyms stood for or which groups to engage with.

I was asked to report things to several different locations by, supposedly, representatives of Fedora.

It was a frustrating process to even know who I should be talking to about these issues, and when the people who were talking to us decided to dismiss the issue and insult us instead, we were left with what we felt was no choice but to take action. We are always open to discussion as long as it is in good faith, and still are.

Fedora contributor Adam Williamson summarized the situation and sympathized with Bethke. He also noted that the request to assert OBS Studio's rights and remove the OBS Flatpak was being handled as a high-priority request. Unfortunately, he said, there was no current process for removing a Flatpak from Fedora. Indeed, based on the discussion in the ticket for Fedora release engineering there was confusion about whether it was actually possible to remove a Flatpak image from the index, and how to notify users of such an event. Following a meeting with the Flatpak SIG and Miller, Bethke withdrew the request to remove or rebrand the OBS Studio Flatpak on February 18, which reduced the urgency to find a solution. Bethke suggested that the ticket be used to track the technical issues with the Fedora Flatpak, and asked that Fedora make it clearer for upstream projects to report bugs.

Even though the OBS situation seems to be resolved, Fedora is left with a number of things to work through with regard to Flatpak. The first and most obvious, of course, is creating a policy and method for removing Flatpaks from its repository. It is somewhat surprising that the project rolled out a method of distributing packages without a plan to address the inevitable need to quickly remove a package from the repository when needed.

Priority

The next open question to tackle is the priority order for RPMs and various flavors of Flatpak in GNOME Software. When Fedora initially accepted the "unfiltered Flathub" proposal for Fedora 38, the Fedora Engineering Steering Council (FESCo) rejected the idea of prioritizing Flathub software over Fedora sources. (LWN covered this in 2022.) It's possible that attitudes have changed in the past couple of years, particularly given Flathub's increasing popularity and some of its newer practices for allowing projects to verify Flatpaks as being provided directly by the project. As Williamson suggested in the OBS Studio ticket, it may be time to rethink the role of distribution-specific Flatpaks:

The story we should be reading from all the comments on this from folks who find it inherently surprising that Fedora would offer its own flatpaks over ones from flathub is that flathub is successful: for a lot of people who buy into the flatpak/snap/appimage-style approach, flathub is their primary trusted source for flatpaks and it's where they assume their flatpaks will come from 'by default', especially if they've clicked through a "turn on third-party repos" dialog. And there are genuine reasons for this - in general the flatpaks from flathub work, people like that they can recommend them to others regardless of distribution and expect a consistent experience, and people like the involvement of upstream developers in many flathub flatpaks.

However, Catanzaro's effort to give Flathub packages top priority does not seem to be finding much success. On February 18, he said that the Workstation working group had discussed the topic for a third time, and it had still not reached consensus. "I'm no longer confident that the Working Group will make any changes here." He also said that he planned to continue arguing to remove the Fedora Flatpak repository—which would make Fedora RPMs the top priority, followed by Flathub if it is enabled. But, he was beginning to fear that the working group would not accept his proposal. On February 25, he wrote that the group had discussed it yet again, and he thought that the group was evenly split on what to do. A possible option would be a proposal that Fedora Flatpaks would need to be owned by the package's RPM maintainer, which would result in "a drastically reduced set of Flatpaks".

Finally, it seems clear that there is work to be done to make it easier for upstream projects to engage with Fedora when they have questions or concerns about how their work is packaged. Justin Wheeler said that he had been working with the Fedora Council on an "explicit statement on our 'upstream first' policy" and had added some language to specifically address collaboration and clear lines of communication. However, that does not provide any concrete changes that would help upstreams navigate and resolve their problems with Fedora.

There is also the question of whether Fedora should honor requests from an upstream not to package software at all. Jordan Petridis wrote about an interview that Miller did recently where he discussed the OBS issue and an older kerfuffle about packaging the Bottles project. Petridis took issue with several of Miller's comments about Flathub's review processes, and complained that Fedora does not live up to its own standards around naming and branding that Miller discusses.

In the interview Miller talks about Fedora's branding rules and asking that projects do not call their derivatives "Fedora". However, the Bottles project asked Fedora not to package its software, or to call it something else if it was going to package the software. After initially considering the request and planning to drop it in Fedora 38, the packager decided to go ahead and provide Bottles RPMs anyway, since the upstream only provides Flatpak packages. And it is still called Bottles in Fedora, several years later, albeit with a disclaimer that it is not an official package and a link to Fedora's bug tracker rather than upstream's. Petridis said that it was wrong that it had to come to legal threats to get Fedora to "treat application developers like human beings and get the Fedora packagers and community members to comply".

Fedora, and other distributions, might want to consider creating a simple and straightforward process for upstreams to report problems and discuss concerns—one that does not require navigating a twisty maze of SIGs, working groups, and multiple bug or issue trackers. Even then, however, upstreams may not wish to participate in the process at all and would prefer to be left to be the sole distributor of their software. At least under their own brand.

The changes and compromises that go along with distribution packaging are not always compatible with the vision that upstreams have for their software. This is especially true with applications like OBS Studio that make use of specialized hardware and have dependencies on multimedia codecs or other libraries that distributions like Fedora do not ship, or ship in modified form for legal reasons. Distributions should consider when it is appropriate to leave software distribution to an upstream project that is uninterested in—or even hostile to—having distributions provide native packages.

The landscape has changed dramatically since Linux distributions were at the center of the universe for free-software distribution. There is still immense value in the Linux distribution packaging model, but it is not a good fit for all cases. Recognizing that, and accepting it, might improve things (and reduce drama) for everyone involved.


to post comments

Regression links?

Posted Feb 28, 2025 19:18 UTC (Fri) by NightMonkey (subscriber, #23051) [Link] (2 responses)

I looked through https://github.com/obsproject/obs-studio/issues/11478, but can't find links to the noted regressions in newer QT versions. Can someone share the links to those regression tracking issues so I can track their status? Cheers. (I really like using OBS on Gentoo.)

Regression links?

Posted Mar 1, 2025 19:49 UTC (Sat) by nickodell (subscriber, #125165) [Link]

I looked at this, and I found that they usually mention QT issues in a standardized format, which is QTBUG followed by the bug number. So one way of finding those would be to look for open issues with "qtbug" in them. This is a little overbroad, because sometimes they mention QT issues that have been solved, or mention issues that are tangentially related, but it should be a decent starting point. https://github.com/obsproject/obs-studio/issues?q=is%3Ais...

Regression links?

Posted Mar 2, 2025 19:14 UTC (Sun) by mattdm (subscriber, #18) [Link]

I don't have a link to the issue, but as I understand it the problem was with widget sizing, causing some items in the settings to not be visible.

case by case

Posted Mar 1, 2025 0:20 UTC (Sat) by cen (subscriber, #170575) [Link] (1 responses)

It seems to me that any general policy will eventually fail in some edge cases. One would expect that upstream's packages would generally work best but it is entirely possible that some upstreams are terrible at flatpak packaging and provide a worst experience vs some 3rd party packager who knows what they are doing. At the end of the day, you need some QA and manually curated "app" store for best user experience.

case by case

Posted Mar 2, 2025 9:04 UTC (Sun) by LtWorf (subscriber, #124958) [Link]

I have patched skladnik (kde games) to work on touchscreens. The patches have all been accepted upstream, but after several months, and at this moment are not released. So on Debian trixie the game is playable on a phone, but not on anything else at this moment.

I presume most upstreams won't bother with cves, so there's that problem, that might be insignificant or important depending on how exposed that particular software is.

This is not a good trend

Posted Mar 1, 2025 1:39 UTC (Sat) by intelfx (subscriber, #130118) [Link] (65 responses)

It is deeply disturbing that more and more free software projects are using trademarks and legal threats as a means to manipulate and exert control over how others are allowed to package, deliver, and consume said free software.

This is not a good trend

Posted Mar 1, 2025 2:09 UTC (Sat) by roc (subscriber, #30627) [Link] (8 responses)

When third-parties release broken versions of your software under your name, and users blame those problems on you, what else can you do other than assert trademark rights? This is exactly the sort of problem trademarks are designed to prevent.

This is not a good trend

Posted Mar 1, 2025 2:54 UTC (Sat) by bgilbert (subscriber, #4738) [Link] (7 responses)

You can collaborate with them to fix it, understanding that you are a participant in a broader ecosystem you don't have a unilateral right to control.

Historically there's been an understanding that the freedoms of free software must include the freedom to ship broken versions of it. That's necessary in order to also have the freedom to ship improved versions, such as versions with antifeatures removed.

This is not a good trend

Posted Mar 1, 2025 8:56 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (4 responses)

Licenses that require renaming of the software in the event of shipping modified versions have long been considered free software.

This is not a good trend

Posted Mar 2, 2025 2:35 UTC (Sun) by bgilbert (subscriber, #4738) [Link] (3 responses)

The FSF indeed says so, but they also have some reservations about degree of burden, as do some of their license analyses and as you have done in the past (in an extreme case, admittedly). Community norms seem relevant here. Firefox/Iceweasel has caused major pain in the past, and that's just one package. If it became common for upstreams to require renaming patched versions, the burden on distros (and indeed on users trying to find distro packages) could be quite substantial.

This is not a good trend

Posted Mar 2, 2025 12:38 UTC (Sun) by khim (subscriber, #9252) [Link] (2 responses)

> If it became common for upstreams to require renaming patched versions, the burden on distros (and indeed on users trying to find distro packages) could be quite substantial.

And what's wrong with that? If distros insist on playing the middleman then they have to shoulder the support burden.

It's the same story as with with that damn DMA API: either you support something – and then you can impose demands, or you don't support something – and then you don't have any say on how app is supposed to work.

For ages distros were trying to play games where they have been trying to impose their rules on everyone while refusing to do the support work.

Flatpacks and SNAPs gave technical means of solving the issue, but the will to relinquish control is still not there.

Which is sad: the ability to build apps and deliver them to users was so natural, it's, essentially, the basis of a general-purpose OS that it's really hard to even believe that someone may still fight that basic need.

If distros want or need to include some third-party code – that's fine… but there shouldn't be any confusion about who is the support contact… today we have that confusion and it needs to be fixed, one way or another.

This is not a good trend

Posted Mar 2, 2025 13:05 UTC (Sun) by bluca (subscriber, #118303) [Link]

> while refusing to do the support work.

This is abject nonsense, and just shows you haven't the faintest clue about the work distro developers actually do. If you hate Linux distros so much, just switch to Windows - everyone ships their own apps as .exe to download from random websites, I hear it works really great, especially for security

This is not a good trend

Posted Mar 2, 2025 13:34 UTC (Sun) by pizza (subscriber, #46) [Link]

> while refusing to do the support work.

*ahem*

To quote https://github.com/obsproject/obs-studio/blob/master/COPYING --

11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

This is not a good trend

Posted Mar 1, 2025 19:03 UTC (Sat) by Mook (subscriber, #71173) [Link] (1 responses)

Per the article, they tried to; a bug was filed, and was either ignored or just shut down.

See also specific comment describing their experience: https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/...

The issue was that Fedora was shipping broken versions, but making the users think they were getting the upstream version (because it's a Flatpak), so upstream was getting all the bug reports. Historically, when distros ship broken versions (e.g. Debian and keepassxc for a while) at least the users can figure out where the issue lied.

This is not a good trend

Posted Mar 2, 2025 2:54 UTC (Sun) by bgilbert (subscriber, #4738) [Link]

Those problems aren't new to Flatpaks, though. As long as there have been downstreams, users have misunderstood the ecosystem and reported downstream bugs upstream, and downstreams have been uncooperative (sometimes very uncooperative). None of that is good, and it requires finesse, but it doesn't seem like a problem meriting legal threats.

This is not a good trend

Posted Mar 1, 2025 7:22 UTC (Sat) by epa (subscriber, #39769) [Link] (54 responses)

It should be standard practice to strip out the trade marks when packaging software for distribution. After all, if you can’t modify it and distribute your modified version without the threat of a trademark suit, it is not free software.

This is not a good trend

Posted Mar 1, 2025 8:31 UTC (Sat) by cjwatson (subscriber, #7322) [Link] (24 responses)

This is completely unrealistic though. The most salient trademark is likely to be the project name, and most projects refer to themselves all over the place, often in ways that aren't amenable to automatic substitution - translations, screenshots, and so on. Never mind what it would do to interoperability and plain old user confusion if a distribution renamed everything.

This is not a good trend

Posted Mar 1, 2025 9:37 UTC (Sat) by Wol (subscriber, #4433) [Link] (19 responses)

> This is completely unrealistic though. The most salient trademark is likely to be the project name, and most projects refer to themselves all over the place, often in ways that aren't amenable to automatic substitution - translations, screenshots, and so on.

So if I realise a bastardised version of "Watson's Medicinal Compound" that doesn't work, and moreover is harmful to users' computers, you'd be happy to get the blame for it?

A trademark is the user's way of knowing that they are getting the *genuine* *article*. It doesn't matter in the slightest whether you think your version is better or not. It doesn't matter in the slightest whether your version *really* *is* better or not (and that's down to the user, anyway, not you).

The fact is, your version is not the genuine original, and for you to mislead people into thinking it is is called fraud. You HAVE to strip trademarks - that's all there is to it.

(with apologies to Lily :-)

Cheers,
Wol

This is not a good trend

Posted Mar 1, 2025 22:12 UTC (Sat) by dvdeug (subscriber, #10998) [Link] (18 responses)

Which doesn't really respond to cjwatson. If you want people to strip the trademarks, make them easily removable.

> You HAVE to strip trademarks - that's all there is to it.

"Reverse passing off"--the act of stripping the trademarks off and releasing it under your trademarks--can get you sued just like trademark infringement. It's illegal at least in the US and India.

This is not a good trend

Posted Mar 2, 2025 0:23 UTC (Sun) by Wol (subscriber, #4433) [Link] (14 responses)

>Which doesn't really respond to cjwatson. If you want people to strip the trademarks, make them easily removable.

That would be nice, yes, but it's not a requirement. It IS a legal requirement not to mis-use other peoples' trademarks. I understand Red Hat do that, but it's a lot of work - YOU are expecting volunteers to do loads of work for your benefit, not theirs? If you want - or need - it, you have to do it. You can't expect others to do unpaid work for your benefit.

> "Reverse passing off"--the act of stripping the trademarks off and releasing it under your trademarks--can get you sued just like trademark infringement. It's illegal at least in the US and India.

Even if the licence explicitly permits it?

At the end of the day, as I see it, FLOSS people should be respectful of other people. That includes their reputation and livelihood, and as such Intellectual Property extremism, whether maximalist or minimalist, tends to be driven by people standing on their rights to be jerks :-(

We object to Big Business trying to lock everything up behind "intellectual property" so they can rip everybody else off. Why do we have so many people in our own camp who want to abolish intellectual property so that they can rip other people off and destroy their livelihood and reputation?

Because this particular incident is a perfect example of the latter - the project's reputation is being damaged by people who don't appear to care that their actions are benefiting themselves at the expense of the people actually doing the work. That shouldn't be acceptable behaviour in our community.

Cheers,
Wol

This is not a good trend

Posted Mar 2, 2025 2:15 UTC (Sun) by bgilbert (subscriber, #4738) [Link] (1 responses)

> Why do we have so many people in our own camp who want to abolish intellectual property so that they can rip other people off and destroy their livelihood and reputation?

This is free software. No one is being ripped off if someone ships a modified version; it's the whole point of the exercise.

It's good when people can make a livelihood from their work, but sometimes they come to think they're owed one, and that's where the bad behavior often starts. FOSS upstreams are stewards of their projects, not owners, and should not expect to have ultimate say over how the code is deployed or used.

This is not a good trend

Posted Mar 2, 2025 9:08 UTC (Sun) by pabs (subscriber, #43278) [Link]

In todays world there is more at stake than code. In a world of upstream FOSS developers supported by (or solely funded by) donations, stripping the trademarks and redistributing can reduce upstream's income, potentially to the point that they can no longer fund development. They understandably might not like redistributors of any kind as a result.

This is not a good trend

Posted Mar 2, 2025 7:04 UTC (Sun) by dvdeug (subscriber, #10998) [Link] (11 responses)

> YOU are expecting volunteers to do loads of work for your benefit, not theirs?

You want people to not use your trademarks on Free software, make it easy to not use your trademarks.

> It IS a legal requirement not to mis-use other peoples' trademarks. / Even if the licence explicitly permits it?

What does the license and the law actually say? I'm not aware that either statement is clearly true. Do you have a right to distribute Mozilla Firefox under the Mozilla Firefox name? What if you've had to add a minor patch? What if your only changes are around the code? You're still distributing the item that trademark describes.

On the flip side, what license explicitly permits replacing trademarks? The GPL 3 gives options:

Notwithstanding any other provision of this License, for material you
add to a covered work, you may (if authorized by the copyright holders of
that material) supplement the terms of this License with terms:

a) Disclaiming warranty or limiting liability differently from the
terms of sections 15 and 16 of this License; or

b) Requiring preservation of specified reasonable legal notices or
author attributions in that material or in the Appropriate Legal
Notices displayed by works containing it; or

c) Prohibiting misrepresentation of the origin of that material, or
requiring that modified versions of such material be marked in
reasonable ways as different from the original version; or

d) Limiting the use for publicity purposes of names of licensors or
authors of the material; or

e) Declining to grant rights under trademark law for use of some
trade names, trademarks, or service marks; or

f) Requiring indemnification of licensors and authors of that
material by anyone who conveys the material (or modified versions of
it) with contractual assumptions of liability to the recipient, for
any liability that these contractual assumptions directly impose on
those licensors and authors.

Those are options, and b) and c) edge towards demanding people do preserve trademarks.

> Because this particular incident is a perfect example of the latter - the project's reputation is being damaged by people who don't appear to care that their actions are benefiting themselves at the expense of the people actually doing the work.

Or Fedora's packagers are the standard overloaded people trying to handle way too much.

This is not a good trend

Posted Mar 2, 2025 10:20 UTC (Sun) by Wol (subscriber, #4433) [Link] (10 responses)

> > YOU are expecting volunteers to do loads of work for your benefit, not theirs?

> You want people to not use your trademarks on Free software, make it easy to not use your trademarks.

On the flip side, don't abuse other peoples' property, DON'T ABUSE YOUR OWN DOWNSTREAM, don't be a jerk!

> > It IS a legal requirement not to mis-use other peoples' trademarks. / Even if the licence explicitly permits it?

> What does the license and the law actually say? I'm not aware that either statement is clearly true. Do you have a right to distribute Mozilla Firefox under the Mozilla Firefox name? What if you've had to add a minor patch? What if your only changes are around the code? You're still distributing the item that trademark describes.

As I see it, if the licence permits it, then it can't be mis-use, so reverse passing off as you called it can't be mis-use if the licence says that's okay. I've got a WebOS TV which I believe is linux under the hood. So I guess that makes it reverse passing off. And the GPL is PERFECTLY HAPPY with that.

As PJ had a habit of saying, the law is "squishy".

On the strict side, if Firefox is a trademark, then the law is extremely clear - if you get your copy of Firefox from Mozilla, then there is no trademark abuse whatsoever. And yes, people have tried to abuse that and complain that 3rd parties distributing the genuine article are in breach of trademark.

On the flip side of that, how would you like to go to a main dealer, get your brake pads replaced with "Genuine Ford Parts", and then get involved in a possibly fatal crash after maybe only 200 miles because somebody had tricked the supply chain into accepting cheap rip-offs and your brakes failed. It's happened! Which is why trademark abuse is taken very seriously.

It basically boils down to whatever the trademark holder is happy with. Take Linux for example, so long as (a) it's clearly based on an original version of Linux curated by Linus, and so long as it's made clear that an altered version is an altered version (eg I expect my gentoo kernel to have modifications made by the gentoo team), then they're fine with it.

Put differently - don't be a jerk! The trademark is meant to protect the time, effort and money the trademark holder has put into building up a brand. For you to mark your version - and dupe your downstream - into believing what they have is the original, is basically abusing upstream's property. And that's what's happened here.

Fedora received a notice "You are shipping a broken product as if it were the genuine original. Please desist", and they acted like complete jerks. This is very clearly the "Ford Brakes" end of the spectrum. And it could easily end up with upstream shutting down. THAT is why this is serious from the FLOSS point of view. This is quite capable of destroying a project, and all because downstream couldn't care what damage they are causing.

> c) Prohibiting misrepresentation of the origin of that material, or
> requiring that modified versions of such material be marked in
> reasonable ways as different from the original version; or

That clause pretty much describes what a trademark is - a mark that represents the origin of the material. So to leave those marks in your modified version AND NOT ADD YOUR OWN CLEARLY DISTINGUISHING MARKS is clearly, AND EXPLICITLY, a possible licence breach. And the existence of trademarks is clearly invoking that clause and saying it IS a licence breach.

Cheers,
Wol

This is not a good trend

Posted Mar 2, 2025 14:36 UTC (Sun) by PastyAndroid (guest, #168019) [Link] (9 responses)

Perhaps these issues could be solved more easily by distributions taking all bug reports first. E.g, users are always directed to the distributions bug tracker for any software running on the distribution - flatpak or not. Though I thought fedora had this with their crash reporter?

It could be made very clear that they need to do this and the software may have modifications[1]. This would solve the issue of upstream dealing with reports that may not necessarily apply. Thus, not wasting their time/effort.

Perhaps even the software developers themselves could do this, force all distribution users to report to the distribution first while automatically closing new reports that have not done this.

Finally, FOSS applications which have trademark issues (legal threats) can be dropped from distributions to avoid legal issues, ensuring that users only obtain the software from official and authorized sources.

[1] Though, I figured this was common knowledge, a good chunk of software across all distributions has always been modified in some way to make it blend in with the distributions other software, this is standard practice. For example, regardless of distribution you'll rarely get a vanilla kernel (no modifications) or vanilla glibc, vanilla plasma, etc.

This is not a good trend

Posted Mar 2, 2025 19:57 UTC (Sun) by NAR (subscriber, #1313) [Link] (5 responses)

E.g, users are always directed to the distributions bug tracker for any software running on the distribution ... Perhaps even the software developers themselves could do this

Exactly how? And should the software developer really care about the dozen(!) major Linux distributions out there, especially if most if its users are on Mac OS or Windows?

This is not a good trend

Posted Mar 2, 2025 20:30 UTC (Sun) by roc (subscriber, #30627) [Link] (4 responses)

Yes! Upstream working with downstream distros sounds good on paper until you realize how fragmented the distros are, all with different people, processes and tools. It's untenable.

"Just focus on the important distros" people say, but of course no-one agrees on what are the important ones, and of course every distro that one of your users uses is important to them.

For a lot of apps an upstream-provided Flatpak seems like a pretty good solution. Upstreams like OBS should be able to declare that they don't want distro-packaged distribution. Friendly people should honor the requests of people whose work they're benefiting from, even when they don't legally have to. Therefore distros that don't respect such a request should be shamed and required to do the hard work of ripping out the trademarks.

"Upstreams benefit from downstream packager work too" people say, but it's incredibly asymmetric in general.

This is not a good trend

Posted Mar 3, 2025 13:35 UTC (Mon) by PastyAndroid (guest, #168019) [Link] (3 responses)

Again, no.

I said that bug reports could be handled by the distribution first, the user knows which distribution they are using and it is their responsibility to report bugs to the correct place.

Distributions could make this clearer before downloading. E.g, something like "Software included in this distribution is packaged and redistributed by distribution X and may be modified, sometimes this may cause unforeseen issues with the software operation as such if you experience issues we recommend reporting it to our bug tracker <link> first or seeking support from our community at <locations>."[1]

Perhaps even a dialog on first boot could do similar. Thus, the developers in most instances will not have to do anything since the user has already been directed.

As for dealing with it themselves, I did say automated. Perhaps requiring a link to the distributions bug report before accepting a report, for example.

Do note, this mostly only applies to developers who are worried about this kind of thing and how their software is used/distributed.

[1] I'm not a writer or people person, I'm a coder. This will have to be re-written entirely, but you get the point. :-P

This is not a good trend

Posted Mar 3, 2025 13:45 UTC (Mon) by pizza (subscriber, #46) [Link]

> Distributions could make this clearer before downloading. E.g, something like "Software included in this distribution is packaged and redistributed by distribution X and may be modified, sometimes this may cause unforeseen issues with the software operation as such if you experience issues we recommend reporting it to our bug tracker <link> first or seeking support from our community at <locations>."[1]

Distributions can (and do!) do this until they are blue in the face, but end-users will routinely ignore any such notificaitons (even if done on *every* program notificaiton) and go straight for the upstream, nearly every single time.

This is not a good trend

Posted Mar 3, 2025 14:46 UTC (Mon) by NAR (subscriber, #1313) [Link] (1 responses)

This is not how users behave. They see an error message or experience an issue, they search it on Google which will find the original author of the software and not the distribution. Especially if that error message or issue was seen in the Windows or Mac OS versions too. Users don't want to use distributions (or even operating systems for that matter), they want to use a specific set of applications (sometimes with specific versions).

This is not a good trend

Posted Mar 3, 2025 16:23 UTC (Mon) by PastyAndroid (guest, #168019) [Link]

If the issue persists across multiple operating systems and on any configuration, then it is not the fault of the distribution and the distribution should not be held responsible.

The issue we're discussing here is where Fedora compiled the application with different versions of software than the application author did, this caused issues with the software. That is a distribution specific issue and would apply in this case and thus, this belongs as a report for the distribution and not the original authors. Such issues should always be first reported to the distribution, not the authors.

The line can get a little blurry as to who is responsible from a users perspective and so, I suggested reporting all issues to the distribution first as a matter of course, the distribution can help guide the user as to whether it's a distribution specific issue or an upstream issue - perhaps the package maintainer or someone on behalf of the distribution could open the upstream bug report as they are in a much better position to provide the necessary information (think debugging and otherwise).

In any case, authors who do not wish to deal with such potential issues can use flathub or other official distribution methods and avoid their packages being redistributed in a distribution using their trademark rights to refuse it. Thus, any issues are solely on the original authors as they control the whole chain in that case.

Overall the key would be to ensure users are properly guided in how to report their problems, removing any ambiguity or need to question it. The easier you make this for users, the better.

We really do not want to be an 'open community' that sues each other using trademark rights when we are unhappy with something. That doesn't sound very open at all. Instead we should aim to solve the underlying issues as opposed to putting a band-aid on issues or ignoring them.

This is not a good trend

Posted Mar 2, 2025 21:51 UTC (Sun) by Wol (subscriber, #4433) [Link] (2 responses)

> Finally, FOSS applications which have trademark issues (legal threats) can be dropped from distributions to avoid legal issues, ensuring that users only obtain the software from official and authorized sources.

Why? Are you advocating punishing upstream, because downstream is being a jerk? All you need to do is abide by the GPL, take responsbility for your own actions, and then there won't be a problem.

This all boils down to the fact that much of Fedora's downstream doesn't realise that this is a Fedora-modified project, and hence upstream gets blamed for Fedora's blunders. To punish upstream, because Fedora screwed up, is completely unacceptable.

At the end of the day, if YOU screw up, OWN IT. Just try it - you'll be amazed. It'll do your reputation (amongst decent people) no harm whatsoever. And if it WILL harm you, to be blunt, that's society I'd rather avoid, thank you very much ... (and if it's work, I'd be looking to jump ship!).

Cheers,
Wol

This is not a good trend

Posted Mar 3, 2025 13:26 UTC (Mon) by PastyAndroid (guest, #168019) [Link] (1 responses)

Not at all. Ultimately, if you risk being sued for redistributing a piece of software (modified or not), it is unwise to redistribute it - why take the legal risk?

Also, this does not 'punish' upstream in the slightest. It simply gives them control over their project, if they wish to be the sole distributor then they can be by eliminating the middle man and thus protecting their reputation and project, in this way people are not redistributing it in a form they are unhappy with.

Personally, I'm against the concept of FOSS being treated this way, but I can see it is something some FOSS devs need.

This is not a good trend

Posted Mar 3, 2025 17:43 UTC (Mon) by Wol (subscriber, #4433) [Link]

> if they wish to be the sole distributor then

But they don't.

People keep on attributing other things to upstream, but all upstream wants is *not* to be blamed for downstream's mistake!

That is it!

Cheers,
Wol

This is not a good trend

Posted Mar 2, 2025 20:55 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (2 responses)

> "Reverse passing off"--the act of stripping the trademarks off and releasing it under your trademarks--can get you sued just like trademark infringement. It's illegal at least in the US and India.

No, it is not illegal in the US. Fox tried to litigate this exact issue many decades ago, and SCOTUS slapped them down. See https://www.oyez.org/cases/2002/02-428

(In that case, the original was in the public domain - but SCOTUS did not stop there, and instead made a blanket ruling that "reverse passing off" is only a thing for physical goods, so you certainly can't apply it to intangible software.)

This is not a good trend

Posted Mar 2, 2025 23:37 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (1 responses)

Before anyone misinterprets my comment and insists that I must be wrong, I will clarify: I am talking about trademark law. You still have independent obligations under copyright law.

In the case of the GPL (and most FOSS licenses), there is indeed a requirement to preserve the copyright notice. But a copyright notice is a single line, usually at the top of LICENSE.txt (or COPYING.txt, or whatever your FOSS project decided to call it), that names the author(s) of the software. Hardly anyone ever looks at it, except incidentally when they're trying to check what license is applicable. The name and branding of the product is an entirely different thing altogether, and no FOSS license (that I have ever heard of) explicitly requires you to preserve such branding.

This is not a good trend

Posted Mar 3, 2025 9:44 UTC (Mon) by Wol (subscriber, #4433) [Link]

That GPL clause that was pointed out to me elsewhere in this article basically described trademarks and it seems pretty clear to me - whether you are allowed or required to remove distinguishing marks is at the mark-owner's discretion. As explicitly stated in the GPL itself.

Cheers,
Wol

This is not a good trend

Posted Mar 1, 2025 9:51 UTC (Sat) by epa (subscriber, #39769) [Link]

You are right. The answer should lie in recognizing that a trademark is a formal adjective. Many years ago there was “Mozilla Firefox” but also a fork “Frontmotion Firefox” and potentially others not using the Mozilla trademark. You could rebrand the software without changing the executable name or the heading in menus.

Sadly nowadays the branding is “Firefox”, or “Firefox browser” for the pedantic, but the program is not installed as /usr/bin/browser. This makes it hard to preserve the freedom to make and distribute any changes you want.

This is not a good trend

Posted Mar 3, 2025 15:29 UTC (Mon) by amarao (guest, #87073) [Link] (2 responses)

This is well known thing in medical world. Every drug has non-patentable name for identification, and trade mark for the company to sell.

We should have this. It is already true for Chromium (patented trade mark: chrome), codium (patented name vs code).

Should be the same for all other software. Something to identify, and something to brag about.

This is not a good trend

Posted Mar 27, 2025 9:02 UTC (Thu) by sammythesnake (guest, #17693) [Link] (1 responses)

NB "patent" and "trademark" are unrelated concepts in law - it's wise to carefully distinguish between them because sometimes the differences are very important.

In this case, you're talking about "trademark" , not "patent".

In brief, trademark law deals with names/logos etc. that identify the creator/purveyor of a product (protecting consumers from getting the wrong thing and creators/purveyors from reputation damage) while patent law deals with inventions, giving inventors a temporary monopoly over the market for their invention in exchange for making the invention available for others to replicate once three patent period ends.

For completeness, copyright is the third "intellectual property" law often conflated, which gives creators a monopoly over copying/performing the work, and the fourth (less spoken of) one is "trade secret" which provides protections against ”secret recipes" being leaked, but it's really rather different from the other three, and doesn't make much sense in a context with published source code(!)

There are details I've glided over, but that's the general gist...

This is not a good trend

Posted Mar 27, 2025 11:56 UTC (Thu) by Wol (subscriber, #4433) [Link]

You've forgotten the fourth - "Design Patent" - which confusingly is actually a variant of trademark!

Where you protect the appearance of your product - competitors can make stuff which does the same thing, but they can't make it look the same.

(NB - the word "patent" comes from "letters patent", which is why it doesn't (in law) mean what most people assume it means.)

Cheers,
Wol

This is not a good trend

Posted Mar 1, 2025 13:49 UTC (Sat) by draco (subscriber, #1792) [Link] (8 responses)

"Linux" is a trademark.

So to follow your rule, you wouldn't be able to call them "Linux distributions" since none of them would distribute "Linux."

That seems like a huge problem.

This is not a good trend

Posted Mar 1, 2025 15:12 UTC (Sat) by Wol (subscriber, #4433) [Link] (7 responses)

> That seems like a huge problem.

Which - IF APPROACHED WITH RESPECT - really isn't.

If I bought Linux in Scandinavia, I think I'd be going home with a box of Washing Powder :-). Yes really! And that's fine, the user is not being mislead.

If I buy a Linux distro, Linux itself is only part of the distro. And the linux project is openly happy with being shipped as part of another product. But - and actually - Fedora shipping this flatpack looks like a GPL breach! - if I buy, let's say gentoo, linux, the mere name of the distro is notification that the project has probably modified linux. As required by the GPL - a "prominent notice that this is a modified version of the software".

So the fact that Fedora are shipping a modified version of the flatpack - with NO apparent indication that it is modified - is a clear black-letter breach of the GPL's requirement to ensure "prominent notices" telling the user it's been modified!

Cheers,
Wol

This is not a good trend

Posted Mar 1, 2025 17:20 UTC (Sat) by jkingweb (subscriber, #113039) [Link] (6 responses)

> But - and actually - Fedora shipping this flatpack looks like a GPL breach! - if I buy, let's say gentoo, linux, the mere name of the distro is notification that the project has probably modified linux. As required by the GPL - a "prominent notice that this is a modified version of the software".

Is it actually modified? My impression is that it's just configured differently.

This is not a good trend

Posted Mar 1, 2025 17:37 UTC (Sat) by Wol (subscriber, #4433) [Link] (5 responses)

> Is it actually modified? My impression is that it's just configured differently.

It's probably got different bundled dependencies. Editing the configurations IS a modification. Etc etc. The binary has been built from the rpm so is almost certainly "modified" as far as the GPL is concerned ...

The thing is, shipping the rpm is fine - the mere fact that it is an rpm (and the R in rpm originally stood for Red Hat, no?) tells the user that this is not the original version from the original project.

But flatpacks are meant to be distro-agnostic. The Fedora flatpack is modified and different from the project's flatpack. AND THERE IS NO VISIBLE DIFFERENCE TO THE USER. The user expects the flatpack to come from the project. It doesn't, and there is no way for a naive user to realise that. So if it isn't a GPL violation, Fedora are skating very close to the edge of the ice ... it's certainly not within the spirit of the GPL for users to be misled ...

Cheers,
Wol

This is not a good trend

Posted Mar 1, 2025 21:11 UTC (Sat) by pizza (subscriber, #46) [Link] (3 responses)

> It's probably got different bundled dependencies. Editing the configurations IS a modification. Etc etc. The binary has been built from the rpm so is almost certainly "modified" as far as the GPL is concerned ...

Uh, not necessarily. Run the configure (or cmake, or whatever) command line with different options, you're not modifying the source at all. Different dependencies present (or not) can also affect the build, again without modifying any source code.

This is not a good trend

Posted Mar 3, 2025 6:15 UTC (Mon) by NYKevin (subscriber, #129325) [Link] (2 responses)

From the GPL, version 3:

> To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.

In other words: If you distribute any file that is not 100% identical to a file provided by upstream, then you have modified the work.

You can scream until you're blue in the face that this is inconvenient, unreasonable, not what people do in practice, overly strict, etc., but if you get sued, the courts will not be interested in anything outside of the four corners of the license as it is actually written. So you should comply with the license as it is written, or at least be prepared to comply when some upstream inevitably asks you to do so.

This is not a good trend

Posted Mar 3, 2025 13:55 UTC (Mon) by pizza (subscriber, #46) [Link] (1 responses)

> In other words: If you distribute any file that is not 100% identical to a file provided by upstream, then you have modified the work.

...but that only matters if you do so "in a fashion that requires copyright permission".

Meanwhile. These copyright holders don't get to scream "BUT MAH TRADEMARKS!!!" if you create derivatives of their F/OSS that contain their trademarks, but also scream "BUT MAH TRADEMARKS!!!" if you first *strip out* every one of their trademarks and call it something completely different.

This is not a good trend

Posted Mar 3, 2025 18:59 UTC (Mon) by NYKevin (subscriber, #129325) [Link]

> Meanwhile. These copyright holders don't get to scream "BUT MAH TRADEMARKS!!!" if you create derivatives of their F/OSS that contain their trademarks, but also scream "BUT MAH TRADEMARKS!!!" if you first *strip out* every one of their trademarks and call it something completely different.

I agree. But I have never heard of the latter happening. I think you just made it up.

This is not a good trend

Posted Mar 1, 2025 23:36 UTC (Sat) by jkingweb (subscriber, #113039) [Link]

As pizza mentions, no actual modification need happen to get different compilation or runtime outcomes.

Moreover, I believe the Fedora flatpak being different from the OBS flatpak is a red herring since the former is (if I understand correctly) not derived from the latter, but rather built from the OBS source, with a different flatpak runtime environment.

I don't disagree that it's a crummy situation and that Fedora should not distribute poor-quality packages which may be misconstrued as coming from upstream, but I don't see how it rises to a license violation, based on the facts presented.

No trademarks in upstream source

Posted Mar 2, 2025 9:03 UTC (Sun) by pabs (subscriber, #43278) [Link] (19 responses)

The upstream maintainers should remove the trademarks from their source repositories and place them in separate source repos, which could be separately installed to get the same app but with a trademark.

No trademarks in upstream source

Posted Mar 2, 2025 10:23 UTC (Sun) by Wol (subscriber, #4433) [Link] (18 responses)

> The upstream maintainers should remove the trademarks from their source repositories

Why should upstream do your dirty work for you? This is, unfortunately, a perfect example of FLOSS's entitlement culture - other people, WHO ARE WORKING FOR FREE (usually), should do EXTRA work for your benefit.

Cheers,
Wol

No trademarks in upstream source

Posted Mar 2, 2025 13:25 UTC (Sun) by pizza (subscriber, #46) [Link] (14 responses)

> Why should upstream do your dirty work for you? This is, unfortunately, a perfect example of FLOSS's entitlement culture - other people,

This cuts both ways. You don't want your stuff "used" in certain ways, don't release it under F/OSS licenses.

No trademarks in upstream source

Posted Mar 2, 2025 13:42 UTC (Sun) by Wol (subscriber, #4433) [Link] (4 responses)

> This cuts both ways. You don't want your stuff "used" in certain ways, don't release it under F/OSS licenses.

I don't know about you, but I personally would like to take credit, and responsibility, for my own work. Are you telling me I need to release it totally anonymously so so other people can steal the credit?

As I've said repeatedly, don't be a jerk. Don't hide where stuff came from. Don't dupe your own downstream.

If I take ScarletDME, modify it, and market it as "Wol's DME", that's not a problem. If, however, I market my version as if it was upstream, that's FRAUD.

And you know what - I don't want my work used in "certain ways". I don't want it FRAUDULENTLY MISREPRESENTED. If you take my work, leave my trademarks in, AND PROMINENTLY ADD YOUR OWN (as *demanded* by the GPL!!!), that's fine by me.

Cheers,
Wol

No trademarks in upstream source

Posted Mar 2, 2025 23:06 UTC (Sun) by interalia (subscriber, #26615) [Link] (3 responses)

> Are you telling me I need to release it totally anonymously so so other people can steal the credit?

Huh? How did you get that reading? To me, the opposite of "releasing under F/OSS licence" would be "releasing it under a proprietary licence". I don't know you got "release anonymously" from that.

And can we have less shouting, please? For such an old timer as you profess to be, you use a lot of all caps. Please take some deep breaths for your own good and that of the site.

No trademarks in upstream source

Posted Mar 3, 2025 9:41 UTC (Mon) by Wol (subscriber, #4433) [Link] (2 responses)

> For such an old timer as you profess to be, you use a lot of all caps.

I'm enough of an old timer to remember when "all caps" was all there was! And I've reached the age where I'm a "grumpy old man" :-)

> To me, the opposite of "releasing under F/OSS licence" would be "releasing it under a proprietary licence".

Read the thread. The parent that provoked that was basically saying "if you don't want to do loads of (unpaid) work to enable other people to rip you off, you shouldn't use a FLOSS licence". I know big business has taken over large swathes of the FLOSS landscape, but we don't need to encourage them by driving the small guy out ...

Cheers,
Wol

caps

Posted Mar 3, 2025 9:50 UTC (Mon) by rschroev (subscriber, #4164) [Link]

> I'm enough of an old timer to remember when "all caps" was all there was! And I've reached the age where I'm a "grumpy old man" :-)

I'm sorry but that is a very weak excuse. We've had lower case for a very long time now. The convention that all caps means shouting, and that it therefore should be used very sparingly, has existed for 30 years at the very least by now. It has been pointed out to you multiple times here. Yet you still continue to use all caps, which in my opinion shows a lack of respect for the people you want to communicate with.

No trademarks in upstream source

Posted Mar 3, 2025 10:20 UTC (Mon) by interalia (subscriber, #26615) [Link]

> I'm enough of an old timer to remember when "all caps" was all there was!

Cool story bro, now since we can see you mastered the world wide web just fine, you're perfectly capable of not shouting so stop doing it every time a thread goes more than 2 comments deep.

> The parent that provoked that was basically saying "if you don't want to do loads of (unpaid) work to enable other people to rip you off, you shouldn't use a FLOSS licence".

So as I understand it, being "ripped off" here means having someone else pass their modified app as the original. I don't want to get caught up in who's being "entitled" about it, that's not really productive.

We often say FLOSS is scratching your own itch, well if the trademark use is a concern then isn't it fundamentally an itch of the upstream trademark holder? If an upstream feels strongly about their trademark being misused by a downstream, then I'd say it's mutually beneficial to both of them if it's straightforward to distribute an unaffiliated version without the trademarks, since the easier it is to do then the more likely it is that the downstreams will dutifully strip the trademark out rather than saying it's too much effort and daring the trademark owner to file suit.

But on a practical level there is one upstream and multiple downstreams, and if I was upstream and cared about this I think I'd prefer to do it once to have a consistent result rather than have each downstream distro patch the app individually at varying effort and quality levels. This is not about who's entitled to what work, but what would give me the best outcome.

No trademarks in upstream source

Posted Mar 2, 2025 20:59 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (8 responses)

The vast majority of FOSS licenses cover copyright. No more, no less (except for a minority which also include patent rights). You do not have the right to use the original trademarks unless a) the FOSS license explicitly includes them or b) there is a separate trademark license covering them.

The fact that this is inconvenient to you is, as far as the law is concerned, entirely your problem to solve.

No trademarks in upstream source

Posted Mar 3, 2025 7:08 UTC (Mon) by gdt (subscriber, #6284) [Link] (1 responses)

Further to this comment about trademarks, trademarks are not the only issue: there is the question of 'trade dress'. Unlike many packaging formats, Flatpak typically displays much of the trade dress used by the project. This was the essential point for OBS: the two Flatpaks were dressed so similarly that people were confusing the genuine product and the copy (a copyright-permitted copy, but a copy all the same). Fedora could perhaps make the trade dress of its own Flatpaks different enough to avoid this issue re-occuring.

No trademarks in upstream source

Posted Mar 3, 2025 9:52 UTC (Mon) by Wol (subscriber, #4433) [Link]

How many people remember (or know) the story of NCR in the Wild West days. How they regularly assumed the "trade dress" of their competition, sold shitty imitations, and destroyed other companies' reputations (and the companies with it).

Do we really want to go back to those days, and give the enemies of FLOSS a free reign to trash our reputations?

Even if we don't know about NCR, I'm sure we know all about the Windows stores that wrapped FLOSS programs in a malware or PUP containing installer, and did lots of damage. I think we've managed to stamp that out - do you really want to go back to those days?

Cheers,
Wol

No trademarks in upstream source

Posted Mar 4, 2025 12:45 UTC (Tue) by ballombe (subscriber, #9523) [Link] (5 responses)

What about trademark reference included in API/ABI ?

But fundamentaly, if the trademark make it too onerous to modify the software, we still have option to declare the software non-free. This is not a legal determination.

No trademarks in upstream source

Posted Mar 4, 2025 13:36 UTC (Tue) by Wol (subscriber, #4433) [Link] (4 responses)

> What about trademark reference included in API/ABI ?

> But fundamentaly, if the trademark make it too onerous to modify the software, we still have option to declare the software non-free. This is not a legal determination.

Your problem, then, is that you are unable to copy the software without breaking the GPL !!!

I think it was Nintendo? - lost a lawsuit over "unremovable trademarks" probably thirty years ago. If removing the trademark breaks the software, then the trademark is "essential to the operation" and loses its protection.

But why is everybody so obsessed with defrauding their own downstream? Why is everybody so obsessed (in the name of freedom) with violating the GPL?

The GPL itself requires you - unless it's a verbatim copy! - to *prominently* *mark* *it* *as* *your* *own* *version*. This is the problem with Fedora - their own users simply had no idea it was not the genuine upstream article. That's a GPL violation!

The threat of trademarks is simply a way of enforcing the GPL - "If you don't add your own marks, you have to remove mine". That's not a demand to remove marks - it's a demand that you follow your GPL obligations!

Cheers,
Wol

No trademarks in upstream source

Posted Mar 4, 2025 14:48 UTC (Tue) by draco (subscriber, #1792) [Link] (1 responses)

> The GPL itself requires you - unless it's a verbatim copy! - to *prominently* *mark* *it* *as* *your* *own* *version*.

Wol, please cite the exact license text (and context/location in the license)

The only things I find in GPLv3, GPLv2, & LGPLv2.1 are:
* In the preamble, it says modified versions should be clearly identified so the original author isn't besmirched. It then says the exact terms are specified later, so while there's an intent there, it's not (as I read it) the binding text
* Later it says that the *sources* must be marked as modified and when (but not how)
* License must be clearly marked
* Original source must be clearly marked if in a combined work
* GPLv3 does allow you to add licence terms to strengthen this further, but it's not the default.

There is nothing about "must mark the resulting version as your own"—just that it must be clear what the license is (so they know they can request source) and then that source must make the modification clear.

I dunno about flatpaks, but assuming there's some way to track them back to their sources/build recipes, then it should be clear they're based on the RPM.

RPM versions inherently identify themselves as distinct from the upstream version (due to the RPM release version added) so that format plus its storage in Git by the Fedora project addresses all the license terms of use (or should).

I didn't read the terms exhaustively, so if I missed something, please point it out.

You've also filed a bug, I assume? From what I've seen, the project takes licensing extremely seriously (they've done intensive license audits, catching numerous violations and defective licenses that other distributions missed)

No trademarks in upstream source

Posted Mar 4, 2025 19:44 UTC (Tue) by Wol (subscriber, #4433) [Link]

Thanks to NYKevin for this, but ...

> 5. Conveying Modified Source Versions.

>You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:

> a) The work must carry prominent notices stating that you modified it, and giving a relevant date.

> 7. Additional Terms.

> c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or

Hmm ... so it sounds like misrepresenting the origin isn't *automatically* a GPL violation, but it's certainly acceptable for it to be one.

Cheers,
Wol

No trademarks in upstream source

Posted Mar 4, 2025 18:10 UTC (Tue) by ballombe (subscriber, #9523) [Link] (1 responses)

> But why is everybody so obsessed with defrauding their own downstream? Why is everybody so obsessed (in the name of freedom) with violating the GPL?

Quite the contrary. I do not want to defraud anyone. If upstream does not want that I distribute modified versions, I will not do it. But then I will not consider the software FOSS. That is as simple as that.

No trademarks in upstream source

Posted Mar 4, 2025 19:50 UTC (Tue) by Wol (subscriber, #4433) [Link]

> Quite the contrary. I do not want to defraud anyone.

So why don't you care that *your* *downstream* has no idea of the true origin of the software in question? It's morally indefensible (and quite likely illegal) to misrepresent someone else's software as your own; so why do you consider it perfectly acceptable to misrepresent your software as someone else's? That's what I mean about defrauding your own downstream.

(And that's why trademarks got dragged into this, that is exactly what trademarks are for.)

Cheers,
Wol

No trademarks in upstream source

Posted Mar 3, 2025 2:15 UTC (Mon) by pabs (subscriber, #43278) [Link] (2 responses)

Trademarks are inherently proprietary, so being present in the source repository means that the source is no longer entirely FOSS.

As a monopoly power, trademarks exist to control what other people do with your software. Force them to stick to your rules about what are acceptable changes, or put in a lot of effort to manually strip out every instance of the trademark. Think about the Firefox/Iceweasel situation (which we may have to go back to given Mozilla's recent changes), or Chef or Docker or many other trademark related situations. Adding trademarks littered throughout your source code is simply a demonstration of your intent to control or penalise downstream redistributors. Not adding trademarks to your source code demonstrates that you understand that FOSS means surrendering your monopoly over your own work. It also makes FOSS feel more like a *community* and less like a jungle

https://drewdevault.com/2021/01/20/FOSS-is-to-surrender-y...

People who are working for free on FOSS projects, do not register trademarks at all. It is mainly commercial vendors like RedHat, or large projects with large donation streams. Such projects could definitely afford the time to make the trademark a runtime or build-time parameter. As an example; in recent years RedHat finally released the source code for their non-upstreamed enterprise documentation. With the switch to systemd, most of it probably applies on Debian too, so I would like to package it for Debian, but their trademarks are everywhere so removing them is going to be months of work to do in my non-paid spare time, so it will probably never happen.

https://gitlab.com/redhat/centos-stream/docs/enterprise-d...

Removing trademarks from source also makes your work as upstream simpler, since making the trademarks a runtime or build-time parameter means that when you get a branding refresh, a new logo, or even a name change, then it is one change in one place, not everywhere you ended up copying it. Imagine if every Debian desktop and window manager package had a copy of the Debian logo and the Debian wallpaper, it would be a nightmare to update the wallpaper once per release, or to go from the chicken logo to the swirl logo. We sensibly separate that out into the desktop-base package.

No trademarks in upstream source

Posted Mar 5, 2025 12:58 UTC (Wed) by epa (subscriber, #39769) [Link] (1 responses)

Copyright is also "inherently proprietary" but the presence of copyrighted code in a repository doesn't meant it is no longer free software. There is usually a licence granting back some of the rights reserved to the copyright holder. The same could be done for trademarks: you may call your modified version of grep "Billy's grep (TM)" but only under certain conditions. Perhaps trademarks could also be used for copyleft purposes: make any changes you like and redistribute them as free software, and you can keep using the trademark; if you want to incorporate the code in a proprietary product, you may do that, but must strip the trademark.

I agree that it's good practice to isolate logos, product names and so on in one place, so they can easily be stripped out or changed. A single subdirectory of the source tree would work; then package builders could remove or patch that at the start of the build process.

No trademarks in upstream source

Posted Mar 5, 2025 13:23 UTC (Wed) by Wol (subscriber, #4433) [Link]

> make any changes you like and redistribute them as free software, and you can keep using the trademark;

That's actually *extremely* *dangerous* to upstream, and that's why FLOSS (and the GPL) has (or should have) absolutely no problems with trademarks.

And again, that's why all this blew up with Fedora.

We're all happy with DCOs and Linux enforcing them (along with lots of other Free Software projects). What exactly is the difference between a DCO, and a trademark (other than *registered* trademarks having legal clout)?

A DCO is all about a developer taking responsibility for their code. A trademark is all about a project taking responsibility for their code. You'd get well pissed off if I submitted (broken) code and put your DCO on it, wouldn't you? So why is everyone up in arms about a project getting upset because somebody is using their trademarks to pass off a broken version of the project as being upstream's fault?

A DCO is all about taking responsibility for your own work - good OR bad. A trademark is all about taking responsibility for your own work - good OR bad. And you don't put *somebody* *else's* marks on your own work so that you can avoid responsibility when it all goes pear shaped!!!

(That's why I, and I suspect most other FLOSS guys, have no trouble with you taking my work AND ADDING YOUR OWN MARKS. The problem here, is Fedora didn't - or if they did those marks were rather too well hidden.)

The GPL actually *demands* you add your marks to the source. I actually think it's a bug it doesn't demand you add them to the binary (if distributed where the end user is unlikely to see the source)!

Cheers,
Wol

This is not a good trend

Posted Mar 1, 2025 23:45 UTC (Sat) by Phantom_Hoover (subscriber, #167627) [Link]

Trademark law exists as much to secure consumers’ right to honest information about the provenance of products, as it does to secure rights-holders’ intellectual property. If you’re going to alter free software enough that upstream won’t endorse your distribution, you just have to change its branding so it’s clear to users that you’ve done so, and if your modified version is actually better then that works to your advantage. It’s a system that generally benefits everyone except those who wish to, effectively, deceptively piggy-back on someone else’s work. And the free software movement has generally always recognised this and made use of trademarks as appropriate: it’s certainly not a new trend.

Please respect project branding guidelines

Posted Mar 1, 2025 2:43 UTC (Sat) by SFalken (guest, #175710) [Link] (2 responses)

Not that it's a *huge* deal, but I see that "openSUSE Aeon" is referenced in the article text.

That's actually something that the developers specifically request not be done, in general:

https://en.opensuse.org/Portal:Aeon/BrandGuide#Word_Marks

Calling it "Aeon" or "Aeon Desktop" or some variation thereof is perfectly acceptable.

Please respect project branding guidelines

Posted Mar 1, 2025 16:45 UTC (Sat) by jzb (editor, #7867) [Link] (1 responses)

Thanks for pointing that out - it looks like the brand guidelines were introduced in July last year after I'd written about Aeon in June - so I'd missed these. Happy to make the correction - though, note, we prefer corrections sent to lwn@lwn.net rather than as comments. Thanks!

Please respect project branding guidelines

Posted Mar 1, 2025 18:18 UTC (Sat) by SFalken (guest, #175710) [Link]

Fair enough, sorry about that.

Highlighting the trademark issue ...

Posted Mar 1, 2025 9:48 UTC (Sat) by Wol (subscriber, #4433) [Link] (2 responses)

>The reason Bethke requested that the Flatpak either be removed, or that the Fedora Flatpak be clearly identified as a third-party package, is that users were not even aware they were using Fedora's instead of the OBS project's.

Probably too late now the horse has bolted, but this is the relevant text from the article. And this - unfortunately - makes it extremely clear why this is a trademark issue. If users are unaware they are using a 3rd-party, broken, version then we have a problem ...

Cheers,
Wol

Highlighting the trademark issue ...

Posted Mar 1, 2025 17:34 UTC (Sat) by mcatanzaro (subscriber, #93033) [Link] (1 responses)

Keep in mind that we're talking about Fedora's software center, so the upstream version from Flathub is considered third-party; you do not see it at all unless you click the "Enable third-party software" button (which users are, in fairness, encouraged to click). Only the Fedora Flatpak and Fedora RPM are available by default. (But yes, from upstream's perspective, the official Fedora packages are certainly the third-party ones....)

Highlighting the trademark issue ...

Posted Mar 1, 2025 17:56 UTC (Sat) by Wol (subscriber, #4433) [Link]

> so the upstream version from Flathub is considered third-party; you do not see it at all unless you click the "Enable third-party software" button

That could easily be seen as even worse ... you don't see the original project flatpack, but because it's a flatpack it doesn't cross your mind it might be that self-contradictory beast - a distro-specific flatpack ...

Cheers,
Wol

Converging and diverging paths

Posted Mar 1, 2025 17:01 UTC (Sat) by easwarh (subscriber, #131924) [Link] (5 responses)

It's interesting to note that the Windows ecosystem is going towards a centralized app store a la package repositories with Winget and Microsoft Store, while the Linux ecosystem, per this article, is going towards the old Windows approach of everyone providing their software from their own website, modulo some minimal centralization in Flathub. I wonder how long it'll be until the Windows user culture of "do a web search and click the first link" permeates the ecosystem, with its attendant security issues.

Converging and diverging paths

Posted Mar 1, 2025 17:49 UTC (Sat) by hunger (subscriber, #36242) [Link]

I'd argue that linux is heading toward an immutable image you download + flatpak. That seems very centralized to me:-)

Converging and diverging paths

Posted Mar 1, 2025 17:51 UTC (Sat) by Wol (subscriber, #4433) [Link]

> I wonder how long it'll be until the Windows user culture of "do a web search and click the first link" permeates the ecosystem, with its attendant security issues.

Well, this kerfuffle over trademarks shows the dangers of the "every website to its own" approach, but the central store has a very different set of issues - Apple and Microsoft and Google like the central store because it provides a nice convenient toll-booth.

The FLOSS world should be firmly behind trademarks, and treat them with respect, because they provide the legal guarantee that you're actually getting "the real deal". That was why trademarks were introduced in the first place! And the "every product on its own website" isn't a problem if trademarks are respected and enforced.

Rule 1 - don't mislead your users! Okay, some users do a damn good job of misleading themselves, but we should most definitely not be setting out to mislead others, and if somebody points out that our actions ARE misleading (intentional or not) then we should FIX IT. That's the tragedy here - that it's easy to see why/how users would be mislead, and Fedora seems unable to see the problem.

Why are distros using flatpacks??? They're meant to be distro-agnostic packages, so as original distro software, they don't make sense.

Cheers,
Wol

Converging and diverging paths

Posted Mar 1, 2025 19:34 UTC (Sat) by lunaryorn (subscriber, #111088) [Link]

Winget is "everyone providing their software from their own website", literally, just not with the a web browser as frontend. It's not a central repository of binary packages, it doesn't do dependency handling, it's just a collection of recipes to fetch and run upstream binary installers.

When you install Firefox with winget it's literally downloading and running the same installer you'd have downloaded from the Firefox website. When you install git it pulls down the same all-in-one Git for Windows installer from the Git For Windows Github page that's linked on the Git website.

By contrast, Flathub really is a central repository of binary packages, accompanied by a central build infrastructure. Flathub hosts it's own binaries, and, apart from a few notable exceptions, requires packages to be built on its own infrastructure.

It's more than the Microsoft Store, even, it's really a proper package repository, just distribution independent with a focus on desktop applications, much coarser dependencies, and a few other minor technical differences compared to traditional Linux package repositories.

When you install an open source application from flathub you get, apart from. said exceptions, a binary that's hosted on Flathub infrastructure, built on Flahub infrastructure from upstream sources.

Converging and diverging paths

Posted Mar 3, 2025 3:24 UTC (Mon) by notriddle (subscriber, #130608) [Link] (1 responses)

> It's interesting to note that the Windows ecosystem is going towards a centralized app store a la package repositories with Winget and Microsoft Store, while the Linux ecosystem, per this article, is going towards the old Windows approach of everyone providing their software from their own website, modulo some minimal centralization in Flathub.

They're moving in different directions, but that seems like it's because they're coming from different places and moving towards the same place. Flathub and the Windows store have a lot more in common with each other than either of them have in common with the approaches they want to displace.

The "app developer" packages the app themselves and uploads it through a fully-automated developer portal. Dependencies come from an integrated "SDK" or "Runtime" (these terms are basically synonyms), not piecemeal the way dpkg or rpm do it. If you want dependencies outside the SDK, you vendor them. You are solely responsible for what you include in your uploaded bundle, no matter where you got it from; the SDK, on the other hand, is dynamically linked and can receive bug fixes without you doing anything. If your app is properly sandboxed, it cannot load any code that isn't part of either the SDK or the app bundle, no matter what any other app that happens to exist on the machine might do.

The biggest difference is that Flatpak lets end users add repositories, but that's an ability they inherit from APT and YUM, not a change.

(Full disclosure: While I have not actually uploaded a Windows app to their store, I've uploaded an add-on for Edge, which uses a developer portal called the "Partner Center" with a somewhat-prominent button to enroll in additional programs, including "Windows: Register as an app developer to submit apps and games to Microsoft marketplaces." Also, I've uploaded Android apps, and, from the outsiders' perspective, the Play Store and the Windows Store work exactly the same.)

Converging and diverging paths

Posted Mar 3, 2025 17:50 UTC (Mon) by smcv (subscriber, #53363) [Link]

> Dependencies come from an integrated "SDK" or "Runtime" (these terms are basically synonyms)

They go together in pairs, but are not the same. The developer or packager compiles against a SDK (which is large), and then the end user runs the program against a set of runtime libraries which has been chosen to have its supported libraries and their versions line up with the SDK (but the runtime library stack used by the end user is smaller, because they doesn't need to contain developer-only stuff like compilers, headers and static libraries).

In Flatpak, the SDK is called a SDK, the runtime library stack is called a Platform, and they are both said to be "runtimes". Other ecosystems have different words for essentially the same thing.

Traditional package-based distros do the same, except that instead of having exactly one SDK that is supported at compile-time and exactly one set of runtime libraries that is supported at runtime, any set of packages that meets the requirements specified in the packaging is assumed to be supportable. In distributions that have a distinction between developer and end-user packages, the SDK-like environment has development packages (Debian -dev or Red Hat -devel or similar) but the end-user environment usually does not.

What exactly is wrong with Fedora's OBS?

Posted Mar 2, 2025 13:14 UTC (Sun) by zdzichu (subscriber, #17118) [Link] (2 responses)

This is another article I see about beef OBS has with Fedora , and this glances over specifics, too.
What are the problems with Fedora package/flatpak? The one linked bug, about H264 encoder, lacks and troubleshooting investigation. It is not proved Fedora package is at fault, just a handwaving.
I did not see any other BZ ticket or issue clearly stating what's wrong with Fedora packaging (if anything!). And this should be the first step to resolve the situation.
Nevertheless, this raises the question: certainly, there are differences between upstream flatpak and Fedora's. If there were none, there would be no need for Fedora package. So what are those differences, are they important, are they faulty?

What exactly is wrong with Fedora's OBS?

Posted Mar 2, 2025 15:45 UTC (Sun) by ballombe (subscriber, #9523) [Link]

One could argue that a version of the KDE/Qt runtime need to be supported until all regression reported in the next version are addressed. Otherwise we can easily reach a situation where no working version are supported.

What exactly is wrong with Fedora's OBS?

Posted Mar 2, 2025 17:41 UTC (Sun) by jzb (editor, #7867) [Link]

and this glances over specifics, too

I tried to include the specifics as much as possible—but they are in short supply. There was no BZ to refer to. Upstream doesn't want to fiddle with filing bugs against Fedora's packaging anyway—they just want users to get what they've produced directly.

I think they did display that the Fedora Flatpak had issues that were not reproduced in the upstream version. The other issue—perhaps this wasn't emphasized strongly enough—is the confusion over which Flatpak users were running and that the Fedora version was prioritized over the upstream one. IMO that's a legitimate concern. There's still some room for improvement in the way software is delivered to users in Workstation to make it abundantly clear if the package is from Fedora, if it's a Flatpak or RPM, or if it's a Flatpak from Flathub that's verified. The only reason I know the difference when installing software is because I've paid attention and written about it. At first glance, it wouldn't be obvious to me—and I expect that's true of others.

certainly, there are differences between upstream flatpak and Fedora's. If there were none, there would be no need for Fedora package

I think that's also part of the question/problem. It seems like a lot of Fedora Flatpaks may just be RPMs that are scooped up into the Flatpak format and they don't receive the same amount of testing. Maybe Fedora's Flatpak SIG feels it needs to provide a wide range of software for Silverblue, etc. and could step back and reconsider some packages if they are available via Flathub? Dunno.

2 packagers but 3 packages?

Posted Mar 3, 2025 7:30 UTC (Mon) by marcH (subscriber, #57642) [Link] (11 responses)

Sorry if I read too fast but... how come there are three different packages available? No matter what their format is.

As usual, we have two potential "packagers":
- upstream
- the Linux distribution in use

Often less than two when upstream is not interested in packaging. Or when the distro does a quick and dirty job that does not really count (for instance: when a single person packages 100s of packages?)

So, a grand maximum of two "packagers". So how come we end up with three different packages? Are Fedora packagers not talking to each other?

The most time-consuming thing is not compiling and packaging, it's QA: _testing_ and making sure everything works, making sure known vulnerabilities are patched, reviewing changelogs, establishing a trust relationship with upstream etc. No Linux distribution has the bandwidth to do this twice (I bet: not even once sometimes)

QA and trust

Posted Mar 3, 2025 7:31 UTC (Mon) by marcH (subscriber, #57642) [Link]

The debate about priorities seems to also sweep quality under the rug. No matter who packages and how, the most important is: does it work; which bugs and vulnerabilities there are. That's the most important part of the user experience, much more important than the packaging approach and technology. So, package priority should not be hard-coded to the packaging technology, that's the tail wagging the dog. Package priority could have a default but that default should be easy to override on a per-package basis.

> Users want Flatpaks created by upstreams, but are confused by the way they are displayed in GNOME Software. He recommended that the priority be changed to display software from Flathub first, then Fedora Flatpaks, and finally Fedora RPMs.

In any case, it should always be crystal-clear which software comes from where. Not just for deciding which bug tracker is relevant but also for obvious trust and security reasons. No user interface should ever hide software provenance(s) and make installation so easy it feels "magical". Users should be invited to pause and think before installing and running less common software that isn't "core" and is not used by everyone else. Cause it very likely had much less scrutiny and is then more likely to have bugs, vulnerabilities and backdoors. It's easy to make fun at how time-consuming and painful it is to install software on Windows, but this also forces users to be a bit more conscious of what they are doing. There is a middle ground/sweet spot somewhere.

https://queue.acm.org/detail.cfm?id=3344149 "Surviving software dependencies" - a lot applies exactly the same here.

Let's try to move the software industry past its teenage years.

2 packagers but 3 packages?

Posted Mar 4, 2025 0:59 UTC (Tue) by AdamW (subscriber, #48457) [Link] (9 responses)

Because two are flatpaks and one is an RPM.

1. Fedora RPM
2. Fedora flatpak
3. Flathub flatpak

The Fedora flatpak is built from the Fedora RPM.

2 packagers but 3 packages?

Posted Mar 4, 2025 4:09 UTC (Tue) by marcH (subscriber, #57642) [Link] (8 responses)

> The Fedora flatpak is built from the Fedora RPM.

Thanks - but why does Fedora do that, what is the point? Please feel free to shame me and point me at the part of the article I missed.

2 packagers but 3 packages?

Posted Mar 4, 2025 6:56 UTC (Tue) by zdzichu (subscriber, #17118) [Link] (7 responses)

The point for packaging an RPM is obvious, I hope. For the flatpak, there are experiments with immutable distributions (Fedora variants Silverblue and Kinoite). Immutable distributions are cumbersome to add software to, but this is alleviated by having apps in flatpaks. If you have to provide a app in such format, it is most obvious to build a flatpak from an existing RPM. It is (in theory) already audited, integrated and follows distribution lifecycle.

2 packagers but 3 packages?

Posted Mar 4, 2025 8:19 UTC (Tue) by marcH (subscriber, #57642) [Link] (6 responses)

> Immutable distributions are cumbersome to add software to, but this is alleviated by having apps in flatpaks.

Thanks. So, immutable variants never have 3 packages because the RPM is not compatible with them. Great.

This still does not explain why the Fedora RPM and the Fedora Flatpak are _both_ available on the regular, "mutable" Fedora.

2 packagers but 3 packages?

Posted Mar 4, 2025 9:43 UTC (Tue) by farnz (subscriber, #17727) [Link] (5 responses)

There's two reasons (one good, one that probably ought to be fixed in the long run and is marginal to begin with) to have both a Fedora RPM and a Fedora Flatpak:
  1. Flatpaks are sandboxed in ways that RPMs just aren't (at least for now). As a result, if you're uncertain whether a given piece of software is suitable for your needs, a Flatpak is marginally safer.
  2. If you're running Fedora Workstation, but want to work out whether Fedora Silverblue would work for you, you need to swap out RPMs for Flatpaks to confirm that the same software packaged as a Flatpak works for you despite the sandboxing.

And the reason to have Fedora Flatpaks as well as upstream is that Fedora promises that its software meets a set of policies; Flathub (and other sources of Flatpaks) don't promise to meet Fedora policies, for fairly obvious reasons.

2 packagers but 3 packages?

Posted Mar 4, 2025 21:23 UTC (Tue) by marcH (subscriber, #57642) [Link] (4 responses)

Thanks!

> Flatpaks are sandboxed in ways that RPMs just aren't (at least for now). As a result, if you're uncertain whether a given piece of software is suitable for your needs, a Flatpak is marginally safer.

OK, so if Flatpaks are generally better then don't offer the corresponding RPM available when a tested Flatpak is already offered.

> If you're running Fedora Workstation, but want to work out whether Fedora Silverblue would work for you,...

That's useful for developers, packagers and testers. Not for "plain" users. The ability to try both is great, but both should still not to be offered by default.

Thanks to everyone who answered I'm starting to suspect the root problem/original sin is really this: _it's not possible to make decisions on a per-package basis_. In some cases the Fedora RPM should be the only Fedora package offered. In other cases, the Fedora Flatpak is available and better and it should be the only Fedora package offer. But the package management software is not flexible enough to support such decisions and fine-grained configuration. That sounds like the big shortcoming affecting the user experience.

Developers should always be able to opt-in and be offered everything that is available. But regular users should not have to make choices like this. Plain users pick a Linux distribution expecting a cohesive whole where they generally do not have to think and combine packages and versions themselves.

Or, maybe Fedora is just a distribution focused on developers and not very good for plain users. Fine by me! I'll keep using it anyway.

2 packagers but 3 packages?

Posted Mar 4, 2025 21:39 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

> OK, so if Flatpaks are generally better then don't offer the corresponding RPM available when a tested Flatpak is already offered.

IIUC Fedora flatpaks are always built _from_ the RPMs.

2 packagers but 3 packages?

Posted Mar 5, 2025 0:24 UTC (Wed) by marcH (subscriber, #57642) [Link]

> > OK, so if Flatpaks are generally better then: do not offer the corresponding RPM available when a tested Flatpak is already offered.

> IIUC Fedora flatpaks are always built _from_ the RPMs.

So?

Does that mean the flatpak can only be safer hence better? Then hide the corresponding RPM.

In practice, some unexpected things always go wrong and I bet some flatpaks can fall... flat. Couldn't resist, sorry. Then, hide that particular flatpak from non-developers.

In any case some level of per-package flexibility is required.

2 packagers but 3 packages?

Posted Mar 5, 2025 8:23 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

Flatpaks are better on the assumption that the sandboxing does not block anything you want it to do - but that's a big assumption. For example, I tried running on Silverblue, but found that the way the GNU Emacs Flatpaks behave (both Fedora and Flathub) was incompatible with my workflows because of the sandbox (albeit I've since switched away from Emacs)

But (as a counter), I'm happy with LibreOffice from Flatpaks, because the sandbox doesn't get in my way. I'm slowly removing non-Flatpak packages and replacing with Flatpaks, with the intent to switch over to Kinoite (because I keep coming back to preferring KDE to GNOME) once I've reduced my system to one where all applications I use are Flatpaks.

That said, your software setup should only show you one of the 3 options at a time; I've just checked KDE's Discover, and there's a button at the top-right to choose a source - either "Fedora Linux", "Fedora Flatpaks" or "Flathub", with a different icon for "Fedora Linux". It also has a default choice it makes, which can be set by the distro; I believe that 99% of the issue is that Fedora's default was set to prefer Fedora Flatpaks over Flathub, and Flathub over RPMs, and if it were configured to prefer RPMs or Flathub, the issue would be less serious.

2 packagers but 3 packages?

Posted Mar 5, 2025 14:31 UTC (Wed) by madscientist (subscriber, #16861) [Link]

Agreed; the GNU Emacs flatpak wasn't useful to me due to the sandboxing. On the other hand, I use Gnome Evolution via flatpak and it works great for me.

However, the GNU Emacs snap (which uses snap's "--classic" option) allows me to use up-to-date GNU Emacs on my ~5 year old distribution (which I can't upgrade for $Job IT reasons).

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 15, 2025 1:41 UTC (Sat) by andrejp (guest, #47396) [Link] (38 responses)

The idea that flatpacks/snaps are somehow better, is false. It's the wintendo way of software distribution.

The claim that it's somehow "safer" is also false. Want to sandbox the app? Sandbox it in the system, not in the package.

The very reason linux chose centralized distribution of software ("distros") is that the app software is separate from the dependencies. Ergo if a dependency breaks or has security issues, upgrading the dependencies in the system can fix it. Meaning a distro can fix issues that the app devs either can't or won't, and distros need not wait for upstream to update dependencies in the package, which they might - or might not - after and if they release a new version. Doing so mid-cycle is unlikely as it means more work for them. And until they do, the app is broken/vulnerable, together with the system that the app is installed on - it's a pretty obvious vector of attack, same as it is on wintendo.

Hence a centralized repo is *safer* than an app packaging all the dependencies. It's the very reason *why* distros even exist and *why* distros don't (didn't) want users to install apps together with all the dependencies in a single package. It's also part of the reason *why* linux distros are (were) much more secure than wintendo app distribution.

But now I read how "flatpacks" and "snaps" are somehow better. Better how? What security are you talking about? If an app needs to interoperate with the rest of the system, don't sandbox it. Doing it anyway will probably break it in subtle ways. And if an app requires sandboxing, do it in the *system*, not the package. Why are you even relying on 3rd party package and packager to do it right? They might not even have the skill to do it, or the will, or the resources. They might not even care, or they might break it intentionally. It's stupid beyond explanation, yet y'all are telling me that it's somehow "more secure"?

And don't force multiple copies of packages on the system. Flatpacks and snaps are fscking abominations on the system. Run "snap list --all" and there's two copies of *everything*. Just in case a user might want to... what? Uninstall the last version and install/use the previous one? 'Cause otherwise she can't do that? GTFO. Run "mount" and there's tens of mounts, to the point that the output is basically useless unless what you want to see is the list of installed abominations. Same for df, with systemT ('T' as in "trash") polluting 'df' output with "credentials" and what not. How are "credentials" a fscking block device? And if they're not, why the fsck are they polluting df space to where it's about as useful as "mount" - which is not at all?

I'd uninstall Lennart if I could, together will all the flatfootedpacks and snaps that I'd happily snap a big fat stick on beating them off the system. Heck I'd snap as many sticks as it would take to where not one "snap" or "flatpack" remains. Alas, most - if not all "distros" (as in short for "centralized software distribution repository") these days seem to prefer the wintendo way. Which makes the purpose of these distros even existing questionable. What do you need a "distro" for if every 3rd party package copies half the system with it as bundled dependencies? Multiple times?

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 15, 2025 3:19 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (37 responses)

> But now I read how "flatpacks" and "snaps" are somehow better. Better how? What security are you talking about? If an app needs to interoperate with the rest of the system, don't sandbox it.

The problem is, it's not binary. You still want your app to be able to read the files, just not arbitrary files, but the ones that users select.

> Doing it anyway will probably break it in subtle ways. And if an app requires sandboxing, do it in the *system*, not the package.

Flatpaks don't sandbox themselves, the system does it.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 18, 2025 2:33 UTC (Tue) by andrejp (guest, #47396) [Link] (36 responses)

> The problem is, it's not binary. You still want your app to be able to read the files, just not arbitrary files, but the ones that users select.

Exactly the point I was making.

> Flatpaks don't sandbox themselves, the system does it.

Semantics. Tautology. The "sandbox" (access) border is where it is. "Packs" put it at "package" border. But your own example says you want more flexibility than that. Hence the argument: if an app needs to interoperate with the rest of the system ("the files that users select"), don't sandbox it (at the "package" level). Doing so anyway will just break the app in subtle ways (as in "you want users to select files" which are outside the scope of the package sandbox). Hence the second half of the argument: proper place to do it is "in the system" (fs or whatever subsystem is relevant).

That being the case (that the proper way is to do it "in the system" and not "in the package"), how are these packs better? What security are you talking about? It's just a fixed sandbox border that is itself a problem if the app needs to interoperate with the rest of the system. Which most generally do. And to enable this "interoperability with the reset of the system", the "pack sandbox" needs to be worked around and circumvented, and the app then sandboxed again at some other ("the system") level ("to be able to read the files, just not arbitrary files, but the ones that users select"). Which makes the fixed sandbox at the package level not only redundant, but problematic.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 18, 2025 2:46 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (35 responses)

> Semantics. Tautology. The "sandbox" (access) border is where it is. "Packs" put it at "package" border.

Are you an LLM?

Flatpacks provide a way to limit the access to the system via portals, sandboxing all other ways of access: https://docs.flatpak.org/en/latest/portal-api-reference.html

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 18, 2025 2:59 UTC (Tue) by andrejp (guest, #47396) [Link]

> Are you an LLM?
> Flatpacks provide a way to limit the access to the system via portals, sandboxing all other ways of access:

Puhlese...

You should probably ask yourself that, considering your generic "answer".
Turing test fail lol.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 18, 2025 3:35 UTC (Tue) by andrejp (guest, #47396) [Link]

> https://docs.flatpak.org/en/latest/portal-api-reference.html

In other words, "here's how you can circumvent our sandbox so you can implement a different one - we'll even provide you with tools, it's just another API for the API, to supplement the original API, and it all works on the same system-level APIs that you can use without ever even touching our APIs. but hey, it's all free, so why complain and object, right?"

Like a free bullet in the head. No reason why anyone would ever object or complain about anything, as long as it's free.

LOL.

Don't worry, I've learned my lesson. I'll go back to just reading, same as I've been doing for the last 30 years.
And honestly - the IQ test was real easy.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 18, 2025 8:53 UTC (Tue) by mbunkus (subscriber, #87248) [Link] (32 responses)

As the author of an application that needs to read files that reference other files which it also needs to read, this approach is rather limited. Think of LibreOffice documents referencing externally stored pictures or, in my case, Blu-ray index/playlist files referencing tens of M2TS and image files. It is a way to sandbox, just not a really comprehensive or good one.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 18, 2025 9:29 UTC (Tue) by intelfx (subscriber, #130118) [Link] (16 responses)

> Think of LibreOffice documents referencing externally stored pictures or, in my case, Blu-ray index/playlist files referencing tens of M2TS and image files. It is a way to sandbox, just not a really comprehensive or good one.

How would you solve this?

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 18, 2025 9:35 UTC (Tue) by mbunkus (subscriber, #87248) [Link] (15 responses)

I don't have a solution. I'm only pointing out a fundamental flaw in one of the advertised central advantages of systems such as Flatpak I've had to deal with as an application developer providing AppImags & Flatpaks. In my case I have to disable the file system sandbox, allowing the application access to the whole host file system (Unix permissions still apply, of course; it only means the sandbox doesn't apply further restrictions).

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 18, 2025 9:40 UTC (Tue) by intelfx (subscriber, #130118) [Link] (14 responses)

Are you sure the flaw is *fundamental*?

If you think that what Flatpak does is "a way to sandbox, just not a really comprehensive or good one", then *what exactly* would be a comprehensive or a good one instead?

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 18, 2025 9:58 UTC (Tue) by mbunkus (subscriber, #87248) [Link] (1 responses)

I haven't thought about how file access might be sandboxed better because I'm not interested in designing such systems. I'm simply observing & reacting to how it affects me as an application developer. To me it seems that the sandboxes targeting the Linux desktop use the "require user interaction for each file accessed" model. This has two problems that I can see right from the start:

1. The "files referencing other files" issue I've already mentioned
2. Making it much harder for cli-only applications as they usually don't use GUI libraries such as Qt, meaning there's no easy way to shove portal-like functionality in there without having to adjust your code — but I may be wrong here; I simply have never seen it (Flatpak is very much tailored towards GUI applications; as a matter of fact you cannot package cli-only applications as Flatpaks properly)

There are two other sandboxing systems out there that I know about tangentially: Android & systemd. I know little about Andoid, but what little I know seems to be a two-part system: an application always has access to its own private piece of land within the file system that no other application has access to, and you can grant it access to the rest of the non-system parts of the file system via Android's permission system. It's not as fine-granular as Flatpak's system but requires much less interaction. It benefits from the fact that Android itself has a rigid design that it can impose on all applications, unlike generic Linux systems where users can store files anywhere, really.

systemd's sandboxing system is quite fine granular as you can set up certain paths to be read-only, others to be read/write, restrict capabilities etc. However, this setup is required before the program is started, meaning the admin has to know in advance which parts of the file system will be accessed in which way. This works fine for well-known daemons; it doesn't work so well for applications dealing with general user data such as LibreOffice or my own applications. In my case users often have stuff in their home, or on mounted network shares, on in places such as /data on different partitions etc. etc.

Again, I have no solutions here. This is a hard problem. Maybe there isn't a good one-model-fits-all solution at all, though I hesitate to say that as I certainly lack the knowledge in the area of sandboxing techniques to make such an assertions.

Maybe I'm just a bit annoyed with statements such as "<sandboxing technique> apps are more secure as they limit what the application can access". Yeah, it's partially true, and I'm probably just an annoying nitpicker.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 18, 2025 10:18 UTC (Tue) by intelfx (subscriber, #130118) [Link]

> I know little about Andoid, but what little I know seems to be a two-part system: an application always has access to its own private piece of land within the file system that no other application has access to <...>

> systemd's sandboxing system is quite fine granular as you can set up certain paths to be read-only, others to be read/write, restrict capabilities etc. However, this setup is required before the program is started

Flatpaks also have their own internal store that they can access freely without any permissions. They also have an option to statically require RO or RW access to specific parts of the host filesystem (like systemd daemons).

> <...> and you can grant it access to the rest of the non-system parts of the file system via Android's permission system

Like you said, in Android's case, this likely only works because *almost all* storage is compartmentalized. So "non-system parts of the file system" is basically "free-form user files". There's no way for an app to abuse this grant to access system files or, importantly, other apps' files.

On Linux, this is not an option — direct filesystem access (even limited to non-system files) is a much broader brush. Except, maybe, if you filter all the dotfiles via some kind of security layer (and even then, you'll eventually get stuck with either false-positives or false-negatives).

Perhaps what's missing is just an ability for an app to request access to the containing directory along the user-picked file, or request access to a precomputed path. Does not sound like a *fundamental* problem to me — has anyone tried asking the XDG guys to add this to the relevant portal spec?

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 18, 2025 9:58 UTC (Tue) by Wol (subscriber, #4433) [Link] (11 responses)

> Are you sure the flaw is *fundamental*?

If by "fundamental" you mean "a real pain in the proverbial for the user", then I think it is. Unless you comprehensively think through all use-case scenarios (which imnsho most developers are cognitively incapable of doing) you are going to have quite a horde of users complaining "my use case is broken".

For example, something I do, for very simple and good reasons, is have a humungous load of hard links all over my system. Less so now, but my wife and I took loads of photos (my camera tells me it can only store 1100 photos on the 100GB of flash cards in it ...) so they were all stored in a central area, owned by root (to prevent accidental damage), and linked everywhere they were required. Niche usage, sure, but most apps don't have a clue about that sort of setup. And there'll be plenty of other niche cases out there ...

Cheers,
Wol

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 18, 2025 10:06 UTC (Tue) by intelfx (subscriber, #130118) [Link] (10 responses)

No, by *fundamental* I mean "essential to how Flatpak operates", "unfixable".

It might be an important problem, but I'm almost certain it's not a fundamental one.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 19, 2025 6:26 UTC (Wed) by andrejp (guest, #47396) [Link] (9 responses)

Actually, it is. Both. See my original message.

It's akin to scratching your ass if your arm itches. It might feel good, but won't actually do anything about the itch. Alas the "Lennarts" of the world insist that "this isn't the itch you're looking for" (waving hand) and would instead provide users with a fat sticker to put over the arm, claiming that that will somehow fix or prevent any and all itches. Which in theory sounds fine until the arm starts to itch anyway. For which Lennarts provide more, bigger and fatter stickers, along with a stick as a "free" bonus (so don't complain, 'coz it's free) so you can scratch your ass more conveniently.

Check the internet. Or at least LWN. Seems like a whole lot of people with itches they can't scratch, 'coz Lennart and his one-fix-for-all stickers.

The solution ofc is to uninstall Lennart, along with packs that fall flat, snaps that mostly snap the system's resources, and systemT (T as in "trash"). Then the itch can be scratched by the user in the proper place. And if you want to feel good too, you can also scratch your ass, even if it doesn't itch. All without Lennart's "free" sticks and stickers.

It's pretty simple actually. A system-wide MAC can do it. It's helpful if a systems integrator ("distro") - and /not/ the 3rd party that provides the app - provides the default MAC sandbox for the app(s), but not strictly required. Then the *user* can add the required permissions/exceptions for *his* use case. All "in the system" (and not "in the app package"). No Lennart required.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 19, 2025 6:42 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (6 responses)

Such an elaborate comment, ruined by hate speech and personal attacks. Don't do it again, please keep the discussion civil.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 19, 2025 9:42 UTC (Wed) by andrejp (guest, #47396) [Link] (5 responses)

If you're seeing "hate speech", you should probably check the dictionary on what that actually means.

That I loathe Lennart's "solutions" that much is obvious. Hardly "hate speech" though, unless you define "hate speech" as "you disagree with my solutions" == "you hate me".

Or perhaps you equate my using "Lennarts of the world" with "hating Lennart"? Well I don't "hate Lennart", but I do use the idiom a bit akin to "Karens of the world". Perhaps it's not "fair" to Lennart, so let me give an example.

Suppose someone was to park a proverbial truck in your living room as a "solution". Would that make you happy? No? What if that someone then told you that the truck solves *his* problem superbly and that if you don't like the truck, that is *your* problem, so *you* should "work around" the truck (ie. "WONTFIX")? No? You'd still protest? Darn. I'm sure though that if the proverbial truck displayed a big red sign in the windshield that said "truck tainted 'coz living room too small", that would definitely make you love the truck. Fo' sure. Or else you're just a "hater" lol. Especially if you suggested in no uncertain terms to remove the fscking truck - that would no doubt be a big, "uncivilized" no-no.

Right?

So perhaps you can understand what I mean by "Lennarts of the world": the types that park proverbial trucks in other peoples' living rooms and expect other people to "work around" the truck while at the same time waving off and labeling any criticisms or objections or suggestions to remove the truck as "hate speech" and "personal attacks". It *is* just a truck, right? And it's not even that big - it didn't even fill the *whole* room, you can still walk around it, and it comes with a built-in kitchen sink too! You've just saved space in the kitchen! And best of all, "it's free"! So why so much "hate"?

Or, perhaps you just disagree with me seeing LP as a "Lennart" per example above.

Well okay, that's perfectly fine. I'm sure a number of other readers would possibly - even probably - agree with my own view. YMMV.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 19, 2025 9:58 UTC (Wed) by andrejp (guest, #47396) [Link] (4 responses)

And just to make this perfectly clear: I don't view *everything* by LP as bad. Some of it is actually pretty good. The bad tho is like the proverbial truck given in the example. And with no means of separating the truck from the bundled kitchen sink while at the same time making the truck a hard dependency of the living room, can you really blame me for wanting to remove the whole effin' truck? Or for not wanting that "someone" to park more trucks in other rooms?

I mean... "GRUB tries to do too much, and most of those things are a mistake, he said."
No, wait, that wasn't my comment. Hm.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 19, 2025 13:07 UTC (Wed) by daroc (editor, #160859) [Link] (3 responses)

Regardless of the precise terms they used, zdzichu is completely correct. We require comments here to be polite, and to avoid personal attacks. Saying that you dislike systemd is perfectly fine. Explaining your technical problems with it is welcome. Being rude about it and personally insulting Lennart isn't.

Please stop this thread of conversion here, and be less vitriolic in your future comments.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 21, 2025 14:52 UTC (Fri) by andrejp (guest, #47396) [Link] (2 responses)

Funny how even after it has been thoroughly explained what this is and what this is not, you still found it in you the need to point out how you agree with the labeling. That is actually far more "rude" than anything I've said - you're lecturing me on how comments should be polite and to avoid personal attacks and that rudeness has no place in the comment section, while at the same time completely ignoring everything I've said and just reapplying the labels, even adding more ("vitriolic").

I don't think you see how rude and personally insulting *that* is.

But then again, it's part of the same reason why Lennart has been getting all that flak: snubbing and hand-waving off anyone that happens to not quite fit into the crowd of cheerleaders, or even outright disagrees with the crap that's being pushed on users.

I understand - you don't like words like ass, shit, crap, fuck and so on and so forth. But gee, see what happens if I first snub and hand-wave you off (like I just did - deliberately, not to offend or incite you, but in order to demonstrate a point), then label you with some juicy and colorful labels ("you're 'hating me'", "your comment is full of 'vitriol'", "I find your comment to be 'personally insulting'"). First you're going to "warn" me "politely" (check). That failing, you're going to use "stronger" words ("hate speech", check). That failing, you're going to propose "uninstalling" this uid, 'coz "he's parking 'trucks' (ass, shit, fuck, crap) into the 'living room' (this comment section)" (pending, probably being considered). That still not having the desired effect (new uid), your next step is probably going to be to suggest "uninstalling" the IP this comment has come from. Then probably "uninstalling" by "legal action". And so on.

In other words, you'll want "the *whole* 'truck' out of your fscking 'living room'".

To which my response to you is, again deliberately, in order to demonstrate the point: "please stop with the hate speech", "please stop personally insulting me" and "be less vitriolic in your future comments".

Stop now

Posted Mar 21, 2025 15:14 UTC (Fri) by jzb (editor, #7867) [Link]

OK. Time to end this thread. To be very clear—the comment section is not the place for people to snipe at one another. It's quite OK to have disagreements on topics, but nobody needs or wants to read two or more commenters just arguing with each other. Stop here.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 21, 2025 15:15 UTC (Fri) by andrejp (guest, #47396) [Link]

In other words, you're saying "your communication is not welcome here" and "please remove the truck from my living room".

I understand. I apologize for the inconvenience.
Hm. No that's the wrong quote.
So long, and thanks for all the fish?
Lol.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 19, 2025 7:01 UTC (Wed) by intelfx (subscriber, #130118) [Link] (1 responses)

I see lots of text here, but unfortunately all of it is starkly content-free. Please try again.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 19, 2025 9:43 UTC (Wed) by andrejp (guest, #47396) [Link]

Which part did you find to be "content-free"? The problem? The "solutions"? Or the solution? I addressed all three.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 18, 2025 21:36 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (14 responses)

> Blu-ray index/playlist files referencing tens of M2TS and image files.

Such as the all-important list of the greatest titles stored in `/etc/shadow`. At some point, these kinds of features need to just go away as fundamentally insecure. As a compromise, you might be able to refer to files in the same directory and its subdirectories.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 19, 2025 10:16 UTC (Wed) by farnz (subscriber, #17727) [Link] (13 responses)

Note that the portal API already lets you open a directory, instead of a file - you can ask for the directory representing the root of the Bluray instead of the index file, and you will be granted access to that entire directory and all its subdirectories. This is plenty for a Bluray player, but problematic if you want access to /etc/shadow.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 19, 2025 11:33 UTC (Wed) by andrejp (guest, #47396) [Link] (11 responses)

Probably not entirely on topic, but I'm looking for my pet and I'd like to post a short "wanted" notice on the board.

Her name is Performance. If you find her please return her safely.
Unfortunately I can't offer any financial reward to the finder, but I'll let the finder keep her as compensation.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 19, 2025 12:01 UTC (Wed) by farnz (subscriber, #17727) [Link] (10 responses)

How, exactly, does asking the system to bind mount a directory chosen by the user into the mount namespace your process is using, hurt performance?

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 19, 2025 12:05 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

> How, exactly, does asking the system to bind mount a directory chosen by the user into the mount namespace your process is using, hurt performance?

An extra layer of indirection can solve all manner of problems, except the problem of too many layers of indirection.

Cheers,
Wol

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 19, 2025 12:09 UTC (Wed) by farnz (subscriber, #17727) [Link]

Except that this isn't a layer of indirection, as implemented in the Linux kernel - it causes the mount point (the user's chosen directory or file) to directly point to the right place in the underlying filesystem structures. You pay a bigger price when the kernel does UID/GID permissions checks on open.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 19, 2025 13:53 UTC (Wed) by andrejp (guest, #47396) [Link] (7 responses)

Oh, so you found her already? Good for you, she's yours to keep :)
This particular kitty though only wants /etc/hostname to play with in the sandbox, root(rw) -> root(r-) (you don't want the kitty to mess the toy up, safe-to-play sandbox right?).
Bind mount /etc?

Linux bind mounts

Posted Mar 19, 2025 13:58 UTC (Wed) by farnz (subscriber, #17727) [Link] (6 responses)

You can bind-mount files as well as directories, under Linux, and have the bind mount reduce permissions as compared to the original pointer to the file. So if you genuinely need read access to /etc/hostname, you can bind-mount that into the sandbox as read only, getting you read access but not write.

That said, if reading /etc/hostname is something your program does often enough for performance of that read to matter, you've got bigger concerns than sandboxing - why are you rereading a value that rarely changes, instead of caching it after first read and invalidating the cache when you get told it's changed?

Linux bind mounts

Posted Mar 19, 2025 14:24 UTC (Wed) by andrejp (guest, #47396) [Link] (1 responses)

> You can bind-mount files as well as directories, under Linux

Really? Well that's new lol. Lemme check.

# cd /tmp
# touch sfile; mkdir sdir
# mount --bind sfile sbox
mount: /tmp/sbox: mount system call failed: Not a directory.
Hm. It does say "Not a dir". Perhaps I'm not doing it right?
# mount --bind sfile sbox/sfile
mount: sbox/sfile: mount point does not exist.
Hm. Perhaps the file must exist before?
# touch sbox/sfile
# mount --bind sfile sbox/sfile
#
Yup. Indeed.
Tnx, I just learned something new :)

Linux bind mounts

Posted Mar 19, 2025 14:40 UTC (Wed) by andrejp (guest, #47396) [Link]

(^^ new for me, it has probably been around for a while)

Linux bind mounts

Posted Mar 19, 2025 14:33 UTC (Wed) by andrejp (guest, #47396) [Link] (3 responses)

> That said, if reading /etc/hostname is something your program does often enough for performance of that read to matter,

No I just made up a trivial test for demonstration purposes. I still wouldn't use a pack/snap for other reasons (have you tried bind mounting a couple of 1000s of files, then ran 'mount' to list them on the host side? that's one of the objections)

But hey, like I said - you find it, you keep it. Though I'm not sure if the kitty would stick around after say 10k bind-mounted files, skittish as she is :)

Linux bind mounts

Posted Mar 19, 2025 14:49 UTC (Wed) by farnz (subscriber, #17727) [Link] (2 responses)

Why would you bind-mount 1,000s of files? That's not something that Flatpak normally does (I have several running at the moment, with open files, and only a few bind-mounted files); when you tell the portal that you're finished with a file, the sandbox automatically unmounts the bind-mounted file so that you no longer have access to it.

The only time you'd ever bind-mount 1,000s of files in a Flatpak world is if you've had the user open thousands of files individually, and then not released them - but again, if this hurts performance, why are you keeping thousands of files open?

Linux bind mounts

Posted Mar 19, 2025 15:49 UTC (Wed) by andrejp (guest, #47396) [Link] (1 responses)

Right. And who would ever need more than 640k lol...

No the point is that there probably is a perf impact once the number goes up, and considering how all these distros seem to like these packs it's not inconceivable that the number does go up. 'mount | wc -l' currently shows *59* on this system - enough that some "work-around" is required if you just want to see the actual disk mounts (read: usefulness). The second point is that bind-mount really isn't the right spot for what MAC does already and (much more) cleanly. The third is that since these app packs are composed by 3rd parties I wouldn't necessarily trust them to do it right, and with potentially not much insight (without digging out source/build files) into how it's actually put together. The fourth I've already pointed out, which is that even if the admin is diligent and updates are applied regularly, the packs might for one reason or another skip updating these dependencies. The fifth I've also pointed out, which is the duplicity of versions of these packs. An old pack might have vulnerable binaries which might conceivably be available as a vector, say by LD_PRELOADing some libs from old/other packs; not that I know of one atm, but still. The sixth is, again, waste of resources by keeping multiple copies; disk is cheap, sure, but I'd prefer not having to constantly up-size partitions. #7 I like a *single* tool on the system to install sw, not mixing apples and oranges; dunno 'bout you but I don't fancy a mixed deb/rpm/snap/flat/whatever system with overlapping namespaces; besides, consider that these packs are a supposed "solution" to the problem of non-unified sw management - devs don't like deb or rpm or don't want to provide both, so they provide a... third... and fourth... and fifth... type, 'coz that's so much "better" and "solves" the problem of too many different pkg managers... right.. so even just listing all the installed software.. umm.. you get the idea. Anyway, #8 taking all of the above in consideration, there are very few salient selling points to these packs; "more secure" certainly isn't one of them - simply unpacking a tgz in /opt/app and providing some standard way of sandboxing ("chroot", except not chroot) would probably be just as good as any app pack out there, if not better, for the simple reason that it'd be standard, inspectable, verifiable and not dependent on the 3rd party to do it right while at the same time keeping various other interfaces clean (mount, df etc)

Linux bind mounts

Posted Mar 19, 2025 16:04 UTC (Wed) by farnz (subscriber, #17727) [Link]

There's no reason why Flatpak couldn't use MAC instead in future - it doesn't, because of the mess that Linux MAC schemes currently are (AppArmor/SELinux/others, some enabled, some force-disabled etc).

And if you genuinely have thousands of user-visible files opened, you need something, somewhere, to track which ones an application currently has access to - otherwise your complaint translates to "I don't like my applications being restricted from sending data they shouldn't have access to out to spy agencies".

Most of your complaints are just about one way to use Flatpaks - Flatpaks can be more secure, thanks to having a standard way of sandboxing and a standard way to transfer the application bundle around, along with isolation between different Flatpaks. And Flatpaks don't have to be "3rd party"; Fedora Flatpaks, for example, are just an automated repackaging of Fedora RPMs with a sandbox policy added to make them a Flatpak.

flatpacks falling flat, packing bugs, snaps snapping resources, both suck

Posted Mar 19, 2025 17:31 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Yep. But there's still a bit of missing functionality, if you open a file as a file, it doesn't allow you access to subdirectories. And I don't think it can be expressed with the current functionality? Although I haven't checked the Portal API in a while.

Angry people

Posted Mar 15, 2025 14:45 UTC (Sat) by tuna (guest, #44480) [Link]

It is pretty sad that people are so angry all the time. OBS could just have written up what was wrong with OBS in Fedora, but instead they just had to be all angry and then people here have to be angry. I think everything would be better if people could be a bit more chill and leave the anger to when it is really needed.


Copyright © 2025, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds