On Monday, 06 June 2022 at 23:58, Kevin Kofler via devel wrote: > Dominik 'Rathann' Mierzejewski wrote: > > > On Sunday, 05 June 2022 at 19:15, Kevin Kofler via devel wrote: > >> It is common knowledge that Fedora is/was effectively useless for > >> anything remotely related to multimedia without RPM Fusion packages. > > > > That's entirely false. There are many multimedia-related uses which are > > covered solely by the package set shipped in Fedora repositories. For > > example, a DLNA server on my home LAN works just fine with minidlna and > > ffmpeg-free. You can use ffmpeg-free to manipulate videos encoded with > > royalty-free codecs. Most videos on YouTube are also available in either > > VP9 or AV1 and with Opus audio. > > That is why I wrote "is/was": There is now indeed limited support for > multimedia in stock Fedora, so the (outdated) expectation that nothing works > at all without RPM Fusion has now become overly pessimistic. Still, it is > the common expectation and everyone has learned to deal with it for years, > so I do not see why changing that was worth doing at all. Not everyone. New users will not be aware of RPM Fusion, so I see much value in having things mostly work out-of-the-box. We just have to agree to disagree here. > (And the fact that almost all YouTube videos actually work without any > H.264, AAC, or EME DRM support at all just proves that it was not necessary > to add support for decoding H.264 and AAC to Fedora proper nor to allow > browsers to easily download the Widevine blob.) Not allowing users to make that decision would be taking away their freedom. Firefox doesn't download the blobs without asking the user first. > > Unless you're a lawyer, the above statement is false. Red Hat legal says > > the modified FDK-AAC is free and GPL-compatible, so there's no violation > > of licenses here. > > Red Hat Legal's interpretation is in direct contradiction to the FSF's > attestation that the FDK-AAC license is not compatible with the GPL. And yet, that's the only interpretation that matters to Fedora. Please stop arguing over facts. > Red Hat > Legal's claim that a license can be GPL-compatible or not depending on > whether the code happens to implement some patents or not sounds highly > dubious to me, and that view does not seem to be shared by the FSF nor by > FFmpeg upstream, and it is their license (drafted by the FSF and applied by > FFmpeg upstream to their code) that we must comply with. Again, this is irrelevant. If you have a problem with Red Hat's interpretation, I suggest you consult a lawyer. > It is particularly bizarre that Fedora is willing to put themselves at risk > of a lawsuit over divergent license interpretations as a result of an > effort, ironically, to ship something compliant with US law. This is only your opinion and it's irrelevant from legal perspective. > >> All these compromises: > >> * violate the core Freedom principle of Fedora, and > > > > How? > > Because the copy of OpenH264 shipped through that Cisco repository is not > Free Software? (All the binaries covered by the patent license impose the > non-Free restrictions of that patent license, see > http://www.openh264.org/BINARY_LICENSE.txt .) Fedora package is BSD-licensed. If you think that's incorrect, open a bug against openh264 package and block FE-Legal. > Because we replaced an LGPL- licensed AAC implementation with one that > Debian considers non-Free? Again, what Debian considers non-Free is irrelevant from Fedora legal perspective. Unless you can point to a statement signed by a lawyer, this is only an opinion and carries little weight. > Because we ship a linked-together mix of code that FFmpeg upstream > considers non- redistributable (as a mix of GPL and GPL-incompatible > code)? They're not lawyers so this is irrelevant. > Because we allow browsers to download proprietary DRM blobs? Again, not allowing users to do that would be taking away their freedom. Firefox doesn't download the blobs without asking the user first. > Plus, the compromises also violate the Features principle because Fedora > deliberately ships incomplete implementations of H.264 and AAC. You could say that about any software that we ship that's missing features. FESCo decided it's better to include an incomplete or inferior implementation that we can legally distribute than no implementation at all. I don't necessarily agree with that decision (in case of AAC), but they're the community-elected body empowered to make such decisions. Any community member can register themselves as candidate and run for a FESCo seat in the next election. > >> * lead to a degraded user experience compared to just installing fully > >> functional multimedia codecs under Free copyright licenses from RPM > >> Fusion. > > > > Which Fedora cannot legally ship. > > But RPM Fusion can, so why not just let RPM Fusion do it? Because having FFmpeg in Fedora lets us include a whole class of software that we couldn't distribute previously. Because Fedora has orders of magnitude more resources than RPM Fusion both in terms of infrastructure and package maintainers, so moving maintenance of some packages to Fedora lets us tap into those resources and lessen the burden on RPM Fusion. > Shipping the incomplete implementations just makes it harder to use the > complete ones (because the FFmpeg-native implementations of H.264 and AAC > (and libx264 for H.264 encoding) are not binary-compatible with OpenH264 and > FDK-AAC that Fedora is pushing), for no practical benefit whatsoever because > everyone can just install the codecs from RPM Fusion. You're assuming everyone knows about RPM Fusion and that's not a given. Also, the claim that ffmpeg-free is not binary-compatible with RPM Fusion ffmpeg is false. > >> In some cases, concerns raised by RPM Fusion developers have been > >> deliberately ignored (e.g., in the AAC case). > > > > It was not ignored. The case was referred to FESCo where it was > > discussed and a decision was made to go ahead with the limited decoder. > > That is exactly my point: The concerns were ignored by FESCo. You keep repeating that, but in fact it's not true. You're simply unable to accept the fact that they didn't make the decision you wanted and move on. [...] > I would also like to point out that the FFmpeg bump to FFmpeg 5 in RPM > Fusion happened after the upstream Fedora 36 feature freeze and hence IMHO > too late. But RPM Fusion's hand was forced there. I don't think anybody is arguing otherwise. > You are right that there was some discussion of the ffmpeg-free idea back in > 2021, but the feedback was negative (so I would have honestly expected this I'd say there was no feedback. My personal archive shows only my responses. > horrible idea to end there, as in all previous cases over the years where a > naïve maintainer had a similar idea, but ended up listening to the strong I've been mulling over this idea for years, but I never had the time to implement it. I'm actually glad Andreas and Neal managed to do it. > reasons not to do that) and there again, the concerns were ignored, and the > plan worked on with no further public communication. The irritating > impression I get is that that was deliberately done so that concerns could > no longer be raised until it was too late. Concerns were not ignored. You seem to be convinced that doing anything else than what you're suggesting is equal to ignoring your concerns. It's not. I'm not happy about the missing H.265 codec and about the subpar implementation of the H.264 codec in the -free package, but the world is not all H.264 and H.265 use is niche. There are numerous benefits to having ffmpeg in Fedora directly and they outweigh the downsides in my opinion. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
