OpenH264 induces headaches for Fedora [LWN.net]

By Joe Brockmeier
June 2, 2025

Software patents and workarounds for them are, once again, causing headaches for open-source projects and users. This time around, Fedora users have been vulnerable to a serious flaw in the OpenH264 library for months—not for want of a fix, but because of the Rube Goldberg machine methodology of distributing the library to Fedora users. The software is open source under a two-clause BSD license; the RPMs are built and signed by Fedora, but the final product is distributed by Cisco, so the company can pick up the tab for license fees. Unfortunately, a breakdown in the process of handing RPMs to Cisco for distribution has left Fedora users vulnerable, and inaction on Fedora's part has left users unaware that they are at risk.

OpenH264 background

The Advanced Video Coding (AVC) video codec, often referred to as H.264, is a video-compression standard meant to provide reasonable video quality at lower bitrates than previous standards. It is widely used for video encoding and playback, not only for watching cat videos online but also for video conferencing. Various patents that apply to the standard were held by MPEG LA, which was later acquired by the Via Licensing Alliance. One public presentation from 2013 indicates that the going rate to acquire a license to appease the patent holders was $0.20 per unit (after 100,000 units) or $25 million a year, whichever was cheaper.

In 2013, Cisco announced the OpenH264 project, which not only provides source and binaries that implement the H.264 standard, Cisco also pays the licensing royalties through an arrangement it made with MPEG LA. However, there's a catch: a project or user has to use the binaries that are distributed by Cisco to take advantage of its deal with the license holders.

Projects cannot simply take the source and ship it with their software—at least, they cannot if they want to be certain that the patent holders won't come looking for a payout. If, say, Fedora actually hosts the repository with OpenH264 packages for its users, then it—or its users—will be responsible for the licensing fees. Since Fedora is not an independent entity, Red Hat would be responsible for the fees as the sponsor of Fedora. As it happens, Red Hat has (quite reasonably) been unwilling to roll the dice and ship OpenH264 in the hopes that it would escape the gaze of the license holders. It has been equally reluctant (also reasonably) to open its wallet for a fee that may well run in the millions of dollars each year.

In 2014, LWN covered some of the early problems that Fedora had with inclusion of OpenH264, and noted that Christian Schaller was working with Cisco on a way to build OpenH264 on Fedora's infrastructure for its users. Ultimately, as described on Fedora's OpenH264 page, Fedora was able to include the fedora-cisco-openh264 repository metadata, starting with Fedora 24, that would point users to Cisco-hosted packages built by Fedora. That included packages to use H.264 with GStreamer and Fedora's Firefox package. The repository was enabled by default with the Fedora 33 release.

Given the age of the standard, one might hope that the patents that apply to it would have expired or be close to expiring—but it's not that simple. As Michael Catanzaro explained in a 2023 discussion about OpenH264, it is unlikely that a current implementation of the standard will definitely be clear of patent encumbrances:

Unfortunately H.264 is extremely complicated because there are so many revisions to the specification, so even once the patents covering the original specification have expired, figuring out whether a particular decoder is legal or not still requires substantial technical expertise in addition to legal expertise. And that can change if the decoder implements any newer features in the future, which makes for an extremely challenging problem. That is to say, do not expect other H.264 decoders to be allowed in Fedora even when all patents covering the original spec have expired.

Thus, despite the fact that it is more than 22 years old, H.264 remains a patent headache, and Fedora is still having to perform a delicate dance with Cisco to avoid having liability for patent fees. Unfortunately, it takes two to tango—or, in this case, release OpenH264 packages.

Delays

CVE-2025-27091 was issued on February 20. It describes a vulnerability in the decoding function of OpenH264 that could allow a remote attacker to trigger a heap overflow in the library. If an attacker can entice a user into playing a video that exploits the vulnerability, it would be theoretically possible for the attacker to perform arbitrary commands on the victim's system. The CVE was given a severity rating of 8.6 out of ten. The upstream project released OpenH264 2.6.0, with a quiet fix for the vulnerability, on February 12.

Patrik Polakovič opened a ticket to update OpenH264 the same day that 2.6.0 was released. Unfortunately, there was a mismatch in the shared-library version. The Makefile for OpenH264 specified SHAREDLIB_MAJORVERSION=8, but the meson.build for the project was set to major_version = '7'. That stalled things on the Fedora side while trying to sort out the right library version—and before it was understood that there was a security vulnerability at play. Catanzaro bumped the ticket with a comment about the security advisory on February 24.

Following that, several tickets were opened to track progress on properly building the packages with the security fix; those were ultimately consolidated in a single ticket on February 27. The first set of packages was built the same day, but Catanzaro asked to hold off on sending them to Cisco for distribution while a 2.5.1 version release with the fix was created to avoid bumping the ABI version from 7 to 8. But it was not possible for Fedora to create its own version due to the patent issues.

