Fedora discusses Flatpak priorities
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.
Posted Feb 28, 2025 19:18 UTC (Fri)
by NightMonkey (subscriber, #23051)
[Link] (2 responses)
Posted Mar 1, 2025 19:49 UTC (Sat)
by nickodell (subscriber, #125165)
[Link]
Posted Mar 2, 2025 19:14 UTC (Sun)
by mattdm (subscriber, #18)
[Link]
Posted Mar 1, 2025 0:20 UTC (Sat)
by cen (subscriber, #170575)
[Link] (1 responses)
Posted Mar 2, 2025 9:04 UTC (Sun)
by LtWorf (subscriber, #124958)
[Link]
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.
Posted Mar 1, 2025 1:39 UTC (Sat)
by intelfx (subscriber, #130118)
[Link] (65 responses)
Posted Mar 1, 2025 2:09 UTC (Sat)
by roc (subscriber, #30627)
[Link] (8 responses)
Posted Mar 1, 2025 2:54 UTC (Sat)
by bgilbert (subscriber, #4738)
[Link] (7 responses)
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.
Posted Mar 1, 2025 8:56 UTC (Sat)
by mjg59 (subscriber, #23239)
[Link] (4 responses)
Posted Mar 2, 2025 2:35 UTC (Sun)
by bgilbert (subscriber, #4738)
[Link] (3 responses)
Posted Mar 2, 2025 12:38 UTC (Sun)
by khim (subscriber, #9252)
[Link] (2 responses)
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.
Posted Mar 2, 2025 13:05 UTC (Sun)
by bluca (subscriber, #118303)
[Link]
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
Posted Mar 2, 2025 13:34 UTC (Sun)
by pizza (subscriber, #46)
[Link]
*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
Posted Mar 1, 2025 19:03 UTC (Sat)
by Mook (subscriber, #71173)
[Link] (1 responses)
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.
Posted Mar 2, 2025 2:54 UTC (Sun)
by bgilbert (subscriber, #4738)
[Link]
Posted Mar 1, 2025 7:22 UTC (Sat)
by epa (subscriber, #39769)
[Link] (54 responses)
Posted Mar 1, 2025 8:31 UTC (Sat)
by cjwatson (subscriber, #7322)
[Link] (24 responses)
Posted Mar 1, 2025 9:37 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (19 responses)
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,
Posted Mar 1, 2025 22:12 UTC (Sat)
by dvdeug (guest, #10998)
[Link] (18 responses)
> 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.
Posted Mar 2, 2025 0:23 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (14 responses)
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,
Posted Mar 2, 2025 2:15 UTC (Sun)
by bgilbert (subscriber, #4738)
[Link] (1 responses)
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.
Posted Mar 2, 2025 9:08 UTC (Sun)
by pabs (subscriber, #43278)
[Link]
Posted Mar 2, 2025 7:04 UTC (Sun)
by dvdeug (guest, #10998)
[Link] (11 responses)
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
a) Disclaiming warranty or limiting liability differently from the
b) Requiring preservation of specified reasonable legal notices or
c) Prohibiting misrepresentation of the origin of that material, or
d) Limiting the use for publicity purposes of names of licensors or
e) Declining to grant rights under trademark law for use of some
f) Requiring indemnification of licensors and authors of that
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.
Posted Mar 2, 2025 10:20 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (10 responses)
> 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
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,
Posted Mar 2, 2025 14:36 UTC (Sun)
by PastyAndroid (subscriber, #168019)
[Link] (9 responses)
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.
Posted Mar 2, 2025 19:57 UTC (Sun)
by NAR (subscriber, #1313)
[Link] (5 responses)
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?
Posted Mar 2, 2025 20:30 UTC (Sun)
by roc (subscriber, #30627)
[Link] (4 responses)
"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.
Posted Mar 3, 2025 13:35 UTC (Mon)
by PastyAndroid (subscriber, #168019)
[Link] (3 responses)
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
Posted Mar 3, 2025 13:45 UTC (Mon)
by pizza (subscriber, #46)
[Link]
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.
Posted Mar 3, 2025 14:46 UTC (Mon)
by NAR (subscriber, #1313)
[Link] (1 responses)
Posted Mar 3, 2025 16:23 UTC (Mon)
by PastyAndroid (subscriber, #168019)
[Link]
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.
Posted Mar 2, 2025 21:51 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (2 responses)
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,
Posted Mar 3, 2025 13:26 UTC (Mon)
by PastyAndroid (subscriber, #168019)
[Link] (1 responses)
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.
Posted Mar 3, 2025 17:43 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
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,
Posted Mar 2, 2025 20:55 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
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.)
Posted Mar 2, 2025 23:37 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
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.
Posted Mar 3, 2025 9:44 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Mar 1, 2025 9:51 UTC (Sat)
by epa (subscriber, #39769)
[Link]
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.
Posted Mar 3, 2025 15:29 UTC (Mon)
by amarao (guest, #87073)
[Link] (2 responses)
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.
Posted Mar 27, 2025 9:02 UTC (Thu)
by sammythesnake (guest, #17693)
[Link] (1 responses)
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...
Posted Mar 27, 2025 11:56 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
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,
Posted Mar 1, 2025 13:49 UTC (Sat)
by draco (subscriber, #1792)
[Link] (8 responses)
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.
Posted Mar 1, 2025 15:12 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (7 responses)
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,
Posted Mar 1, 2025 17:20 UTC (Sat)
by jkingweb (subscriber, #113039)
[Link] (6 responses)
Is it actually modified? My impression is that it's just configured differently.
Posted Mar 1, 2025 17:37 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (5 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 ...
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,
Posted Mar 1, 2025 21:11 UTC (Sat)
by pizza (subscriber, #46)
[Link] (3 responses)
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.
Posted Mar 3, 2025 6:15 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
> 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.
Posted Mar 3, 2025 13:55 UTC (Mon)
by pizza (subscriber, #46)
[Link] (1 responses)
...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.
Posted Mar 3, 2025 18:59 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link]
I agree. But I have never heard of the latter happening. I think you just made it up.
Posted Mar 1, 2025 23:36 UTC (Sat)
by jkingweb (subscriber, #113039)
[Link]
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.
Posted Mar 2, 2025 9:03 UTC (Sun)
by pabs (subscriber, #43278)
[Link] (19 responses)
Posted Mar 2, 2025 10:23 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (18 responses)
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,
Posted Mar 2, 2025 13:25 UTC (Sun)
by pizza (subscriber, #46)
[Link] (14 responses)
This cuts both ways. You don't want your stuff "used" in certain ways, don't release it under F/OSS licenses.
Posted Mar 2, 2025 13:42 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (4 responses)
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,
Posted Mar 2, 2025 23:06 UTC (Sun)
by interalia (subscriber, #26615)
[Link] (3 responses)
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.
Posted Mar 3, 2025 9:41 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (2 responses)
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,
Posted Mar 3, 2025 9:50 UTC (Mon)
by rschroev (subscriber, #4164)
[Link]
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.
Posted Mar 3, 2025 10:20 UTC (Mon)
by interalia (subscriber, #26615)
[Link]
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.
Posted Mar 2, 2025 20:59 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (8 responses)
The fact that this is inconvenient to you is, as far as the law is concerned, entirely your problem to solve.
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.
Posted Mar 3, 2025 9:52 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
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,
Posted Mar 4, 2025 12:45 UTC (Tue)
by ballombe (subscriber, #9523)
[Link] (5 responses)
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.
Posted Mar 4, 2025 13:36 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (4 responses)
> 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,
Posted Mar 4, 2025 14:48 UTC (Tue)
by draco (subscriber, #1792)
[Link] (1 responses)
Wol, please cite the exact license text (and context/location in the license)
The only things I find in GPLv3, GPLv2, & LGPLv2.1 are:
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)
Posted Mar 4, 2025 19:44 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
> 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,
Posted Mar 4, 2025 18:10 UTC (Tue)
by ballombe (subscriber, #9523)
[Link] (1 responses)
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.
Posted Mar 4, 2025 19:50 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
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,
Posted Mar 3, 2025 2:15 UTC (Mon)
by pabs (subscriber, #43278)
[Link] (2 responses)
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.
Posted Mar 5, 2025 12:58 UTC (Wed)
by epa (subscriber, #39769)
[Link] (1 responses)
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.
Posted Mar 5, 2025 13:23 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
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,
Posted Mar 1, 2025 23:45 UTC (Sat)
by Phantom_Hoover (subscriber, #167627)
[Link]
Posted Mar 1, 2025 2:43 UTC (Sat)
by SFalken (subscriber, #175710)
[Link] (2 responses)
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.
Posted Mar 1, 2025 16:45 UTC (Sat)
by jzb (editor, #7867)
[Link] (1 responses)
Posted Mar 1, 2025 18:18 UTC (Sat)
by SFalken (subscriber, #175710)
[Link]
Posted Mar 1, 2025 9:48 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (2 responses)
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,
Posted Mar 1, 2025 17:34 UTC (Sat)
by mcatanzaro (subscriber, #93033)
[Link] (1 responses)
Posted Mar 1, 2025 17:56 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
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,
Posted Mar 1, 2025 17:01 UTC (Sat)
by easwarh (subscriber, #131924)
[Link] (5 responses)
Posted Mar 1, 2025 17:49 UTC (Sat)
by hunger (subscriber, #36242)
[Link]
Posted Mar 1, 2025 17:51 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
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,
Posted Mar 1, 2025 19:34 UTC (Sat)
by lunaryorn (subscriber, #111088)
[Link]
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.
Posted Mar 3, 2025 3:24 UTC (Mon)
by notriddle (subscriber, #130608)
[Link] (1 responses)
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.)
Posted Mar 3, 2025 17:50 UTC (Mon)
by smcv (subscriber, #53363)
[Link]
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.
Posted Mar 2, 2025 13:14 UTC (Sun)
by zdzichu (subscriber, #17118)
[Link] (2 responses)
Posted Mar 2, 2025 15:45 UTC (Sun)
by ballombe (subscriber, #9523)
[Link]
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.
Posted Mar 3, 2025 7:30 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (11 responses)
As usual, we have two potential "packagers":
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)
Posted Mar 3, 2025 7:31 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
> 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.
Posted Mar 4, 2025 0:59 UTC (Tue)
by AdamW (subscriber, #48457)
[Link] (9 responses)
1. Fedora RPM
The Fedora flatpak is built from the Fedora RPM.
Posted Mar 4, 2025 4:09 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (8 responses)
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.
Posted Mar 4, 2025 6:56 UTC (Tue)
by zdzichu (subscriber, #17118)
[Link] (7 responses)
Posted Mar 4, 2025 8:19 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (6 responses)
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.
Posted Mar 4, 2025 9:43 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (5 responses)
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.
Posted Mar 4, 2025 21:23 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (4 responses)
> 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.
Posted Mar 4, 2025 21:39 UTC (Tue)
by pizza (subscriber, #46)
[Link] (1 responses)
IIUC Fedora flatpaks are always built _from_ the RPMs.
Posted Mar 5, 2025 0:24 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
> 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.
Posted Mar 5, 2025 8:23 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (1 responses)
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.
Posted Mar 5, 2025 14:31 UTC (Wed)
by madscientist (subscriber, #16861)
[Link]
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).
Posted Mar 15, 2025 1:41 UTC (Sat)
by andrejp (guest, #47396)
[Link] (38 responses)
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?
Posted Mar 15, 2025 3:19 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (37 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.
> 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.
Posted Mar 18, 2025 2:33 UTC (Tue)
by andrejp (guest, #47396)
[Link] (36 responses)
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.
Posted Mar 18, 2025 2:46 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (35 responses)
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
Posted Mar 18, 2025 2:59 UTC (Tue)
by andrejp (guest, #47396)
[Link]
Puhlese...
You should probably ask yourself that, considering your generic "answer".
Posted Mar 18, 2025 3:35 UTC (Tue)
by andrejp (guest, #47396)
[Link]
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.
Posted Mar 18, 2025 8:53 UTC (Tue)
by mbunkus (subscriber, #87248)
[Link] (32 responses)
Posted Mar 18, 2025 9:29 UTC (Tue)
by intelfx (subscriber, #130118)
[Link] (16 responses)
How would you solve this?
Posted Mar 18, 2025 9:35 UTC (Tue)
by mbunkus (subscriber, #87248)
[Link] (15 responses)
Posted Mar 18, 2025 9:40 UTC (Tue)
by intelfx (subscriber, #130118)
[Link] (14 responses)
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?
Posted Mar 18, 2025 9:58 UTC (Tue)
by mbunkus (subscriber, #87248)
[Link] (1 responses)
1. The "files referencing other files" issue I've already mentioned
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.
Posted Mar 18, 2025 10:18 UTC (Tue)
by intelfx (subscriber, #130118)
[Link]
> 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?
Posted Mar 18, 2025 9:58 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (11 responses)
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,
Posted Mar 18, 2025 10:06 UTC (Tue)
by intelfx (subscriber, #130118)
[Link] (10 responses)
It might be an important problem, but I'm almost certain it's not a fundamental one.
Posted Mar 19, 2025 6:26 UTC (Wed)
by andrejp (guest, #47396)
[Link] (9 responses)
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.
Posted Mar 19, 2025 6:42 UTC (Wed)
by zdzichu (subscriber, #17118)
[Link] (6 responses)
Posted Mar 19, 2025 9:42 UTC (Wed)
by andrejp (guest, #47396)
[Link] (5 responses)
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.
Posted Mar 19, 2025 9:58 UTC (Wed)
by andrejp (guest, #47396)
[Link] (4 responses)
I mean... "GRUB tries to do too much, and most of those things are a mistake, he said."
Posted Mar 19, 2025 13:07 UTC (Wed)
by daroc (editor, #160859)
[Link] (3 responses)
Please stop this thread of conversion here, and be less vitriolic in your future comments.
Posted Mar 21, 2025 14:52 UTC (Fri)
by andrejp (guest, #47396)
[Link] (2 responses)
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".
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.
Posted Mar 21, 2025 15:15 UTC (Fri)
by andrejp (guest, #47396)
[Link]
I understand. I apologize for the inconvenience.
Posted Mar 19, 2025 7:01 UTC (Wed)
by intelfx (subscriber, #130118)
[Link] (1 responses)
Posted Mar 19, 2025 9:43 UTC (Wed)
by andrejp (guest, #47396)
[Link]
Posted Mar 18, 2025 21:36 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (14 responses)
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.
Posted Mar 19, 2025 10:16 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (13 responses)
Posted Mar 19, 2025 11:33 UTC (Wed)
by andrejp (guest, #47396)
[Link] (11 responses)
Her name is Performance. If you find her please return her safely.
Posted Mar 19, 2025 12:01 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (10 responses)
Posted Mar 19, 2025 12:05 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (1 responses)
An extra layer of indirection can solve all manner of problems, except the problem of too many layers of indirection.
Cheers,
Posted Mar 19, 2025 12:09 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
Posted Mar 19, 2025 13:53 UTC (Wed)
by andrejp (guest, #47396)
[Link] (7 responses)
Posted Mar 19, 2025 13:58 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (6 responses)
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?
Posted Mar 19, 2025 14:24 UTC (Wed)
by andrejp (guest, #47396)
[Link] (1 responses)
Really? Well that's new lol. Lemme check.
# cd /tmp
Posted Mar 19, 2025 14:40 UTC (Wed)
by andrejp (guest, #47396)
[Link]
Posted Mar 19, 2025 14:33 UTC (Wed)
by andrejp (guest, #47396)
[Link] (3 responses)
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 :)
Posted Mar 19, 2025 14:49 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (2 responses)
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?
Posted Mar 19, 2025 15:49 UTC (Wed)
by andrejp (guest, #47396)
[Link] (1 responses)
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)
Posted Mar 19, 2025 16:04 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
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.
Posted Mar 19, 2025 17:31 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Mar 15, 2025 14:45 UTC (Sat)
by tuna (guest, #44480)
[Link]
Regression links?
Regression links?
Regression links?
case by case
case by case
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
This is not a good trend
This is not a good trend
This is not a good trend
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
> 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
This is not a good trend
This is not a good trend
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
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
This is not a good trend
This is not a good trend
This is not a good trend
Wol
This is not a good trend
This is not a good trend
Wol
This is not a good trend
This is not a good trend
This is not a good trend
add to a covered work, you may (if authorized by the copyright holders of
that material) supplement the terms of this License with terms:
terms of sections 15 and 16 of this License; or
author attributions in that material or in the Appropriate Legal
Notices displayed by works containing it; or
requiring that modified versions of such material be marked in
reasonable ways as different from the original version; or
authors of the material; or
trade names, trademarks, or service marks; or
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.
This is not a good trend
> requiring that modified versions of such material be marked in
> reasonable ways as different from the original version; or
Wol
This is not a good trend
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
This is not a good trend
This is not a good trend
This is not a good trend
This is not a good trend
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
This is not a good trend
This is not a good trend
Wol
This is not a good trend
This is not a good trend
Wol
This is not a good trend
This is not a good trend
This is not a good trend
Wol
This is not a good trend
This is not a good trend
This is not a good trend
This is not a good trend
Wol
This is not a good trend
This is not a good trend
Wol
This is not a good trend
This is not a good trend
Wol
This is not a good trend
This is not a good trend
This is not a good trend
This is not a good trend
This is not a good trend
No trademarks in upstream source
No trademarks in upstream source
Wol
No trademarks in upstream source
No trademarks in upstream source
Wol
No trademarks in upstream source
No trademarks in upstream source
Wol
caps
No trademarks in upstream source
No trademarks in upstream source
No trademarks in upstream source
No trademarks in upstream source
Wol
No trademarks in upstream source
No trademarks in upstream source
Wol
No trademarks in upstream source
* 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.
No trademarks in upstream source
Wol
No trademarks in upstream source
No trademarks in upstream source
Wol
No trademarks in upstream source
No trademarks in upstream source
No trademarks in upstream source
Wol
This is not a good trend
Please respect project branding guidelines
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
Please respect project branding guidelines
Highlighting the trademark issue ...
Wol
Highlighting the trademark issue ...
Highlighting the trademark issue ...
Wol
Converging and diverging paths
Converging and diverging paths
Converging and diverging paths
Wol
Converging and diverging paths
Converging and diverging paths
Converging and diverging paths
What exactly is wrong with Fedora's OBS?
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?
What exactly is wrong with Fedora's OBS?
2 packagers but 3 packages?
- upstream
- the Linux distribution in use
QA and trust
2 packagers but 3 packages?
2. Fedora flatpak
3. Flathub flatpak
2 packagers but 3 packages?
2 packagers but 3 packages?
2 packagers but 3 packages?
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:
2 packagers but 3 packages?
2 packagers but 3 packages?
2 packagers but 3 packages?
2 packagers but 3 packages?
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)
2 packagers but 3 packages?
2 packagers but 3 packages?
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
> Flatpacks provide a way to limit the access to the system via portals, sandboxing all other ways of access:
Turing test fail lol.
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
And honestly - the IQ test was real easy.
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
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)
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
Wol
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
No, wait, that wasn't my comment. Hm.
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
Stop now
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
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
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
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
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
Unfortunately I can't offer any financial reward to the finder, but I'll let the finder keep her as compensation.
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
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
Wol
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
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
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?
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.
Linux bind mounts
Linux bind mounts
# 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
Linux bind mounts
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.
Linux bind mounts
Linux bind mounts
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).
Linux bind mounts
flatpacks falling flat, packing bugs, snaps snapping resources, both suck
Angry people