Dominik 'Rathann' Mierzejewski wrote: > 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. It depends on where the new users are coming from. And if they really find Fedora but not RPM Fusion, then we need to do something about that. I guess getting errors on playing most multimedia files out of the box would actually help getting RPM Fusion known. It sure did in the past. >> 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. It does not matter that it asks the user. It still blatantly violates the rule that applications must not download executable code and execute it. (There are other offenders, e.g., the infamous HPLIP "plugin", but that does not make it any better.) Doing that bypasses the licensing policies of our repository in a pretty obvious way (by just shipping the proprietary blobs elsewhere). In addition, that download offer actively promotes proprietary software, which used to be a no go in Fedora, but now (very sadly) even Fedora itself has started doing that by shipping pointers to all sorts of proprietary stuff ranging from NVidia drivers from RPM Fusion (whereas ironically the software in RPM Fusion that follows our licensing policies is considered off limits due to patents) to all sorts of proprietary Flatpaks. (It shall also be pointed out that it is disputed whether the NVidia drivers can even be legally distributed at all, because they are under a proprietary, GPL- incompatible license and therefore arguably cannot be legally linked to the GPLv2-licensed Linux kernel. But basically nobody cares about that.) Furthermore, keep in mind that such a "Do you want to install foo? Yes/No" prompt drives most users to just blindly click "Yes" without even reading what it says, let alone thinking the implications through. That user behavior is well-known, and, e.g., the reason why Firefox no longer uses this type of prompt for insecure HTTPS sites. That makes the "Firefox doesn't download the blobs without asking the user first." argument pretty fallacious. I like the way QtWebEngine handles the DRM blobs: You *can* install them, but you have to manually unpack them to the directory given in the documentation, then QtWebEngine will pick them up. It will not download those proprietary blobs on its own. But this does not take away any freedom from the user because the blobs can be manually installed. They will just not be proactively offered; instead, the user gets an error and has to read the documentation and make their own decision. >> > 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. Different lawyers will have different opinions. A legal opinion is not a fact. The only way to get anything close to undisputable is to get a legal precedent from an appeal court or higher, and even that only in a particular jurisdiction, and only if the jurisdiction has a concept of case law at all to begin with. (As far as I know, for the jurisdiction to which Red Hat is bound, the concept exists, but requires a decision from an appeal court, a state supreme court, or the federal US Supreme Court.) As long as nobody actually litigates this in court, we just have to accept that there is no final position that cannot be argued over. >> 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. I do not see how this is irrelevant, considering that the upstream copyright holders (and not Red Hat Legal) are the ones entitled to sue Fedora / Red Hat for violating the license. So if you do not want to get sued, surely their opinion matters. >> 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. I do not see how this is an opinion at all. Doing something that the copyright holders consider illegal definitely puts you at risk of a lawsuit, that is a fact. Sure, it does not say anything about the outcome, that is a different matter. But it is also a fact that a court will not necessarily agree with your own lawyers, otherwise there would be no need for lawsuits at all. >> >> 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. It is licensed under a combination of the Free BSD copyright license and the non-Free "AVC/H.264 Patent Portfolio License". >> 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. Debian is one of the leading authorities on software freeness. Yes, they are (usually) not lawyers, and that is a weakness of their statements, but neither they nor I have ever claimed otherwise. The point is, a license that Debian considers non-Free looks suspicious to me, and I am not alone in that. >> 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. They are the copyright holders, so it is not, see above. >> 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. See my answer further above. >> 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. Just to be outvoted 1:8 against any common sense. Been there, done that. >> 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. So far this effort has only caused extra work for RPM Fusion and not solved any of their problems. >> 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. See my first answer. > Also, the claim that ffmpeg-free is not binary-compatible with RPM > Fusion ffmpeg is false. That is not something I have claimed (except for the special case of applications like Chromium and derivatives that hardcode codec lists at compile time). What the paragraph you were replying to *actually* states is that applications or libraries made to *directly* (*not* through FFmpeg) use OpenH264 and/or FDK-AAC (e.g., the GStreamer plugins) cannot be made to use the FFmpeg native codecs and/or libx264 instead just by swapping out the codec libraries, because the native OpenH264 and FDK-AAC APIs and ABIs are very different from the FFmpeg ones. In the case of GStreamer, do the FFmpeg codecs have higher or lower priority than the OpenH264 and FDK-AAC ones? If lower, then we have to actually go and uninstall the OpenH264 and FDK-AAC plugins to get GStreamer to use the FFmpeg ones. If higher, then will GStreamer prefer using OpenH264 and FDK- AAC through ffmpeg-free rather than directly now? >> >> 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. The concerns have not been addressed, hence, ignored. >> 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. So how was this acceptable in any way then? ffmpeg-free should have either matched the version present in RPM Fusion for F36 or imported to Rawhide for F37+ only. What has happened was a blatant violation of feature freezes, by pretending RPM Fusion does not exist at all. >> 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. A link to the Fedora devel list thread was posted earlier in this thread: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/YPXQTK27622JHYOACVAWD4JR4BHNXZ2D/ You can see that, e.g., I have pointed out the hardcoded codec lists issue: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/N3U3AABUAMIIBOHW2DIBO476CWPXI3LP/ >> 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. And I still think it was a mistake to do it, especially without buy-in from RPM Fusion. >> 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. The other RPM Fusion developers, those that were not asked, seem to all disagree with you on that. Kevin Kofler _______________________________________________ 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