Wim Taymans updated the ticket on March 12 to say that there were completed builds for Fedora 40, 41, and 42, as well as EPEL 10. The builds are visible in Koji, Fedora's build system, but they are not available for download. If users try to access the builds using Koji's download links, they will be directed to the Non-distributable-rpms page that explains that Fedora cannot distribute the RPMs for "various legal reasons".

After some discussion, Polakovič reported that he had tried to send the packages to Cisco as email attachments but received an error that "Red Hat Mail does not allow you to use this type of file as it violates Google policy for executables and archives". He asked later if Catanzaro knew how to get the RPMs to Cisco:

These licensing issues are the source of so much frustration. Ordinarily we'd just get the build and that's it. It's insane how many hoops we have to go through.

More discussion and complaints about the legal silliness followed. No one seemed to know how to achieve the task of alerting Cisco to the builds and ensuring that only Cisco employees could download the builds. In early April, Neal Gompa offered the contact information he used when communicating with Cisco from the openSUSE project, which followed Fedora's lead in distributing OpenH264. On April 21, Polakovič said that he had still not received a reply from Cisco and was not sure how to proceed.

Remove OpenH264?

More time passed and on May 8, Catanzaro said that it might be time to remove OpenH264 from Fedora "due to the high risk level and inability to release updates". Kevin Fenzi replied that he finally had contact with Cisco, "so I am hoping that this will be unblocked soon". Another update from Polakovič on May 13—three months after OpenH264 2.6.0 was released with a fix for the vulnerability—indicated that Cisco had provided Fedora with a link for uploading and that the packages were successfully submitted.

On May 28, Fenzi updated the ticket status to affirm that Fedora was still waiting on Cisco to update its repository.

The problem has also been raised and discussed on the fedora-devel mailing list. Chris Adams first asked at the end of April how to remove or replace the openh264 package, due to the vulnerability, without removing other packages. In late May, Jonathan Schleifer thanked Adams for raising the topic: "I had no idea Fedora would let something so serious be unfixed for so long". Stephen Smoogen responded that this was a predictable problem:

There is no incentive for the "partners" to fix these sorts of problems and there will always be a lot of incentive to put it off another day for whatever internal fires are going on. At this point, I think we should acknowledge that we as a project made a mistake and figure out how to fix this for our users.

Catanzaro said that Fedora was between a rock and a hard place. Without OpenH264 Fedora would have to "point to RPM Fusion and hope [users] can figure out how to get what they need from there". He later said that Fedora would need to remove OpenH264 if it cannot fix security issues in a timely manner. "If we knew that it would take this long to update, we would probably have done that already."

Current status

To date, it is unclear when updated packages will be available to Fedora users. The Fedora project has no viable options here. If it does not ship an H.264 implementation, its users are left to fend for themselves, which leads to complaints about complexity and a lack of parity with other Linux distributions or operating systems. It does not have the luxury of thumbing its nose at the patent cartel, nor a benefactor that wants to appease the cartel with bags of cash so that Fedora could supply OpenH264 to users directly. The Cisco arrangement, on paper, would seem to be the best option.

In practice, though, it has left Fedora unable to push an update to protect its users. But what is within Fedora's control is how it communicates with its users. It is mystifying that Fedora has not issued an advisory to warn its users that they are exposed to a security vulnerability. There may not be an easy fix for Fedora to provide, but it could advise of workarounds or at least ensure that users are aware that they are vulnerable and allow them to seek their own remedies.

This situation demonstrates, once again, the fragility of depending on a corporate benefactor providing a service. Just because a team at a company is well-staffed and offering to lend a hand today does not guarantee that will be the case tomorrow or the day after. Management can have a change of heart, priorities will shift, people may get busy or leave for other jobs, institutional knowledge can be lost, and then things fall through the cracks.

This story has been replayed in open-source projects enough times to be familiar to all but the newest folks in the community. We've all seen this movie before, and it does not improve with repeated viewings or remakes.

to post comments

How does this work, exactly?

