[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Changing how we handle non-free firmware

Hi a11!

I'm proposing to change how we handle non-free firmware in
Debian. I've written about this a few times already this year [1, 2]
and I ran a session on the subject at DebConf [3].
TL;DR: The way we deal with (non-free) firmware in Debian isn't
great. For a long time we've got away without supporting and including
(non-free) firmware on Debian systems. We don't *want* to have to
provide (non-free) firmware to our users, and in an ideal world we
wouldn't need to. However, it's no longer a sensible path when trying
to support lots of common current hardware. Increasingly, modern
computers don't function fully without these firmware blobs.

Since I started talking about this, Ansgar has already added dak
support for a new, separate non-free-firmware component - see
[4]. This makes part of my original proposal moot! More work is needed
yet to make use of this support, but it's started! :-)

I believe that there is reasonably wide support for changing what we
do with non-free firmware. I see several possible paths forward, but
as I've stated previously I don't want to be making the decision
alone. I believe that the Debian project as a whole needs to make the
decision on which path is the correct one.

I'm *not* going to propose full text for all the possible choices
here; as eloquently suggested by Russ [5], it's probably better to
leave it for other people to come up with the text of options that
they feel should also be on the ballot.

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.).

When the installer/live system is running we will provide information
to the user about what firmware has been loaded (both free and
non-free), and we will also store that information on the target
system such that users will be able to find it later. The target
system will *also* be configured to use the non-free-firmware
component by default in the apt sources.list file. Our users should
receive security updates and important fixes to firmware binaries just
like any other installed software.

We will publish these images as official Debian media, replacing the
current media sets that do not include non-free firmware packages.


A reason for defaulting to installing non-free firmware *by default*
is accessibility. A blind user running the installer in text-to-speech
mode may need audio firmware loaded to be able to drive the installer
at all. It's going to be very difficult for them to change this. Other
people should be able to drive the system (boot menus, etc.) to *not*
install the non-free firmware packages if desired.

We will *only* include the non-free-firmware component on our media
and on installed systems by default. As a general policy, we still do
not want to see other non-free software in use. Users may still enable
the existing non-free component if they need it.

We also need to do the work to make this happen:

 * in d-i, live-boot and elsewhere to make information about firmware

 * add support for the non-free-firmware section in more places:
   ftpsync, debian-cd and more.

and I plan to start on some of those soon.

[1] https://blog.einval.com/2022/04/19#firmware-what-do-we-do
[2] https://lists.debian.org/debian-devel/2022/04/msg00130.html
[3] https://debconf22.debconf.org/talks/43-fixing-the-firmware-mess/
[4] https://incoming.debian.org/debian-buildd/dists/buildd-unstable
[5] https://lists.debian.org/debian-devel/2022/04/msg00214.html

Steve McIntyre, Cambridge, UK.                                steve@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Attachment: signature.asc
Description: PGP signature

Reply to: