The disabling of hardware codecs in community distributions
In September, the Fedora project changed how it builds the Mesa graphics library, disabling support for the H.264 and H.265 codecs. These formats are heavily encrusted with software patents and have long been difficult to support on Linux systems, though the existence of OpenH264 has improved the situation for many users. In this case, though, the patented algorithms are not being executed on the CPU running Linux; instead, they are run (and accelerated) on a peripheral processor like the GPU. With the change, Fedora users (only of the upcoming Fedora 37 release for now, though that will likely change) have lost access to the acceleration provided by their hardware.
The problem was promptly brought
to the Fedora development list, where a number of users expressed their
unhappiness at the change. But there was also a certain amount of surprise
that Red Hat would not allow code that enables hardware functionality to be
shipped; Chris Adams, for example, asked:
"But isn't this just providing for hardware decoding, where (presumably)
the hardware vendor arranged for whatever needed licenses?
". The
"presumably", in this case, turns out to be wrong.
The vendors shipping this functionality, it seems, do not feel any need to arrange for the licensing to allow their customers to actually use their products in that way. Instead, the acceleration features in the hardware are viewed as a partial solution that only implements the patented algorithms when combined with software support on the CPU. And, as David Airlie pointed out: it is the provision of a solution that actually works that is seen as using the patented technology:
Think of it like a jigsaw puzzle, where the person who places the last piece in the puzzle pays the license. But then stop thinking of it like that and just assume it's a lot vaguer and way more legally involved than that.
Or, as Tom "spot" Callaway put it:
Mesa was (is) implementing the software parts of H264 and H265 encoding/decoding as part of the Video Acceleration API (VAAPI). This interface tells your GPU (usually, sometimes it is other hardware) to do the hard work of encoding/decoding, but it isn't a black box.It is a combination of available hardware and software which does the work, and thus, the implementation as delivered potentially infringes.
So, once again, Linux users can't have good things as the result of software patents. Once Red Hat realized that Fedora was shipping code that might possibly be infringing on the codec patents, that code had to be pulled to avoid accusations of willful infringement. After the situation came to light, openSUSE quickly followed suit with a similar change. Some other distributors may not make the same change, choosing instead to continue to ship the affected codecs; Callaway had an explanation for that as well:
They might be too small to sue (remember, expensive to take to court) and/or too small to get any meaningful damages as a result. I mean, Debian is just rolling in money, right? Or the parent company is based in a legal grey zone. *cough*
Companies with sufficiently deep pockets that are not based in legally sheltered areas do not generally feel that they can take the risk, though.
All is not lost yet; Linux users have other codecs available to them.
Users who are willing to take the extra step of installing OpenH264 will
still have the ability to play back media in that format without
infringement worries. Airlie also suggested
that having OpenH264 installed might be sufficient to allow the re-enabling
of other H.264 codecs on the same system — but it is not clear that any
lawyers have signed off on that idea. Some of the disabled functionality
may yet show up in third-parties like RPM
Fusion as well. Meanwhile, though, this episode is just another
reminder of the threats posed by software patents. We are free to write
any software we like — but we may not be free to run it.