On Tue, 2026-08-18 at 18:28 +0000, John Scott wrote: [...] > On a different tangent, I looked into Realtek's driver which is > currently in the non-free section and it is actually wholly licensed > under the GNU GPL, but not included in main because it contains tables > of random-looking bytes that are assumed to be firmware patches of > some kind. However the mainline kernel driver is similar (even more so > recently) which feels like a double standard.
I used to check each new kernel release for the introduction of large tables of literal numbers that might be closed-source firmware. I challenged a few such additions, including in r8169, as a result of which the PHY firmware used with r8169 is (at least mostly) separated out into linux-firmware.git. A smaller table that the driver copies to the device might be a replacement for an incorrect lookup table, or for some register initialisation values. Even if it is a fragment of machine code, it may be short enough to be "hand-assembled", with no separate source file existing. (I have had to do this once! But I did put the assembly source in a comment.) It would certainly be better programming practice to properly comment these magic numbers, and/or to use named constants. But I don't think we should jump to the conclusion that any mysterious table of numbers is closed-source firmware. As for what is a "large" or "small" tables, the script I wrote to look for large tables of numbers had a threshold of 100 lines, but that was not based on any scientific or legal principle. > I was surprised to see that even Linux-libre doesn't remove that, so I > sent the attached mail to them to learn more for the sake of > curiosity. I don't know that we have a firm stance in Debian about > "magic blobs" that are inline with the kernel source which aren't > firmware (in the linux-firmware.git conventional sense). If these tables do turn out to be closed-source firmware then we are bound to remove them from the Debian linux package (and ideally we would move them out to firmware-nonfree). I am interested to see what response you get. But unless and until that happens, I'm going to assume that these tables are only poorly documented, and are within the DFSG. Ben. -- Ben Hutchings Tomorrow will be cancelled due to lack of interest.
signature.asc
Description: This is a digitally signed message part