Posted Jun 2, 2025 16:24 UTC (Mon) by intelfx (subscriber, #130118) [Link] (12 responses)

I'm clearly not an IP lawyer, and, while I understand that neither are the vast majority of LWN readers (and even if some are, they are not *my* lawyers), perhaps someone could shed an informative/educational light onto this batch of questions:

Where, exactly, is the line that must not be crossed to remain free of software patent responsibilities? And what, exactly, happens when that line is crossed by different entities?

1. If Fedora distributes H.264 decoders, it is "on the hook" for the patents that cover those decoders.
2. If Fedora "points users to RPMFusion", it is presumably not "on the hook". Then who is? Nobody? RPMFusion? Or the users (with the assumption that a single user is too small of a target for the MPEG LA to go after, but with the understanding that the user is still breaking the law technically)?
3. Why does RPMFusion still exist, and why it was not sued into oblivion already? Is it hosted in a jurisdiction that does not recognize software patents?
3. What if Fedora adds RPMFusion to the default list of repositories?
4. What if Fedora adds RPMFusion to the default list of repositories, and sets up the package priorities such that the decoder gets installed on first update?
5. What if Fedora adds a dialog that asks the user to click a button to install the decoder from RPMFusion?

How does this work, exactly?

Posted Jun 2, 2025 16:31 UTC (Mon) by daroc (editor, #160859) [Link]

Those are all excellent questions that I, too, do not have enough law-school education to answer correctly.

I can take a vague stab at some of them, maybe, by pointing out that the exact boundaries of what is and is not patent infringement is likely to be decided by a judge (or de facto decided by the lawyers who evaluate legal risk, at least). So while there may not be much of a _technical_ difference between Fedora letting uses add RPM Fusion repositories manually versus having a button to do it, it still seems likely to me that there's enough of a _practical_ difference that it could sway a judge.

The fact that these things are decided by judges, who are human, using their best judgement also means that there may not even be a hard-and-fast rule for what is or is not acceptable until someone has a precedent-setting lawsuit about it.

How does this work, exactly?

Posted Jun 2, 2025 16:35 UTC (Mon) by jzb (editor, #7867) [Link]

This won't answer all your questions, but LWN covered RPM Fusion in 2007. It is presumably hosted outside the U.S.

I would imagine it's also not a particularly enticing target: it could be shut down, but the patent holders wouldn't be able to get any real money out of it. They probably see more benefit from this small set of users being able to interact with fee-paying services, etc., than trying to wring license fees out of that small set of users.

Red Hat, and now IBM, have far deeper pockets and would make a much more attractive target. Pointing to RPM Fusion in the default list of repos could be seen as contributory infringement. Not a worthwhile risk to take, IMO.

How does this work, exactly?

Posted Jun 2, 2025 20:04 UTC (Mon) by JulianGro (subscriber, #170093) [Link] (2 responses)

As someone who looked into this for his own organization: The problem is that nobody knows how things work exactly.

Our organization is in Germany, which pretty clearly shouldn't see any of the h264 patents as valid. However, other countries might still drag our organization in front of their courts. Other countries might also hold individual contributors instead of the organization accountable. Then there are extradition agreements.
If it was just me, I would take the risk and break the patents. But we have at least one contributor who is worried about knowingly breaking laws in other countries, which have extradition agreement.

Alternatively, you can get a license from the relevant consortium; Not only does that not guarantee that you aren't still infringing on patents, but it is also an 80-page document full of stuff that doesn't make any sense. I cannot sign something like that in good faith. And realistically nobody can sign that in good faith.
Not to mention, you need multiple licenses, because usually you use a proprietary audio codec like AAC together with h264. By signing a contract with then, you also imply that their patents are legitimate, which I would also never want to do if I can help it.

So in our case, we just accept that we won't support proprietary codecs. It's a pretty big annoyance in our case, but there is just no way to do it right.

How does this work, exactly?

Posted Jun 3, 2025 7:38 UTC (Tue) by taladar (subscriber, #68407) [Link] (1 responses)

At least not using proprietary codecs at all has the side-benefit of hurting the entire concept of proprietary codecs.

How does this work, exactly?

Posted Jun 3, 2025 21:46 UTC (Tue) by ocrete (subscriber, #107180) [Link]

Just to be clear, H.264 and AAC are not proprietary in any sense. They've been created by UN standards organisation (ISO) for which all the countries in the world can participate. The annoying thing is that they're created to maximize patent royalties to participating companies.

How does this work, exactly?

Posted Jun 2, 2025 21:39 UTC (Mon) by mcatanzaro (subscriber, #93033) [Link] (3 responses)

> Where, exactly, is the line that must not be crossed to remain free of software patent responsibilities?

Don't make it work. If users are happy, you have crossed the line.

I'm not even sure whether pointing is allowed. Notably the official documentation https://fedoraproject.org/wiki/PackageKit_Items_Not_Found... takes great pains to not tell you where to find what you are looking for.

How does this work, exactly?

Posted Jun 4, 2025 10:23 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (1 responses)

Is the 404 for "Third party repositories" intended? Probably not but it does count as not telling you where to find what you are looking for.

How does this work, exactly?

Posted Jun 4, 2025 13:40 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link]

Surely not intended. :)

Punt to Flathub?

Posted Jun 9, 2025 23:20 UTC (Mon) by DemiMarie (subscriber, #164188) [Link]

Has punting and pointing users to Flathub been considered? In this scenario, Fedora would not ship apps requiring codecs. When the user searched for them in GNOME Software or similar, they would find the Flathub versions, which would work fine.

How does this work, exactly?

Posted Jun 2, 2025 21:40 UTC (Mon) by Wol (subscriber, #4433) [Link] (2 responses)

> Where, exactly, is the line that must not be crossed to remain free of software patent responsibilities? And what, exactly, happens when that line is crossed by different entities?

Make sure you don't go any further than running the software?

By pretty much EVERY statute or common law in pretty much EVERY jurisdiction, "pure" software is not "eligible subject matter". There are plenty of patent lawyers who would beg to differ, but equally for every such patent lawyer there 10, 20 sleight-of-hand tricks to confuse hardware and software, and not one argument that actually works as applied to pure software.

Proof? Well, could you get a patent on your high school exam paper? You'd get laughed out of court!

Go back 40, 50 years, pretty much ALL programs would start their life on paper looking like a high school exam paper. Not eligible subject matter. They were then mathematically transformed into computer files - again not eligibile subject matter. Next they were typically fed through a compiler - not eligible subject matter. You get the gist - mathematical transformation is not eligible subject matter!

And finally, at the end of it all, they get fed through an ALU. An Arithmetic Logic Unit - the brains of what we now call a CPU. That's logic, that's maths, that's NOT ELIGIBLE SUBJECT MATTER.

Finally we come to print our results on a printer. Using a printer to print (aka "do what it was designed to do") is not eligible subject matter! And that printout could be a hard copy of the source or binary of our program - we've come full circle, and there is NO ELIGIBLE SUBJECT MATTER ANYWHERE.

Likewise, using a Visual Display Unit to display the program's output is not eligible subject matter.

Or making a motor motor. Etc etc.

Of course, there's plenty of eligible subject matter inside the printer. Or the VDU. Or the motor. But that's technology, not maths. Software is pure maths all the way round the circle, and maths is not accepted as eligible subject matter.

Personally, I divide this world (collectively called philosophy) into three distinct areas. Mathematics is the building of internally self-consistent models. Software lives entirely in this world. Science consists comparing those models with the way the real world behaves, in an attempt to understand it. And technology consists of manipulating the real world so that it mimics the model you want it to, not the model it would choose if you left it to its own devices.

Patents belong very firmly in the technology camp.

The problem is the classic one of people mis-classifying stuff. Computer Science is a complete mis-nomer - it should be the study of how computers physically work, and nothing to do with the logic behind them. Physics is classed as Science, when in reality most of it is either Mathematics (Theoretical Physics) or Technology (Experimental Physics). A large chunk of what I thoroughly enjoyed studying as Chemistry is actually theoretical physics (atomic chemistry, the study of electron levels and chemical bonds).

In real life people are far too ready to define things as belonging on "their" side of the fence, rather than see that actually their "garden" contains several fences. Which sadly also means they miss a lot of other people working in the same garden because they've misclassified their fences.

Cheers,
Wol

How does this work, exactly?

Posted Jun 3, 2025 14:55 UTC (Tue) by jhoblitt (subscriber, #77733) [Link]

Sir, your obscuring the issues with facts...

The issue is a cartel must be paid. Logic is secondary.

How does this work, exactly?

Posted Jun 4, 2025 9:09 UTC (Wed) by anselm (subscriber, #2796) [Link]

Software is pure maths all the way round the circle, and maths is not accepted as eligible subject matter.

That is as may be. But if you look at, e.g., Dennis Ritchie's famous SUID patent, you will find that it takes considerable pains to explain what it does in terms of hardware, presumably in order to avoid the “software is maths” issue. Which is (a) typical of the genre, and (b) must have been enough to make the patent office happy, at least.

Debian status

Posted Jun 2, 2025 17:27 UTC (Mon) by ju3Ceemi (subscriber, #102464) [Link] (15 responses)

On my Debian:

6.51 [jack:~] apt-cache policy libx264-164
libx264-164:
Installed: 2:0.164.3108+git31e19f9-2+b1
Candidate: 2:0.164.3108+git31e19f9-2+b1
Version table:
*** 2:0.164.3108+git31e19f9-2+b1 500
500 https://deb.debian.org/debian trixie/main amd64 Packages

So the H264 codec is part on the main repository

How is Debian' situation different from Fedora's ?

Debian status

Posted Jun 2, 2025 17:40 UTC (Mon) by jzb (editor, #7867) [Link] (5 responses)

How is Debian' situation different from Fedora's ?

The obvious difference is that Fedora is sponsored by a company and it gets legal advice and direction from that company. If Red Hat/IBM's legal folks think something is at a certain level of risk, then Fedora is unlikely to do it/be allowed to do it. Debian is a community run project.

There is a discussion in this bug report that indicates there may have been a decision behind closed doors that the risk was tolerable for Debian. I can't find a *public* decision of this -- which doesn't mean it does not exist, it's possible it was announced somewhere but I have missed it.

Debian status

Posted Jun 2, 2025 19:02 UTC (Mon) by ballombe (subscriber, #9523) [Link] (4 responses)

Straight from the bug log: Debian patent policy is <https://www.debian.org/legal/patent>

Debian status

Posted Jun 2, 2025 19:46 UTC (Mon) by jzb (editor, #7867) [Link] (3 responses)

That does detail Debian's overall patent policy, but doesn't provide any info about the specific decision to package OpenH264. If anything, it seems to argue against doing so.

Debian status

Posted Jun 2, 2025 20:56 UTC (Mon) by ballombe (subscriber, #9523) [Link]

I do not think there have been any specific decision to package openH264, this is the whole point of the patent policy, which is basically: do not speak about patent.

Debian status

Posted Jun 2, 2025 23:45 UTC (Mon) by pabs (subscriber, #43278) [Link] (1 responses)

libx264-164 is not OpenH264, but libx264. The libopenh264-8 library is OpenH264 though.

Debian status

Posted Jun 3, 2025 6:20 UTC (Tue) by Gerardo (subscriber, #37539) [Link]

$ apt-cache search libopenh264
libopenh264-7 - OpenH264 Video Codec
libopenh264-dev - OpenH264 Video Codec - development files
libopenh264-cisco7 - OpenH264 Video Codec provided by Cisco Systems, Inc.
libopenh264-8 - OpenH264 Video Codec
libopenh264-cisco8 - OpenH264 Video Codec provided by Cisco Systems, Inc.

Debian status

Posted Jun 4, 2025 9:17 UTC (Wed) by anselm (subscriber, #2796) [Link] (7 responses)

How is Debian' situation different from Fedora's ?

Fedora belongs to Red Hat, which belongs to IBM, which is a big company with deep pockets. Leaving aside the issue of whether it is wise to sue IBM (think “The SCO Group”), people might try even so because there's potentially money to be made.

Debian, OTOH, doesn't belong to a big company and doesn't have that much money of its own, so suing Debian is likely to get you loads of bad PR and not a lot else.

Debian status

Posted Jun 4, 2025 10:33 UTC (Wed) by micka (subscriber, #38720) [Link] (6 responses)

So the solution would be to sever the link between fedora and red hat?

Debian status

Posted Jun 4, 2025 11:49 UTC (Wed) by pizza (subscriber, #46) [Link]

> So the solution would be to sever the link between fedora and red hat?

The expressions "cutting off the nose to spite the face" and 'throw the baby out with the bathwater" come to mind.

..I've not seen hard numbers but I wouldn't be surprised of RH *directly* spends low-eight-figure sums [0] on Fedora [1], and several times that indirectly [2]. Annually.

Point being, "Severing the link" would effectively be the end of Fedora as we know it.

[0] More than the annual cap of MPEG-LA's licensing regime.
[1] Mostly in the form of salaries, but there's also a sizeable IT (ie equipment+hosting+bandwidth) budget too.
[2] eg folks working on RHEL or Linux itself, virtualization, GCC, GNOME, Freedesktop, and many more upstream projects that make up a substantial chunk of Fedora's new features and use Fedora as their main proving grounds.

Debian status

Posted Jun 5, 2025 9:12 UTC (Thu) by NRArnot (subscriber, #3033) [Link] (4 responses)

Less dramatic would be to remove Fedora from the USA. IBM/Red Hat is a global corporation. But IANAL, and I don't know whether that would make it impossible to sue IBM for the activities of a non-US organisation that is bankrolled and to some extent controlled by IBM.

(IBM ought to know already -- I'm pretty certain that they own such subsidiaries).

Debian status

Posted Jun 5, 2025 9:34 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (2 responses)

IBM could do a lot of things but its Linux desktop business is not worth the pain of fighting in court companies that do have a significant desktop business and love patents (ie Apple).

The only solution is to avoid feeding the trolls, refuse to buy things that rely on H264 & H265 (ie iPhone / Apple TV) and replace them with AV1-capable solutions (right now, good Android TV / Android hardware).

The trolls will continue to pile up patents on H 264/ H 265 till it its ecosystem shrinks enough to be unprofitable (and please do not point to the FUD-ing around AV1, it’s only FUD-ing till the patent holders dare suing AOM, which is about as probable as IBM suing H264/H265 holders to invalidate their crap).

Debian status

Posted Jun 5, 2025 9:51 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

> The only solution is to avoid feeding the trolls, refuse to buy things that rely on H264 & H265 (ie iPhone / Apple TV) and replace them with AV1-capable solutions (right now, good Android TV / Android hardware).

I wish I could buy stuff that doesn't rely on iCrap OR Android (or anything like that). Unfortunately, it's almost (if not completely) impossible to get a decent "free to air" TV any more, and I'm fed up to the back teeth providing tech support to people who don't have a clue how to navigate the home page. They want the default to be the channel they were last watching, and at most a button for the tv guide.

The in-laws won't be around by then, but I'm dreading what will happen when they get round to shutting down "free to air" - it's currently in the works ...

Cheers,
Wol

Debian status

Posted Jun 5, 2025 10:27 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

Unfortunately, when patent trolls are so well funded, and the regulators do not care, there is little alternative to selective buying to make the trolls understand patenting games are not worth the effort. I’d rather give Fedora or Debian money but if you care about video codecs you need to finance the guys that actually deploy commercial alternatives (ie not Apple). The only thing patent trolls will understand is loss of market share.

And the “good” guys are not so good and they also indulge in patenting so you also need to read the spec sheets to make sure their device is actually AV1-oriented.

Debian status

Posted Jun 5, 2025 17:26 UTC (Thu) by rra (subscriber, #99804) [Link]

The US legal system is notorious for believing it has jurisdiction over everyone in the world no matter whether they have real ties to the US. (See, for example, SEC enforcement actions that regularly target non-US companies using the fig leaf that at least one US citizen managed to interact with the company.) It would certainly consider any subsidiary or funded entity of IBM, which trades on US stock exchanges, to be within its jurisdiction regardless of where it had a physical office.

Debian status

Posted Jun 12, 2025 15:06 UTC (Thu) by stefanor (subscriber, #32895) [Link]

> How is Debian' situation different from Fedora's ?

Debian provides an OpenH264 source package that produces 2 separate binary packages:

* libopenh264-8 - this is built from the openh264 source
* libopenh264-cisco8 - this downloads a pre-built binary from Cisco

If you are in a jurisdiction where software patents are recognised, and you have not are not licensed to use h264, you can use the libopenh264-cisco8 package. If you are in a jurisdiction without patent concern, you can use the libopenh264-8 package. This appears to be against Debian's patent policy, I have no insight into the maintainer and FTP masters' decisions there.

Debian is not relying on Fedora to host an APT repository here, instead it is directly downloading the shared library from Cisco (and verifying it against a known hash). So Debian was not relying on any manual request to get Cisco to update a repository.

Made up problem

Posted Jun 2, 2025 17:29 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (7 responses)

This whole problem was created to cater weird legislation of 4% of global population, causing headaches for all the rest. There's a lot of world outside USA, maybe it's time to start ignoring the outlier?

Made up problem

Posted Jun 2, 2025 17:58 UTC (Mon) by smoogen (subscriber, #97) [Link] (5 responses)

Software patents cover more than 4% of the population these days... as many countries who have a statement that 'you can't patent software', will still issue patents and enforce them if enough caveats are added in. They may also recognize infringement of them because of treaties they have signed etc.

https://en.wikipedia.org/wiki/Software_patent#Jurisdictions

It is murky water for companies to tread in which is why most will avoid it as much as possible.

I’d be willing to pay but I can’t

Posted Jun 2, 2025 18:06 UTC (Mon) by DemiMarie (subscriber, #164188) [Link] (4 responses)

I’d be more than happy to pay the (presumably small) per-user royalty needed, but none of the common first-party or third-party repositories I know of have a way to do it!

I’d be willing to pay but I can’t

Posted Jun 2, 2025 21:54 UTC (Mon) by Wol (subscriber, #4433) [Link] (2 responses)

The problem is, as soon as you pay the royalty, unless you pay it for EVERYONE you personally cannot distribute any GPL software that you have so licenced. If you have a patent licence, you have to grant all your downstream a patent licence. And in order to do that, you presumably have to buy the patent, not just a licence.

Which is why the distros don't even attempt to play that game. They'd rather play the MAD game - "sue us and we'll use prior art to turn your portfolio into scorched earth".

I think there were a couple of small instances of that on GrokLaw, and the plaintiffs didn't know what hit them.

Cheers,
Wol

I’d be willing to pay but I can’t

Posted Jun 9, 2025 23:15 UTC (Mon) by DemiMarie (subscriber, #164188) [Link] (1 responses)

Which distros were defendants in those cases?

I’d be willing to pay but I can’t

Posted Jun 10, 2025 6:37 UTC (Tue) by Wol (subscriber, #4433) [Link]

Don't think it was distros - I just have vague memories of patent threats or something, and the resulting threads were chock-full of prior art.

I think at least one threat actor found themselves fending off loads of claims for re-examination.

Cheers,
Wol

I’d be willing to pay but I can’t

Posted Jun 3, 2025 9:22 UTC (Tue) by farnz (subscriber, #17727) [Link]

I enquired about it a while ago; you have two choices from the patent pools:

Buy a licence that covers a specific binary only. Something like the Fluendo GStreamer codec pack, for example. This gets you binaries that are "legal", but where you can't compile your own.
Pay $huge to cover all open source users. This is a non-starter for even the biggest of companies - the H.264 patent pool was talking about a figure in the billions of dollars per year, for example.

And note that the per-user royalties are not necessarily small; the patent pools want to go back to the "glory days" where they got to charge a small amount per decoder (about $1), plus a per-minute fee for use of encoders that varied depending on the audience, plus a fee per encoder.

Made up problem

Posted Jun 2, 2025 21:47 UTC (Mon) by Wol (subscriber, #4433) [Link]

> This whole problem was created to cater weird legislation of 4% of global population, causing headaches for all the rest. There's a lot of world outside USA, maybe it's time to start ignoring the outlier?

And if someone is prepared to take the risk, software patents are now pretty much unenforceable in the USA now. Quoting a (pro-patent) Supreme Court Justice in a Supreme Court decision is pretty much going to blow most cases out of the water.

Dunno which case or when (it was about when GrokLaw died (RIP GL - you are missed)) but one of the most staunchly pro-patent judges wrote - in a software patent case - a concurring opinion where he said that he could not conceive of any circumstance in which a pure program would pass the "eligible subject matter" test.

Okay, we don't have a ruling that software CANNOT pass that test, but we're pretty close.

Cheers,
Wol

How many more days are the H.264 patents relevant?

Posted Jun 2, 2025 17:54 UTC (Mon) by ebiederm (subscriber, #35028) [Link] (1 responses)

I took a quick look and it appears all of the patents except the US patents expire this year.

https://meta.m.wikimedia.org/wiki/Have_the_patents_for_H....

Does anyone know if the above list is accurate?

Is anyone making plans to take advantage of the imminent expiration of the H.264 patents?

This feels like a situation where folks should maintain the current status quo for the rest of the year, and then see what it takes to change.

How many more days are the H.264 patents relevant?

Posted Jun 3, 2025 16:04 UTC (Tue) by numgmt (guest, #167446) [Link]

Ultimately it doesn't matter whether it's accurate or not, because there aren't any free software decoders out there that only implement a subset of H.264. x264, which comes with FFMPEG, implements as much of H.264 as possible.

This wikimedia article focuses on High Profile, which is the most widely used version of H.264. It's really the only profile you need to support to be compatible with almost everything.

The official H.264 patent list from Via-LA includes 16 pages worth of patents, numbering in the hundreds. They even added a few more patents to the list recently: https://forum.doom9.org/showthread.php?p=2005047#post2005047

There have been over a dozen revisions to H.264 with more features added over time. Most of these features are not used by people who use H.264, or are non-critical. But because they exist, x264 will support them, and because they're patented, distributions like Fedora can't use x264.

Someone would need to create a H.264 decoder/encoder that supports only High Profile and nothing later.

Note that OpenH264 does not qualify, as its High Profile support is actually incomplete, so there are some incompatibilities. It doesn't support High 10 for example: https://github.com/cisco/openh264/issues/3616

And it doesn't seem like they plan to add it, given the lack of interest after 2+ years. Another LWN user, farnz mentioned in a previous article that OpenH264 doesn't fully support the parts of High Profile it does support; it gets around it with partial support for Main/High: https://lwn.net/Articles/1015494/

So, OpenH264 would need more complete support for High Profile before it could be a good patent unencumbered option even in a few years when all the H.264 High Profile patents do expire.

Use Flathub for codecs

Posted Jun 2, 2025 18:00 UTC (Mon) by DemiMarie (subscriber, #164188) [Link]

The only viable option I can see at this point is to not ship software that requires royalty-requiring codecs, and instead tell users to install it as a flatpak from Flathub. Flathub moved away from OpenH264 for similar reasons.

Flathub has its own problems, but they all pale in comparison to remote code execution.

Binary patching?

Posted Jun 2, 2025 22:17 UTC (Mon) by cesarb (subscriber, #6266) [Link]

Would it be an option, while the newer package is still not available, to apply a patch on the binaries, directly on the user machines? Not a xdelta between the older and the newer package, but a hand-made placement of jump instructions to code inserted at the end of the text area, like one would do to bypass a simple copy protection check on binary-only software? It could overwrite the library in place, put a modified copy of the library earlier in the search path, or even mimic Jia Tan's approach to patch it in memory. There should be no patent issues in doing that, since the inserted bytes are not implementing any patented algorithm, and the resulting binary would not be distributed.

Browsers

Posted Jun 2, 2025 23:40 UTC (Mon) by pabs (subscriber, #43278) [Link]

Hmm, browsers use OpenH264 too. I wonder if they are aware of the CVE.

H.264 irrelevant yet?

Posted Jun 2, 2025 23:51 UTC (Mon) by pabs (subscriber, #43278) [Link] (4 responses)

At some point the encoding size difference between H.264 and H.265/AV1 will mean that H.264 gets close to irrelevant for some use-cases. Are there any non-legacy situations that still can't use H.265 or AV1?

Of course the patent situation for H.265 is probably worse.

H.264 irrelevant yet?

Posted Jun 3, 2025 4:53 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

With H.264 the licensing is managed by one patent pool and the costs are quite reasonable for any commercial product.

With H.265 there are multiple patent pools, and getting a license from all of them is unreasonably expensive for small players. This caused some vendors to remove the H265 support, even though they can easily pay reasonable cost (e.g. Synology NAS).

AV1 is supposed to be patent-free, but there are leeches trying to attach themselves to it. So far, all the patents are being challenged and slowly invalidated: https://www.unifiedpatents.com/insights?tag=AV1 Unfortunately, Apple is still dragging its feet and doesn't have hardware encoding support for it.

H.264 irrelevant yet?

Posted Jun 7, 2025 2:45 UTC (Sat) by aphedges (subscriber, #171718) [Link] (2 responses)

> Unfortunately, Apple is still dragging its feet and doesn't have hardware encoding support for it.

They thankfully added it recently! According to https://en.wikipedia.org/wiki/AV1#Operating_system_support, Apple added it on Macs and iPhones in 2023.

H.264 irrelevant yet?

Posted Jun 7, 2025 2:48 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Yes, but they support decoding only, not encoding. So if you want to use AV1 for something like WebRTC, you're locked out of iOS.

H.264 irrelevant yet?

Posted Sep 22, 2025 20:18 UTC (Mon) by aphedges (subscriber, #171718) [Link]

Thanks for pointing that out! I missed that it was only decoding support.

Give write access to the cisco repository to Fedora/SuSE?

Posted Jun 3, 2025 7:08 UTC (Tue) by mokki (subscriber, #33200) [Link] (2 responses)

If cisco hosts the server and provides write access to Linux distributions, it would remove all this communication problems from the process and allow fully automatic and timely distribution.

That should still legally remain the same, it should not matter if cisco gets the packages it distributes via email or via sftp.

Give write access to the cisco repository to Fedora/SuSE?

Posted Jun 3, 2025 11:47 UTC (Tue) by 1ace (subscriber, #103978) [Link] (1 responses)

I believe it does matter, the automation is the thing that needs to _not_ be there, it has to be manually put online by a human employed by Cisco to be covered by the Cisco license.

Give write access to the cisco repository to Fedora/SuSE?

Posted Jun 3, 2025 13:03 UTC (Tue) by mokki (subscriber, #33200) [Link]

True, it could be that some human interaction is required at some point to fulfill the license.
But is it enough that a cisco employee has set-up intentionally the automation and the download site?

If not, then we could flip the flow so that we ask cisco to once set up a daily cron+rsync from koji to their server. It should not be any different than cisco internal systems providing the downloaded firmware/codecs to their other appliances (which I assume are automated). I hope the license does not require that for every download and upload there has to be a human explicitly involved.

What about openSUSE?

Posted Jun 3, 2025 16:07 UTC (Tue) by dowdle (subscriber, #659) [Link] (1 responses)

Presumably, openSUSE has/had the same issue. I assume they build their own as well and submit it for publication to Cisco. What is the status of their package? Are they still vulnerable? Did they decide to drop the package?

What about openSUSE?

Posted Jun 4, 2025 8:18 UTC (Wed) by egb (subscriber, #163244) [Link]

I thought I had seen an article about openSUSE and OpenH264, but I was misremembering -- it was about Freedesktop dropping OpenH264. It might still have some gleanable insights: https://lwn.net/Articles/1015408/

Patent clarifications

Posted Jun 3, 2025 21:51 UTC (Tue) by ocrete (subscriber, #107180) [Link]

There are a few inaccuracies around the patents in the article:

1. MPEG LA (now VIA/LA) doesn't own any patents, they're just a middle man collecting the royalties on behalf of the patent holders (called licensors). Those are companies like Apple, Google, Microsoft, Sony, etc. The full list for H.264 is here: https://www.via-la.com/licensing-2/avc-h-264/avc-h-264-li...

2. The yearly cap for H.264 licensing is $9.75 M, no need to look for leaked presentations, they're all clearly listed on the VIA/LA website: https://www.via-la.com/licensing-2/avc-h-264/avc-h-264-li...

Tangentially related - HEVC for images

Posted Jun 5, 2025 10:24 UTC (Thu) by paulj (subscriber, #341) [Link] (1 responses)

Just cause I happened to notice this yesterday in some other stuff: There is an image compression format, HEVC, that significantly improves on JPEG - e.g. images can be 50% the size, even 40% or less, of the JPEG, for the same quality. Yet it appears no major browsers support it, despite it having been around for 10+ years now. And... it comes down to patents.

Tangentially related - HEVC for images

Posted Jun 5, 2025 12:11 UTC (Thu) by excors (subscriber, #95769) [Link]

"significantly improves on JPEG" is a pretty low bar, given how old JPEG is. It's already improved on by WebP (almost universally available in browsers), AVIF (based on AV1; very widely available), and JPEG XL (proposed but rejected for technical reasons and lack of interest). You can even get a reported 35% improvement on traditional JPEG just by using a modern JPEG encoder like Jpegli. AVIF is probably slightly better compression than HEIC, without the big patent problems, so there's no longer any need for HEIC.

Sending build in e-mail

Posted Jun 12, 2025 18:56 UTC (Thu) by seneca6 (guest, #63916) [Link]

No one seemed to know how to achieve the task of alerting Cisco to the builds and ensuring that only Cisco employees could download the builds.

I must be missing something - if you have e-mail contact, surely you can encrypt the file, maybe even just with "zipfile encryption", put it on your Nextcloud / your web server / the shadiest free send-hoster that is still acceptable for Cisco employees, and send the link with the password in your e-mail to Cisco?

That's my standard way whenever a file is too large for an attachment.

Sorted

Posted Jun 28, 2025 18:52 UTC (Sat) by james (guest, #1325) [Link]

The fedora-cisco-openh264 repository has just released the fixed version 2.5.1.

Phew.