Hey Ross! On Wed, Aug 24, 2022 at 11:36:00AM -0700, Ross Vandegrift wrote: > >Thanks for this. I have two questions about your proposal. Apologies >if these are answered elsewhere already.
No worries. >On Thu, Aug 18, 2022 at 08:58:21PM +0100, Steve McIntyre wrote: >> I'm proposing to change how we handle non-free firmware in >> Debian. > >> So, I propose the following: >> >> ================================= >> >> We will include non-free firmware packages from the >> "non-free-firmware" section of the Debian archive on our official >> media (installer images and live images). The included firmware >> binaries will *normally* be enabled by default where the system >> determines that they are required, but where possible we will include >> ways for users to disable this at boot (boot menu option, kernel >> command line etc.). > >First question: > >The substantial issue here that requires a GR is the treatment of >non-free-firmware packages. The bits about installation media are kind >of fallout, or implementation details. It might be better to leave >those out of the GR, and just get crystal clear on the project's >treatment of non-free firmware. I'm not sure I agree with you here. We already have firmware packages in the non-free component of the archive. Ansgar's work on dak has added a new non-free-firmware component, and the plan is that we'll start moving some packages across there soon. For a long time we've said (*handwave*) that non-free is not really part of Debian, so we're not compromising our principles. I don't particularly care about the details of that piece right here and now. The issue I want solved here in the GR is *precisely* what we're going to do about Debian-produced media: * installation media * live images (both traditional "live" images for x86, and the newer raspi images) * (*potentially*) cloud and container images; they're not likely to use non-free firmware, and I hope it stays that way. But you never know... We currently have two sets of installation media and live images: * "official" ones without anything from non-free, that are entitely free and could live in Debian main, *but* are not useful for use and/or installation on lots of current machines these days. * "unofficial" ones which include firmware packages from non-free, but no other non-free packages. These are more useful for many people, but are not fully DFSG-free. The raspi images live in this area, as most of the raspi hardware depends on a non-free primary bootloader that can't love in Debian main. with the latter set not as well publicised. That's not a great story. So I'm describing exactly what we want to change in our images such that: * it's clear we'll be adding non-free-firmware * we're explaining how it will be used, and how users can control that 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. >Would you feel empowered to implement your changes if the GR passed >without these implementation details? That is, if we voted to permit >non-free-firmware packages on official installation media, live images, >and default installations. I'm not sure that really makes much difference here, I'll be honest? >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. -- Steve McIntyre, Cambridge, UK. st...@einval.com “Why do people find DNS so difficult? It’s just cache invalidation and naming things.” -– Jeff Waugh (https://twitter.com/jdub)