Fedora Amicably Resolves Legal Threat From OBS Studio Over Downstream Flatpak (gamingonlinux.com) 44
When it comes to application packaging, earlier this month the site Its FOSS complained that Fedora Flatpaks "are often unmaintained or broken, leading to a poor experience for users who aren't usually aware they're using them." And this apparently created friction with OBS Studio, the free/open-source screencasting and streaming app.
"We are now considering the Fedora Flatpaks distribution of OBS Studio a hostile fork," OBS Studio lead Joel Bethke posted in on GitLab's page for Fedora Flatpaks. They said they were making "a formal request to remove all of our branding, including but not limited to, our name, our logo, any additional IP belonging to the OBS Project, from your distribution. Failure to comply may result in further legal action taken...." (Issues with Fedora's packaging led "to users complaining upstream thinking they are being served the official package..." Bethke said in his original Issue. "I would also like some sort of explanation on why someone thought it was a good idea to take a Flatpak that was working perfectly fine, break it, and publish it at a higher priority to our official builds.")
23 people clicked "Like" on the original Issue — but threatening legal action only happened after Bethke felt Fedora was unresponsive, according to It's FOSS: In a comment on a video by Brodi Robertson (check pinned comment), Joel shared that folks from Fedora were not taking this issue seriously, with one of them even resorting to name-calling by labeling the OBS Studio devs as being "terrible maintainers". Since then, a major step has been taken by Neal Gompa, a well-known Fedora contributor and member of the Fedora Engineering Steering Committee (FESCo). He has opened a new issue to remove Fedora's OBS Studio flatpak from the registry as soon as possible.
But by Tuesday Bethke posted in a new comment on GitLab announcing that "a very good conversation" with the Flatpak SIG and Fedora Project Leader seemed to have cleared the tension. "We discussed the issues, how we got here, and what next steps are... [T]he OBS Project is no longer requesting a removal of IP or rebrand of the OBS Studio application provided by Fedora Flatpaks." To the issue of not knowing where to report bugs for the downstream package, "We had some very good discussion on how this might be accomplished in the medium-long term, but don't consider it a blocker at this point." As for other issues with Fedora's Flatpak for OBS Studio, "The discussion was positive and they are actively working to resolve..."
And similar sentiments were echoed on Fedora's own issue tracker. "We had a good conversation today, and there is a hopeful path forward that does not require the OBS Project distancing itself from Fedora Flatpaks..."
"We are now considering the Fedora Flatpaks distribution of OBS Studio a hostile fork," OBS Studio lead Joel Bethke posted in on GitLab's page for Fedora Flatpaks. They said they were making "a formal request to remove all of our branding, including but not limited to, our name, our logo, any additional IP belonging to the OBS Project, from your distribution. Failure to comply may result in further legal action taken...." (Issues with Fedora's packaging led "to users complaining upstream thinking they are being served the official package..." Bethke said in his original Issue. "I would also like some sort of explanation on why someone thought it was a good idea to take a Flatpak that was working perfectly fine, break it, and publish it at a higher priority to our official builds.")
23 people clicked "Like" on the original Issue — but threatening legal action only happened after Bethke felt Fedora was unresponsive, according to It's FOSS: In a comment on a video by Brodi Robertson (check pinned comment), Joel shared that folks from Fedora were not taking this issue seriously, with one of them even resorting to name-calling by labeling the OBS Studio devs as being "terrible maintainers". Since then, a major step has been taken by Neal Gompa, a well-known Fedora contributor and member of the Fedora Engineering Steering Committee (FESCo). He has opened a new issue to remove Fedora's OBS Studio flatpak from the registry as soon as possible.
But by Tuesday Bethke posted in a new comment on GitLab announcing that "a very good conversation" with the Flatpak SIG and Fedora Project Leader seemed to have cleared the tension. "We discussed the issues, how we got here, and what next steps are... [T]he OBS Project is no longer requesting a removal of IP or rebrand of the OBS Studio application provided by Fedora Flatpaks." To the issue of not knowing where to report bugs for the downstream package, "We had some very good discussion on how this might be accomplished in the medium-long term, but don't consider it a blocker at this point." As for other issues with Fedora's Flatpak for OBS Studio, "The discussion was positive and they are actively working to resolve..."
And similar sentiments were echoed on Fedora's own issue tracker. "We had a good conversation today, and there is a hopeful path forward that does not require the OBS Project distancing itself from Fedora Flatpaks..."
Re: Flatpak yuck (Score:3)
I think the main disadvantage that AppImage has is that it does not have an 800lb gorilla trying to push it on everyone.
Canonical and Red Hat had no reason to create Snap and Flatpak other than their desire to control as much of the Linux ecosystem as possible.
Re: (Score:2)
I thought Canonical wanted to give you a good reason to upgrade your PC while annoyingly blocking access to most of the files you might want.
At least I assume that's their goal since those are the two things Snap packages are excellent at. Yeah I'm being a snarky dickhead. I can see what they're trying to do and why with snap, and it's not a bad idea, but something is seriously up with the implementation. It's glacially slow and only allows easy access to the most sensitive files in ~ but not the rest in /b
Re: (Score:2)
Indeed, flatpak, snap, appimage and others are all bad solutions to a problem that shouldn't exist is semver was respected. But of those, appimage is definitely the least bad.
Flatpak is less crappy of the crappy universals (Score:3)
Flatpak is the better of the universal unknown malware distribution systems, but it still isn't a normal simple package.
The science is generally solved in building rpm and .deb packages. They have a very nice 'Unoffiical Linux Builds' section on github with instructions for source build.
Re: (Score:1)
I love Linux (Score:4, Insightful)
Person A - "Not being able to ship a single package binary that works on every dist sucks. I wish we could unify Linux distributions under a single package manager but that will never happen for a variety of reasons".
Person B - "I know, but maybe we can containerize applications so they're bundled with their dependencies and become dist agnostic. Then potentially we could release a single package that runs on all of them. We could ship complex tools, applications, games that run everywhere and eliminate this headache once and for all".
Distributions X, Y, and Z - "That's a brilliant idea, here is our mutually incompatible implementation that only we support. Oh and we'll completely half ass it so these products are never completely trustworthy or up to date."
Re: (Score:2)
That's not Linux, that's the entire open source movement. You can actually generalise the entire topic with a recusrive math problem.
A: I have an idea.
B: I have an idea of how to do A differently.
C: I have an idea of how to do B differently.
D: We need a system to easily switch between A, B, and C.
E: I have an idea of how to implement D differently.
F: I have an idea of how to implement E differently.
That's the issue with the "you don't like it just fork" world of open source. Every fork creates... well a for
Re: (Score:3)
This being Slashdot, the reference to xkcd [xkcd.com] is obligatory.
Re: (Score:2)
I was tempted to post that, but just in case someone didn't get the reference I spelled it out explicitly.
Re: (Score:2)
I don't think it's the "open source movement" per se. It is dists, particularly commercial ones like Ubuntu and Red Hat negating the benefit of a unified, containerized distribution format by splitting. Whether that's because they want the whole cake to themselves, or misguided belief that the other would fall into line, neither thing is going to happen.
So a chance for Linux to support a single distributable binary format for applications, games etc. falls on its ass. It would make sense for dists to get be
Re: (Score:2)
It is dists, particularly commercial ones like Ubuntu and Red Hat negating the benefit of a unified, containerized distribution format by splitting.
Since when is the concept of coming up with a unique / better idea limited to commercial distros only? The only reason why this is reflected specifically in commercial distributions is because commercial distributions are uniquely in the best position to benefit from simplifying package delivery. This is the same reason why many adopted systemd, it wasn't about you, it was about simplifying distribution maintained by having a package take the place of a shitton of scripts that needed to be kept up to date.
T
Re: (Score:2)
I could go on. The point is that unification will *ALWAYS* upset someone since someone always thinks something else is better. That goes for binary distribution (which you don't seem to care about) to everything else, including things you do.
You could go on but you've utterly missed the point. I do care about binary distribution and the purpose of having a single supported format across distributions is incredibly obvious. This has nothing to do with open source and everything to do with some very dumb and counterproductive decisions at the dist level which hamper the entire ecosystem.
Re: (Score:3)
I honestly don't understand why people expect software to be able to be shipped as binary and simply work on a variety of different operating systems, many of which not even really sharing a common ancestry that are all managed by different groups just because they share the same kernel. It's as silly as expecting Android binaries to just run on Gentoo. Or Hurd things to run on MacOS because they were both ultimately derived from the Mach kernel.
So many people seem to think this reality is strange, and that
Re: (Score:3)
Containers are a thing and have been for some time. And even Steam on Linux uses containers so games more or less run on top of any dist. The point is that this stuff is doable. Assuming heads are knocked together. A single format supported by every dist would have a massive benefit to the entire ecosystem - it would motivate projects to maintain their own packaging that could be downstreamed to dists, and would encourage commercial software & games to Linux. Because supporting ephemeral apts, yums etc.
Re: (Score:2)
Containers are a thing and have been for some time. And even Steam on Linux uses containers so games more or less run on top of any dist.
Like I said, they ship half an operating system with it, and on top of that, they don't run without glibc, good luck ever getting that to run. A container effectively contains an operating system inside though.
The point is that this stuff is doable. Assuming heads are knocked together.
It's doable if one ignore why an operating system even exists in the first place and just ship one's own with all the software and it has very little to do with what operating system it runs on then. At that level things become so abstract you can probably get those steam games to run on Windows as we
Re: (Score:2)
I honestly don't understand the point you are making except to be contrarian.
Containers exist to fulfill a purpose - to isolate and a built application / container to run over any dist. You're trying to argue nuh-uh don't need them, when they exist for that need. They exist in cloud because software runs in isolation with replication and failover. They exist in Steam because game devs don't want to build, test and maintain the same game for multiple dists. They exist in applications because imposing a time
Re: (Score:2)
I honestly don't understand the point you are making except to be contrarian.
There's nothing contrarian about it. It's the reality that these systems have followed. You're saying that they should all change how they current operate, or should've done so in the past. I'm explaining why they operate the way they do. My view reflects what is currently happening, and thus the mainstream, not the alternative.
You're trying to argue nuh-uh don't need them,
I never did such a thing. I simply explained why they aren't universally adopted and that by the fact that they essentially bundle half an operating system inside, people don't like
Re: (Score:2)
And how successful is all that compared to instead installing software the standard way from the distributions repositories?
Fantastically well. The reason Steam for Linux exists or why there are so many games for it is thanks to containerization. It's also why containerization has so many uses other places and is desirable. And Linux as a whole benefits. Honestly your answers are incredibly contrarian.
Re: (Score:2)
I think you severely overestimate the popularity of Steam on Linux. For one, it doesn't work, as said, without Glibc, which Android and Alpine, which probably are the two most popular systems in terms of number of individual installs don't have.
Re: (Score:2)
Why? Linux based operating systems are basically identical to
Re: (Score:2)
Why? Linux based operating systems are basically identical to each other, with only minor differences.
They're often completely unrelated things that have about as much in common with each other as MacOS and FreeBSD or even less. The only thing they have in common is sharing Linux. Fedora and Alpine really are nothing alike and whatever they share outside of Linux, they also share with FreeBSD, as in rough POSIX compliance. It's very silly to expect the same binaries to work on both. Of course, one of the absolutely biggest Linux-based systems, Android, isn't even really POSIX Compliant. It only “sort
Re: (Score:3)
Person C:
Why don't you just ship a tarball with all the dependencies inside it and your rpaths set up correctly?
Person A and B: *crickets*
Re: (Score:2)
You mean the simple and obvious solution? How absurd. If you don't needless over-complicate things, what will people think?
Re: I love Linux (Score:2)
You're not wrong, but flatpak is the least worst of these. It actually does handle some dependencies. For instance, mesa, openh264, and ffmpeg... I have multiple versions of each of these installed by flatpak for various programs which depend on them, and they update independently.
flatpak and snap are missing many packages (Score:4, Interesting)
I have been trying to use the Linux native package managers, but end up using homebrew even on Linux.
Example:
$ snap search lazydocker
No matching snaps for "lazydocker"
$ flatpak search lazydocker
No matches found
$ brew search lazydocker
==> Formulae
lazydocker
Re: (Score:2)
I have been trying to use the Linux native package managers, but end up using homebrew even on Linux.
You know what, there is nothing wrong with that. We used to build the whole world in /usr/local, remember those days? ./configure; make; make install? Sourceforge was my brew.
When was the last time you all ran
It's like that guilty pleasure when you realized the OSS versions you're getting on your work laptop running Cygwin are newer than your fedora system at home. When you realize you just installed the latest version of Git for windows, right from the official site, but your server's version is ancient.
Li
Legal threat gets attention (Score:2)
This is the correct use of a legal threat: to get the person being an idiot to wake up and talk about a situation. It's a shame it came to this, and I have to hope it won't be repeated, but let's be grateful that we have a legal system that sometimes can achieve what it should do. Yes, too many lawyers are scum, but unfortunately we need lawyers.
Flatpak: a solution in search of a problem. (Score:1)
Re: (Score:1)
Appimage is the same. I was willing to give them a try since their press was such that they addressed a real problem. However, that changed for me when I tried to use a new Appimage of Kdenlive. It complained that my glibcxx and cxxabi were out of date.
So much for THE ENTIRE REASON for Appimage to exist. It is just another incompatible package format, and it needs to die. The same is true of Flatpak and Snaps. They don't serve the very reason for which they exist.
Re: (Score:2)
1000x
The right way to solve this problem is static builds and/or ship the dependancies with correctly set rpaths or scripts to preload the libraries in the local directories etc.
You can achieve just as much portability this way without needing the end user to have in place some elaborate schemes for mounting disk images, creating logical network infrastructure and trying to manage it all. You solve 99% of the problems one on the build side rather than doing over and over again at runtime. Will it work for
"23 people clicked "Like" on the original Issue" (Score:1)
Isn't removing it from Fedora best? (Score:2)
Much of the point of flatpak is that it's easy to get one. Why include it at all?
On broken Fedora packages (Score:2)
Sigh (Score:2)
Over the last ~30 years I've watched package management on Linux arrive, solve problems, become defacto and simple, then slowly destroy itself with a variety of nonsense, not least snap, flatpak, et al.
I'm now back to an absolute crapshoot every time I want to install a single, standard piece of software that's been around for ages. Do I install the distro package? Does it even exist? Do I install the upstream? Does that exist? Do I have to jump through hoops to install yet-more "package managers" / "c
Re: (Score:2)
Ubuntu has taken a nosedive in recent years, but don't generalize it to Linux distros. It just means it may be time for you to choose a different distro.
Re: (Score:2)
I have 7 different distros in my house.
It's universally a culture problem with newer software where they can't be bothered to package it for... e.g. 7 different distros, so they do the old "create a new standard that does what you want, now you have 8 standards that all do the same thing to deal with" XKCD problem.
More software is becoming "just snap", no "just docker", no "clone our github then run this command that actually requires you to install entire virtual machine / container management software th
Re: (Score:2)
The way I see it, it's the job of distributions to package the software. Otherwise, why call them "distributions"?
AppImage and Flatpak are there to make it easier for users to install (newer versions of) software not included in their distribution.
That being said, it shifts the burden of packaging to the software developers, who aren't usually experts in that field. And it gives ideas to distributions who now want to just ship a minimal system and rely on Flatpaks for software.
I have no experience with snap
Re: (Score:2)
HA is just one example of why I have "another" distribution and why I just dedicated a machine to it (their OS, their problem) rather than try to install it myself.
Such a nightmare.
Who the hell decided that YAML inside a container is a way to manage a machine?
I have already a FlatPack Issue on Mint (Score:2)
I've had the same problems with Snaps... (Score:3)
From the software provider's website, "Hey! Never use the snap. They're usually poorly maintained and we can't support them. Download the .deb package directly from our website if you want an experience that actually works as we've intended." And they were right. I had, without thinking about it, downloaded and installed a snap and got poor performance. All things considered, ease-of-use versus efficiency, performance, and maintainers/infrastructure being what they are, the snap / flatpak / appimage ecosystem is still pretty grizzly. OBS was well within their right to want to pull the flatpak. And those complaining about my complaining can stop complaining and help make the situation better, because that's the only way they're going to win me over.
Avoid lock in (Score:2)