Hello Stephan, On 3/12/25 12:10 PM, Stephan Verbücheln wrote:
Hello everyoneThe “drivers” for hardware video decoders on Intel GPUs have been split into free and non-free packages. https://packages.debian.org/en/sid/intel-media-va-driver https://packages.debian.org/en/sid/intel-media-va-driver-non-free The difference between the two is that the Intel source code contains blobs (byte arrays in the C source) with pre-compiled GPU shaders. The source code for the pre-complied shaders is not included and does not appear to be available under a free license.
great pragmatic question! First of all my answer: The answer ********** GPU shaders should be clearly respected as software (and not hardware). Therefore, `intel-media-va-driver-non-free` is rightly in the Debian archive `non-free`. Model of free software systems ****************************** As I described in * https://lists.debian.org/debian-devel/2025/03/msg00196.html for me is a computer machine a stack of three layers: Machine/Computer ,-----------------------------------------, | optional non-free/proprietary software | |-----------------------------------------| | Free and open-source software | |-----------------------------------------| | Hardware (maybe non-free/proprietary) | '-----------------------------------------' If we remove the optional `non-free` layer on the top then we have a fully free software system. I would assume that also GNU would not refute this model of a fully free software system. The question must be: Is firmware to be considered as hardware or software? I.e. in your case of GPU shaders the question is: * Should be GPU shaders considered as hardware or software? The reason for the answer above ******************************* We should unite us in the point that we do not accept non-free software between the bottom two layers. Means there should be no non-free software directly above the hardware layer. As I pointed out in the thread linked above, that we need to consider firmware as hardware in the sense that: 1. Firmware needs to be developed by the chip-vendor itself. (Hardware from companies point of view) 2. Firmware needs to be deployed between hardware companies, i.e. SoC companies, PCB companies, etc. (Hardware from logistic point of view) Now GPU shaders: 1. GPU shaders will not be developed exclusively by the chip vendor itself. In contrast, they providing SDKs for development. 2. GPU shaders will be deployed between software companies, and not exclusively by hardware companies. I.e. 3D engine developers to Game design companies. From technical point of view not clear ************************************** As you expect, in detail from technical point of view, firmware is a special kind of software. It is not data -- and it is executable in the sense that it changes the state of "physical hardware" in time. Physically stored as * a mapped table of commands on, we don't know: flashable EPROM, Solid-State-Device, RAM, ... * an array/matrix of programmable basic gates on: FPGA, ... From this point of view, it makes no sense to differentiate between firmware and software by the media on which it will be stored -- or the format how it changes the state-machine. If someone do so then they are cheating themselves. BUT!: This point of view is wrong in our current situation. From companies-/logistic- ->to-> technical- point of view ********************************************************* Okay, someone would say: * "What? My point of view, the technical one, is wrong? wtf!" The answer is: The path is the goal. The 3-layer machine/computer model we agree all, hopefully. We can map the companies-/logistic- point of view very well to that 3-layer model, imho. We need to go a path! The goal of the path is the technical point of view. Otherwise we become shizo ;P ... What is the path? Imho, I recognize exactly 3 possible paths in the 3-layer machine/computer model. With the border between layer 'Free software' and 'Hardware' * path 1: ... we can soften/remove it and create a flowed merge of both. * path 2: ... we can insert an additional layer, called 'non-free-firmware'. * path 3: ... we describe it very precisely, as accurately as possible. Path 1 is brain-dead, who contradicts? xD ... Path 2 is that what we do not want; not to be confused with path 2 is the current actual-state! We try to find a path, and path 2 is very trivial: Map the current Debian archives structure to the 3-layer machine/computer model. Okay, then we need to go path 3, we need to describe the border between layer 'Free software' and 'Hardware' very precisely, as accurately as possible. Therefore, in my opinion we have something like an homogeneous system: If our path needs to be go from companies-/logistic- |------> technical- point of view the homogeneous equivalent should be Model border 'Free software'/'Hardware' not well defined |------> defined accurately as possible Then we just need to rename 'border' into 'interface' or 'policy'. Imho, as more accurately and precisely we are describing the interface/border, beginning at the companies-/logistic- point of view (because this maps very well, imho) as more we reach the technical- point of view, which is the goal of our path to go. Btw: This does not include the idea of Open Hardware, as we does not change 3-layer machine/computer model above. Okay, to much written for today. Therefore, here comes a quickly end of the email. Dirk =)
OpenPGP_0xE2A3766F21F02BD5.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
