With a change introduced 2 years ago, some video codecs have been excluded from the official mesa build.
Specifically h264, h265/HVEC and AC-1 where disabled. Maybe more where disabled earlier or later, I’m not sure.
This has caused people who value battery life and or smooth video playback to add packman-essentials repo. However it has not been uncommon for the packman mesa to end up a version behind the official mesa for one or a few days causing update conflicts, in practice preventing updates for a while. Recently packman moved (mailing thread) mesa to packman-extra which in addition to causing more headaches for users also increased the risk of update conflicts as there is more software in packman-extra. (I for example just got a libwx_gtk3u_webview conflict that seems to be caused by the addition of packman-extra…).
From my understanding openSUSE (and SUSE) are bound by European patent laws.
Most software patents are not allowed within Europe, but some of the codec patents still have gotten approved trough the “as such” loophole. I am not sure the reduced set forms any strong base for infringement claims, but maybe someone with more knowledge here can clear that up.
However:
All AC-1 patents in europe have expired. See here.
All h264 (high profile) patents in europe have expired by this january (26-01-2025) See here.
All MPEG-4 patents everywhere except brasil have expired. See here or here.
Around 75% of the h265 patents have expired, maybe it can be used without license?
With this I would suggest:
Re-enable h264 and AC-1 and if disabled MPEG-4 codecs in the official mesa build.
Re-evauate if h265 really needs to be disabled, or maybe if it can be provided with an opt in official repo.
Most web-content is moving to resonable codecs (no patents, opensource implementations), but media from cameras or phones, movies, games and such is still using these legacy codecs. Not all hardware supports hardware acceleration of the newer codecs either. We are thus in a period of a longer transition, and its a good idea to support these older codecs system-wide - which I believe (with h265 as an exception) is possible, without the struggles of mixing official/non-official repositories. It should be easy and risk free to have efficient and performant video en/de-coding.
I’m not sure if this extends to other packages that likewise would need build configuration changed, or if its mesa only.
P.S: how can repositories such as packman or rpmfusion legally provide these mesa versions anyway, and is it not possible for openSUSE to do it the same way?
They do not provide them legally. Packman and rpmfusion are operated by individuals/private people which do not care about licences/law infringements. User of packman should know that.
Organisations like openSUSE are bound to the law and can not risk a lawsuit for various, obvious reasons.
rpmfusion disagrees with you, and packman does not explicitly state anything about that, but I severely doubt the maintainers would take that risk, laws do apply to individuals as well. Maybe there is a difference how the laws apply?
Nevertheless that was just a post script, the main point of my post is that for all but h265 the patents have expired, and at least those should be re-enabled in the official repos.
What I think is needed is a support script a user can run to determine their hardware and then provide info on all the formats supported for that hardware? Come up with something and submit to the Project for inclusion?
I don’t follow how this solves or has much to do with the issue at hand: getting some codecs back into the official repos. It does not have anything to do with helping users figure out what their hardware supports…
The Restricted formats page was last updated in 2017, while some information might be still valid (or not time-sensitive) a lot of patents have expired since then, the h264 this january as mentioned.
That just lists packages that are affected, otherwise its the same information as I mentioned in my original post, with the difference that since then patents have expired (page was last updated 2023, when the codecs were first removed…). What I’m saying is that the " Software or methods which have cleared" section can be extended.
Now that would make sense. But it directly poses these follow up questions:
Why does SUSE business locations affect openSUSE? To my understanding its a community project simply sponsored by SUSE?
Can’t SUSE or openSUSE for that matter then instead offer an opt-in official repo like canonical (ubuntu) does with restricted-formats? That would work around the issues of requiring unofficial repos with other stuff in them for system-wide hw acceleration…
Does every patent need to be expired for a technology to be available? The two last BR patents still valid for MPEG-4 to my eye don’t seem to hold much power, and the few US patents still valid for h264 might not either, but I haven’t bother to skim trough them… In other words its still might be feasible to distribute certain packages (example certain decoders) without breaking any active patent, that the holder is restricting, no?
Now that is just weird, is there a reason for this?
Or maybe I am missing something.
Most decoders are already in OSS, apparently for the same reasons that you are stating here. Check for instance:
zypper info --provides gstreamer-plugins-bad
zypper info --provides gstreamer-plugins-ugly
There are apparently only a couple of encoders and a few unusual and DVD decoders that are still patent-encumbered, check for instance:
zypper info --provides gstreamer-plugins-bad-codecs
zypper info --provides gstreamer-plugins-ugly-codecs
which are currently still hosted on Packman.
So, by and large, the packagers are doing their job.
Since I’m not a patent attorney, I don’t know if any of those residual packages could be moved already to OSS, but frankly that doesn’t seem so vital to me.
If you have a background in law and can clearly take away any risk from openSUSE/SUSE, you are free to push/advertise the changes proposed by you at the apropriate communication/developement channels.
But as there are many laws to check and abide to, i honestly guess you aren‘t able to…
“sponsored” here means that some openSUSE services are hosted on servers based in the USA (near Provo, maybe?) and those servers are under US Law AFAIK.
Canonical is under UK Law and that makes things a little easier for them.
Maybe openSUSE could in principle do something similar, but that would likely mean finding new sponsors, servers, possibly to the point that SUSE would not be willing or able to host other services…, just to have an alternative to Packman?
As long as things are hosted on SUSE owned infrastructure, the presence of openSUSE as a “Community Project” is not relevant. Especially considering “The openSUSE Project” has no legal standing of its own, in any jurisdiction.
I guess what remains to discuss is what OrsoBruno found
And things like why intel-media-driver or the nvidia drivers (as discussed in another thread) can include these remaining patented codecs.
I’m starting to suspect the remaining patents indeed don’t hold much power? As in non-essential or about not used features. That seems like the only explanation to how codecs with some still valid patents are in the repo or how (for example) intel-media-driver can decode h264/h265 without distribution issues…
Do you have a source for that? Because that sounds very interesting, I have never heard about such deals. I mean neither Intel nor Nvidia are the distributors, other organisations like SUSE are the ones doing all the distributing…
I searched around quickly to see if I could find anything about it but the only things I found don’t seem to indicate that it would be the case:
During my search I also just found out that Debian includes such patented codecs in default install?
See section “Legal issues” here: MultimediaCodecs - Debian Wiki and their hw accel page.
I know debian might not have any legal standing of its own as a comunity project similarly to openSUSE, but the companies hosting its repositories such as fastly are unlikely to want patent infringements on their door (like SUSE hosting openSUSE infrastructure) so somthing here must be doable without patent issues…
You are confusing proprietary and patented; most of the en/de-coders relevant here (except for nvidia drivers and media-driver-nonfree) are fully opensource implementations of the codecs. Its just that the process of encoding and decoding for some of these formats are (or were) patented and thus even though the patent holders have not written the code and its written in w/e oss license, using them can be complicated, as seen by the discussions here and by the fact that some distros don’t ship them…
In addition you are talking for yourself, the official repositories already have a main non-OSS repository “Main Repository (NON-OSS)”. You are also with 99,9% confidence running proprietary firmware somewhere in your system, for example the UEFI, and there are people who have devices that only have (usable) proprietary drivers such as for example nvidia gpus. It is necessary to provide them for any distro serious about compatibility. You can think whatever you want about that, but its not what we are discussing here.
Any codec implementation that contains proprietary code would of course be in the non-OSS repo, such that people can choose. That is not the topic of this discussion either.
@nMax I run the open driver (MIT/GPL) as well as the proprietary (NVIDIA) on Nvidia GPU’s. Likewise I’ve not seen a need to use non-oss so it’s disabled here…
It does boil down to hardware of the user, then figuring out what is supported on that hardware for their needs with the default openSUSE installation…