Thorsten Glaser <tg@debian.org> writes: > On Thu, 8 May 2025, Simon Josefsson wrote: > >>I don't think it is possible to separate firmware into things that are >>just for enabling of hardware compared to what is running on the main >>CPU. Consider a non-free firmware blob for a future SoC CPU that >>includes camera functionality, it seems possible that would make use of >>some LLM model to have better face recognition for example. Without >>disassembly (which may be illegal) we can't really know if this is part >>of the blob or not. > > I wanted to express that: if the LLM is part of the firmware uploaded > to the SoC for camera functionality, then it is packaged as firmware > as a whole and only accessed through normal camera functions when the > user accesses the camers. It’s not packaged separately (just the model) > or available to other software on the system (removed from the camera > functionality). Okay, I see what you are trying to get at, but I'm not certain things can be separated that easily. Can the camera software in the above scenario be in main, or is it tainted indirectly by the non-free firmware? Does it make a difference if the camera software would only support one proprietary camera that happens to require the non-free-firmware blob? I think this situation is comparable to what we already have today: non-free-firmware blobs enable certain CPU behaviour that packages in 'main' depends on for functionality. > But I agree that to make this distinction probably isn’t worth extra > headache (also my headache’s growing again…) so if nobody has got an > idea of how to express this well, I’d say let’s just remove all > mentions of non-free-firmware from the proposal, it can go with its > usual rules. Yes, I can't seem to find any policy matters that affect only the intersection of non-free-firmware and AI models. It may indeed be simpler to treat non-free-firmware as part of the !main context. /Simon
Attachment:
signature.asc
Description: PGP signature