Workstation Working Group discussed this change proposal today. Here is my summary. TL;DR: our opinion was unfavorable because users rarely like client-side filters.
In the era of Netflix and Amazon Prime, this is a questionable argument. My point here is that FESCo is unlikely to be able to determine âcrippledâ for the heterogeneous audiences we aim to serve given such subjective definitions/derivations, and I see much room for confusion with this proposal: personally, when I read your initial post about the compromise, I had in mind âmanipulationsâ/âmodificationsâ: when legal requirements force us to make any manipulation/change to the original/source (âcripple the sourceâ compared to its original, or dependencies â user experience is no longer aimed to be equal), then ⌠â so I donât say that is my opinion, but this is how I read your post, others might read it the same way (?), and in any case, there is much space for confusion, misunderstanding and subsequently complaints in the way you subsequently elaborated the suggested compromise
Has anyone asked legal about that?
I know there was previous discussion with legal about turning on flathub as a default source in an install. But Iâm not currently aware of a discussion involving turning on flathub as a source in our compose environment and shipping images with flathub sourced flatpaksâŚ
Even without asking legal about that⌠I would have concerns..because doing that we would then be acting as a distributor of code in our images not built in our build system..and I have concerns about.
2 Likes
You didnât even try!
2 Likes
Does that mean Atomic is expected to be the mainstream version over current Workstation and Server? Iâve heard that loosely, but havenât heard of a date or actual plan until now.
Define mainstream.
What makes you think that?
The applications will work just fine, they will just not be able to play some media files that are in patent-encumbered formats. That doesnât constitute âcrippledâ to me.
We thought more of something like the OBS case, where H.264 support is basically essential (some streaming providers have a hard requirement on that format, as I understand it), so the only thing we can do is patch it to use openh264 - which is, by all standards, a subpar implementation.
1 Like
As long as Flathub continues to not be enabled by default (but requires user action to enable access), I guess this could be a reasonable path forward. Note that FESCo may need to add a note (somewhere) to avoid boiling the frog to ensure that any future proposal to enable Flathub by default will be rejected to continue to achieve Fedoraâs Principals (especially about Freedom).
I would also like to propose that the wording of enabling third party repositories include not only a comment on proprietary software, but also an additional comment about software for which the user may not have the authority (or license) to actually use (this would include especially a/v codecs, which are the more likely ones that would be âcrippledâ[0] in Fedora, but there are likely other cases), and they are responsible for ensuring they are in compliance with their jurisdictions laws and regulations before use (yes, individuals should know that, butâŚ).
[0] The term âcrippledâ is considered derogatory. An alternative might be âreduced functionalityâ.
we offer an OBS rpm. Are you saying that I canât stream to anywhere using the Fedora provided OBS rpm? And if that is true, why does that rpm exist.
I did a quick install of the fedora rpm and setup youtube live stream⌠it works well enough for me to see the the recording.
I feel like I need to do a weekly FPL podcast just using the Fedora built OBS now.
Is that crippled? From my pov⌠probably not. For someone doing real time gaming overlays.. maybe.
1 Like
More-presented: I go to https://fedoraproject.org/ and see Workstation and KDE traditionals presented first.
I feel if Atomic is presented first (first-listed for a new user might = mainstream?), more users will use it, and lead to less-eyes for QA on Workstation/traditional. Stuff like more Flatpak use vs RPM. And if the dev focus is whatâs used primarily, it seems like Atomic would get that.
I may be remembering wrong but I recall the RPM OBS Studio can use the openh264 codec from Cisco whereas the Fedora Flatpak couldnât.
If that is true.. thatâs best described as self-inflicted limitation in how we choose to compose flatpaks.. because there is a mechanism available that makes this possibleâŚbut our packaging policy explicitly disallows pulling in functional binaries post-install.
But we should move that discussion over to a different thread, as its something we have to grapple with without getting into the complexity of flathub interactions.
No, this is only a limitation of the Flatpak. The RPM package works fine. Also, you can install additional media codecs from third-party repos to make OBS even more featureful. No such option exists for the Flatpak.
1 Like
No. We have no plans to ship preinstalled apps from Flathub. I had expected that we would use Fedora Flatpaks for everything preinstalled.
Looks like everybody has a different idea of what âcrippledâ means. If we can ship Decibels, Showtime, and Firefox (yes, I forgot Firefox) as Fedora Flatpaks, then itâs no problem. But I think most users would interpret âcrippledâ to apply to apps that play videos.
Thinking ahead, where will the apps come from if we achieve our Fedora 2028 goals? Fedora Workstation and Fedora KDE Plasma Desktop editions are both atomic (Silverblue/Kinoite). dnf is gone. rpm-ostree is gone. If you block Fedora editions from ever enabling Flathub, weâll have no source of apps other than Fedora Flatpaks, which are highly unpopular with users, are actively hurting Fedoraâs reputation, and notably have only one active maintainer for all of the apps. Do you really want to bet the entire Fedora project on the success of Fedora Flatpaks? You also eliminate any incentive for Fedora to engage with Flathub to improve its packaging practices. And this has nothing to do with software freedom, because Flathub already has a foss subset, which is surely what Fedora would want to enable.
Iâm especially curious to hear FESCo membersâ thoughts on this topic. Workstation Working Group has been discussing this on and off for about half a year now, and weâre not particularly close to finding an answer.
Are you aware of any jurisdictions where end users are not allowed to install multimedia codecs? That seems like a bizarre thing to worry about.
2 Likes
Iâm pretty sure the intent of flatpaks as a distribution technology has a solution for application plugins
Whether or not our implementation of flatpaks is compatible with extensions is another question. If ours isnât.. it needs to be.
That would also require rpmfusion to have a pipeline for building a flatpak runtime extension that contains media codecs. Iâm pretty sure they have neither the resources nor interest in doing that.
I donât know why weâd assume rpmfusion would provide that pipeline. I wouldnât even assume that such addon registry of flatpak extensions would be rpm based at all. All that is needed that Fedora would need to provide SDK/runtime to build/run against and the appropriate registry to publish to.
In the US, you may install, but have no authority to actually use (unless you get a license (and there is no known to me way to get a license as an individual (and I tried))) the h.264 (maybe soon resolved) or h.265 codecs (other examples exist in the codec world). Reminding individuals that the content they might download or attempt to use may be proprietary (or licensed) when enabling 3rd party repos (including flathub) just makes good sense.
1 Like
I donât think thatâs a real problem. Letâs move on.
2 Likes
openSUSE Aeon has already shown a way forward. Auto installing Firefox from Flathub on first boot.
2 Likes