Fedora Amicably Resolves Legal Threat From OBS Studio Over Downstream Flatpak

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..."

Re: Flatpak yuck

[RazorSharp]

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.

Flatpak is less crappy of the crappy universals

[skogs]

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:

[brad0]

But still crappy.

I love Linux

[DrXym]

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:

[thegarbz]

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:

[Entrope]

This being Slashdot, the reference to xkcd [xkcd.com] is obligatory.

Re:

[DrXym]

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:

[OngelooflijkHaribo]

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

flatpak and snap are missing many packages

[linuxguy]

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

Legal threat gets attention

[Bruce66423]

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.

[Mirnotoriety]

Flatpak: a solution in search of a problem.

Re:

[StormReaver]

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.

"23 people clicked "Like" on the original Issue"

[fleeped]

I thought that approach to "news" was reserved for the worst news sites, but I guess a decade-long downward trajectory can only lead in that direction.

Isn't removing it from Fedora best?

[drinkypoo]

Much of the point of flatpak is that it's easy to get one. Why include it at all?

On broken Fedora packages

[gr8_phk]

A few years ago I had a problem with a broken official Fedora package in the main repository. It was weird considering the have a 3D printing SIG and it was a very common app for 3D printing. Like the official package *did not work*. IIRC I complained and got nowhere. I then traced it to an issue with a dependency, found a workaround, posted that to IRC or something and a few days later the package got fixed using the workaround. The whole thing made me realize that some of their maintainers are either not