On Thu, Aug 25, 2022 at 11:00:35PM +0100, Steve McIntyre wrote: > That may sound like implementation details to you, but to me those are > the important parts of the change. I'd rather not be in this position, > and I have a lot of sympathy for the people pushing back on the idea > of maybe compromising our Freeness. This is why I want to spell it out > clearly.
Got it, and fair enough! Thanks for explaining. [snip] > >Second question: > > > >It might be good to have rules spelling out what can go into > >non-free-firmware. This would help clarify how non-free-firmware isn't > >just non-free. Is this in place or in progress? Does the GR need to > >include it, or is there some other appropriate mechanism? > > A few of us have spoken about it, but it's not something that we've > laid down in stone yet. We're looking at packages that install only > non-free binary blobs in /lib/firmware, containing only firmware / > software that executes separately to the control of the main OS. So, > that includes things like firmware for wifi hardware *and* CPU > microcode, but *not* (e.g.) the non-free Nvidia drivers that integrate > with the OS kernel. > > I'm less worried about this side - AFAICS ftpmaster and the the people > already packaging these things already have a reasonable idea on what > goes where. Totally agreed, I expect everyone to make reasonable decisions about it. Sometimes writing down these sorts of expectations helps avoid confusion and ease peoples' minds. Your proposal already makes me feel okay about the freeness tradeoffs. But I can imagine someone who might need to (or benefit from) understand the limits of non-free-firmware to feel okay about the proposal. Just to be clear, I don't think it's essential for the GR. Thanks again, Ross
