Re: Changing how we handle non-free firmware
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. steve@einval.com
“Why do people find DNS so difficult? It’s just cache invalidation and
naming things.”
-– Jeff Waugh (https://twitter.com/jdub)
Reply to: