Reconsidering Debian’s Inclusion of Non-Free Firmware - A Call for Discussion

[Andrey Rakhmatullin]

I understand that users need proprietary drivers to run certain
hardware, and Debian should not ignore this reality. That is why I am
not asking Debian to become a fully GNU-endorsed distro like Trisquel,
which rejects all non-free software in every case.

Good! It's also good that you already know about Trisquel and so we can
skip suggesting it.

However, at the same time, Debian should not readily promote non-free
firmware to the point where it loses its philosophical distinction and
becomes just another convenience-focused distribution like Ubuntu or
Linux Mint.

I would like Debian to become more convenience-focused than FSF-focused.

After compromising a byte, our goal should be to find/develop libre
alternatives so that, in the future, Debian users are less (bit)
dependent on non-free firmware.

You could do that in parallel. Please do find/develop those.

Instead, we did the
opposite--compromising more, from a byte to a kilobyte, for the sake
of convenience. If this trend continues, what stops us from reaching a
megabyte of compromise?
Debian's official inclusion of non-free firmware contradicts its
original philosophical values and social contract. Today, Debian
includes a few non-free firmwares; tomorrow, it may include several;
and the day after, many.

Yes please!

I urge Debian to rethink its decision to officially include non-free
firmware and correct the social contract.

There is a procedure for that. Assuming you cannot propose a GR yourself
you may find DDs who will want to do that. However, make sure you both
understand that proposing a GR that will definitely fail just wastes time
of people involved.

Instead of making non-free
firmware the default, Debian should ensure that users consciously
choose to install it while being made aware of the implications.

That was option 3, which lost to all options except FD, or maybe
(considering the mood of your email) option 4, *which lost to FD*.

GNU explains: https://www.gnu.org/philosophy/install-fest-devil.html
Imagine hiding the "devil" by making it an official part of Debian.
Debian is Debian--the "devil" should not be an official part of it.

You know what to use if you don't like the current Social Contract of
Debian.

[Leandro Cunha]

Hi,

Dear Debian Community,
I am Deep Pandya from Gujarat, India, and a long-time Debian user. I migrated from Windows to Ubuntu in 2013 and later explored the philosophy of the GNU project and the history of the free software movement. After trying GNU-endorsed Trisquel and PureOS, I finally landed on Debian (Stretch release) in 2019 and have been actively using it since (Buster, Bullseye, Bookworm). In 2020, I even wrote a blog post, “Reasons to choose Debian among GNU/Linux distributions” (https://lignuxblog.wordpress.com/2020/08/27/reasons-to-choose-debian/). Though I am not a programmer or software developer, I deeply care about Debian’s values.
In 2022, the General Resolution to officially include non-free firmware in the installation images shocked me because it signified a move away from Debian’s conceptual roots.
I fully believe in the GNU philosophy and its uncompromising commitment to freedom. Without that, we might not have had the Linux kernel under GPL or even the open-source movement. However, when it comes to practical usability, I acknowledge that some users—myself included—may need to install non-free firmware for WiFi, Bluetooth, or graphics drivers. But in the past, when I made such a compromise, I was aware of it. Debian used to perfectly balance software freedom and usability—until 2022.
I understand that users need proprietary drivers to run certain hardware, and Debian should not ignore this reality. That is why I am not asking Debian to become a fully GNU-endorsed distro like Trisquel, which rejects all non-free software in every case. However, at the same time, Debian should not readily promote non-free firmware to the point where it loses its philosophical distinction and becomes just another convenience-focused distribution like Ubuntu or Linux Mint.
[A Ruinous Compromise]
After compromising a byte, our goal should be to find/develop libre alternatives so that, in the future, Debian users are less (bit) dependent on non-free firmware. Instead, we did the opposite—compromising more, from a byte to a kilobyte, for the sake of convenience. If this trend continues, what stops us from reaching a megabyte of compromise?
Debian’s official inclusion of non-free firmware contradicts its original philosophical values and social contract. Today, Debian includes a few non-free firmwares; tomorrow, it may include several; and the day after, many. If we normalize this now, how will future Debian developers uphold our values? This is the kind of ruinous compromise that GNU warns about: https://www.gnu.org/philosophy/compromise.html
[A Call for Rethinking This Decision]
I urge Debian to rethink its decision to officially include non-free firmware and correct the social contract. Instead of making non-free firmware the default, Debian should ensure that users consciously choose to install it while being made aware of the implications. As GNU explains: https://www.gnu.org/philosophy/install-fest-devil.html
Imagine hiding the “devil” by making it an official part of Debian.
Debian is Debian—the "devil" should not be an official part of it.
When we have enough free software, at our call, Debianers at our call,
We'll kick out these dirty firmware ever more, Debianers ever more.
I look forward to hearing thoughts from the Debian community on this important issue.
Best Regards,
Deep P. Pandya

In short, the social contract is still being addressed, as the main
repository remains in accordance with the DFSG and the firmwares
separated into non-free-firmware that were moved from non-free. There
is currently a need for these firmwares for the full functioning of
recent machines and I had experience of this on a new machine
purchased 2 years ago.

The project has its own guidelines, which I defend, but following the
philosophy of the GNU project, the project could not even distribute
these firmwares and distribute Linux Libre to users. Unfortunately or
fortunately, this would not be the focus of Debian, which distributes
its own Kernel and this can be addressed by rereading the FSF's free
distribution guidelines, the FSDG[1].

[1] https://www.gnu.org/distros/free-system-distribution-guidelines.html.en

You can also opt for one of these distributions and Trisquel[2] would
be based on Ubuntu which is based on Debian.
https://www.gnu.org/distros/free-distros.html

[2] https://trisquel.info/en/wiki/documentation

[Leandro Cunha]

I urge Debian to rethink its decision to officially include non-free
firmware and correct the social contract. Instead of making non-free
firmware the default, Debian should ensure that users consciously
choose to install it while being made aware of the implications.

I agree and would personally come back to use Debian on some of my
laptops if there was a supported way to install Debian from official
installer images that did not promote non-free software by including
firmware on them.
The recent AMD Microcode vulnerability is a good case-study on the
https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microco
de-hacking
There is no way for me as a user to audit that the Debian installer
images is not including vulnerable microcode, since source code for the
firmware is not available.
My perception is that the Debian developer community rejected this, and
I'm not sure people are ready to reconsider just yet (the trend seems to
be the opposite way). Fortunately there are good libre alternatives in
Trisquel and Guix available for recommendation meanwhile.

In the original GR, one of the options that lost was for Debian to host two sets of installer images, one with non-free firmware and one without, and for users to be able to make an informed decision before downloading the installer.
https://www.debian.org/vote/2022/vote_003#textc
This option did not prevail in the vote, but it would have been my preferred choice (I was not a Debian Developer at the time and so did not vote, but I did follow the discussion).
As mentioned above, I don’t think most people’s feelings have changed enough to warrant reopening this discussion, but I can imagine the day in the future where Debian moves towards this option.
--
Soren Stoutner

I think it's good to have more alternatives, despite more work to take
care of these ISOs for stable and testing mainly.
So I wouldn't disagree with that either, as in the past there were
both and the firmware was considered unofficial.

[Soren Stoutner]

I urge Debian to rethink its decision to officially include non-free
firmware and correct the social contract. Instead of making non-free
firmware the default, Debian should ensure that users consciously
choose to install it while being made aware of the implications.

I agree and would personally come back to use Debian on some of my
laptops if there was a supported way to install Debian from official
installer images that did not promote non-free software by including
firmware on them.
The recent AMD Microcode vulnerability is a good case-study on the
https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microco
de-hacking
There is no way for me as a user to audit that the Debian installer
images is not including vulnerable microcode, since source code for the
firmware is not available.
My perception is that the Debian developer community rejected this, and
I'm not sure people are ready to reconsider just yet (the trend seems to
be the opposite way). Fortunately there are good libre alternatives in
Trisquel and Guix available for recommendation meanwhile.

In the original GR, one of the options that lost was for Debian to host two sets of installer
images, one with non-free firmware and one without, and for users to be able to make an
informed decision before downloading the installer.

https://www.debian.org/vote/2022/vote_003#textc

This option did not prevail in the vote, but it would have been my preferred choice (I was
not a Debian Developer at the time and so did not vote, but I did follow the discussion).

As mentioned above, I don’t think most people’s feelings have changed enough to warrant
reopening this discussion, but I can imagine the day in the future where Debian moves
towards this option.

[Bill Allombert]

In the original GR, one of the options that lost was for Debian to host two sets of installer
images, one with non-free firmware and one without, and for users to be able to make an
informed decision before downloading the installer.
https://www.debian.org/vote/2022/vote_003#textc
This option did not prevail in the vote, but it would have been my preferred choice (I was
not a Debian Developer at the time and so did not vote, but I did follow the discussion).

True, but the GR does not prevent Debian of providing a second set of
installer images. What is required is someone to do the work, as usual.

Cheers,

[Simon Josefsson]

Post by Bill Allombert
True, but the GR does not prevent Debian of providing a second set of
installer images. What is required is someone to do the work, as usual.

We already had those images before. The winning choice said:

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

There was another almost identical choice on the vote that instead said:

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

I read this outcome as fairly clear message that, no, Debian does not
want to provide a second set of installer images, and is not interested
in contributions to make them. This triggered me to reduce Debian usage
and contribute more to the Guix and Trisquel projects (the latter build
udebs from Ubuntu packages and maintain a debian-installer fork).

/Simon

[Aurélien COUDERC]

Post by Simon Josefsson
I read this outcome as fairly clear message that, no, Debian does not
want to provide a second set of installer images, and is not interested
in contributions to make them.

Your positions in this thread try to make it sound much more black and white than it needs to be, than the GR text is written and than my reading of the current consensus in Debian.

Like others have said you can start working on alternate fully free images. We've seen in the thread that there's interest in it. (I would use them. I did like the fully free images although I would knowingly install firmware on top of them.)

What the GR says is that you cannot dump that work on the shoulders of the people currently maintaining the installer, coordinating the releases…

That you're trying to impose so many preconditions before even starting the work is OTOH an indication to me that you're not really interested in doing it in the context of Debian.


--
Aurélien

[Simon Josefsson]

Post by Aurélien COUDERC

Post by Simon Josefsson
I read this outcome as fairly clear message that, no, Debian does not
want to provide a second set of installer images, and is not interested
in contributions to make them.

Your positions in this thread try to make it sound much more black and
white than it needs to be, than the GR text is written and than my
reading of the current consensus in Debian.
Like others have said you can start working on alternate fully free
images. We've seen in the thread that there's interest in it. (I would
use them. I did like the fully free images although I would knowingly
install firmware on top of them.)
What the GR says is that you cannot dump that work on the shoulders of
the people currently maintaining the installer, coordinating the
releases

That you're trying to impose so many preconditions before even
starting the work is OTOH an indication to me that you're not really
interested in doing it in the context of Debian.

I would be happy if my perception of the situation is wrong, and that
fully free official debian installer images was a welcome contribution.
Is that really the case?

My reading of the vote outcome is that Debian Project made a "statement
on an issue of the day" that there would be no more fully free images:

The Debian Project also makes the following statement on an issue of the day:
...
We will publish these images as official Debian media, replacing the
current media sets that do not include non-free firmware packages.

This won over the alternative that permit both as official media:

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

What is the mechanism to issue a new statement on an issue of the day?
Does it require a new vote? What I'm looking for is to confirm a shift
of sentiments towards a position like this:

We will publish images with non-free firmware as official Debian
media, and encourage contributors who are interested in fully free
installer images to offer them separately and that these are also
considered official Debian media.

Andy Cater's post is hard to parse for me. Andy, did you intend it as a
sarcastic comment about something that has been beating to death too
many times already and has no chance of becoming reality? Or was it a
real invitation for discussion and accept contributions? My earlier

Post by Aurélien COUDERC
Please feel free to pick up the code and generate the second set of
installer images, maintaining the code to exclude non-free-firmware.

If I understand what you imply here correctly, this is still a problem.
Proper fully free images cannot be generated by going through an
intermediate step that involve non-free software.

/Simon

[Andrew M.A. Cater]

Post by Simon Josefsson

Post by Aurélien COUDERC

Post by Simon Josefsson
I read this outcome as fairly clear message that, no, Debian does not
want to provide a second set of installer images, and is not interested
in contributions to make them.

Hi Simon,

The voting round this issue had nuance, as you can see.

In many ways, this reflected the relative difficulty of continuing
to do things as we had been doing. Nobody was keen to continue
duplicating effort for the sake of duplicate effort and the wording
reflected this. There had been a *lot* of discussion over approximately
two years, a couple of Debconfs about the fact that some things
could not be achieved without non-free firmware potentially even at
early stage in the installer.

Post by Simon Josefsson

Post by Aurélien COUDERC
What the GR says is that you cannot dump that work on the shoulders of
the people currently maintaining the installer, coordinating the
releases…

Absolutely.

Post by Simon Josefsson
I would be happy if my perception of the situation is wrong, and that
fully free official debian installer images was a welcome contribution.
Is that really the case?

We had a "fully free" installer and a large non-free archive from which
many people pulled firmware to make their hardware work fully.
Non-free-firmware being pulled out of the rest of non-free was a
recognition of that fact and a distancing of firmware from the rest
of non-free.

Post by Simon Josefsson
Andy Cater's post is hard to parse for me. Andy, did you intend it as a
sarcastic comment about something that has been beating to death too
many times already and has no chance of becoming reality? Or was it a
real invitation for discussion and accept contributions? My earlier

It is slighttly sarcastic, yes, but it also outlines exactly what is
involved if you want to pursue a fully free installer (again).
Having been involved in explaining the difference between the installer
and the unofficial installer containing firmware far too many times,
it was difficult to justify an idealogical separation that made it
hard for people to install Debian (or impossible if you were
visually impaired, potentially).

Maintaining two sets of images would be hard. Testing two sets of
images at point release time was also hard.

Post by Simon Josefsson

Post by Aurélien COUDERC
Please feel free to pick up the code and generate the second set of
installer images, maintaining the code to exclude non-free-firmware.

If I understand what you imply here correctly, this is still a problem.
Proper fully free images cannot be generated by going through an
intermediate step that involve non-free software.

You can build an image that contains no firmware.

You can build an image that contains only free firmware.

You can build an image that contains non-free firmware.

Each of these can be built from the code in the Debian archive.
The scripts to produce each of these are slightly different: you would
need to satisfy yourself that every time you regenerate images you
have not inadvertently included inappropriate firmware somewhere along
the line.

I'd suggest a long read through the mailing list archives and watching
a couple of the videos from Sledge. It is harder than it looks and
relies on a *lot* of effort to do this.

With every good wish, as ever,

Andy Cater

Post by Simon Josefsson
/Simon

[Matthias Urlichs]

Post by Simon Josefsson
I read this outcome as fairly clear message that, no, Debian does not
want to provide a second set of installer images, and is not interested
in contributions to make them.

Another way to look at this outcome, and the one I personally prefer by
a wide margin, is that it'd be very cool to have them, but at this time
their utility is 
 questionable, given that I personally own zero (out
of umpteen) computers that would work with such an image.

Not my NAS, not my router, not my laptop, not the Raspberry Pi that's
controlling my home's heating system. Or the other Pi behind the TV;
said TV is a far worse problem from a free software PoV than a few blobs
of firmware, but I digress.

So why should a GR compel us to build a second set of images which most
people cannot use anyway?

On the other hand, if you want to spend some time building those images,
fine, go ahead; if and when those images are actually usable for a
relevant subset of machines out there, *then* we can might want to
revise our decision.

--
-- regards
--
-- Matthias Urlichs

[Simon Josefsson]

Post by Matthias Urlichs

Post by Simon Josefsson
I read this outcome as fairly clear message that, no, Debian does not
want to provide a second set of installer images, and is not interested
in contributions to make them.

Another way to look at this outcome, and the one I personally prefer
by a wide margin, is that it'd be very cool to have them, but at this
time their utility is 
 questionable, given that I personally own zero
(out of umpteen) computers that would work with such an image.
Not my NAS, not my router, not my laptop, not the Raspberry Pi that's
controlling my home's heating system. Or the other Pi behind the TV;
said TV is a far worse problem from a free software PoV than a few
blobs of firmware, but I digress.
So why should a GR compel us to build a second set of images which
most people cannot use anyway?
On the other hand, if you want to spend some time building those
images, fine, go ahead; if and when those images are actually usable
for a relevant subset of machines out there, *then* we can might want
to revise our decision.

It will always be possible to find machines where fully free installer
images cannot run on. This was the case 30 years ago and most likely it
will be the case in 30 years. It seems the disagreement is if that fact
should influence Debian's decisions on what to provide to its users. It
used to be "no", but now it is "yes" which is a bit ironic since I find
it easier to find suitable hardware today than it was 30 years ago.

Our experience seems to differ, I now run Trisquel and Guix on many of
my home and machines and servers. For my uses they all work without
non-free firmware. You have to be careful about what hardware you buy,
and chose your use-cases. And, yes, I use modern hardware -- i9-14900K
on desktop, i7 1260P and Ultra 155H in my two most used laptops,
ARS-111M-NR and Talos II on the server side, as well as a bunch of aging
Dell R630's.

I fully understand if people who work on debian-installer and installer
images don't want to spend time on supporting fully free images. I
don't envy that task, and many thanks for what has been achieved! My
request is not so much about asking them to break their shoulders with
more heavy lifting, but for the project as a whole to not drive away
folks with statements of the effect that a fully free Debian is no
longer a project goal. My perception is that people are not ready to
reconsider their positions, and that the vote gave a clear message, but
I may be wrong.

/Simon

[Ansgar 🙀]

Hi,

Post by Simon Josefsson
Our experience seems to differ, I now run Trisquel and Guix on many of
my home and machines and servers.  For my uses they all work without
non-free firmware.  You have to be careful about what hardware you buy,
and chose your use-cases.  And, yes, I use modern hardware -- i9-14900K
on desktop, i7 1260P and Ultra 155H in my two most used laptops,
ARS-111M-NR and Talos II on the server side, as well as a bunch of aging
Dell R630's.

This class of hardware *requires* non-free firmware. Lots of it, at
every system layer.

You just choose to use the non-free firmware version that happens to
come pre-installed, but it's still non-free firmware just as a pre-
installed Microsoft Windows is still non-free software, even when you
just use it as a "firmware" to boot a firmware-free Linux in Windows'
subsystem for Linux. (Which the FSF might arguably call "free" then...)

Ansgar

[Simon Josefsson]

Post by Ansgar 🙀
Hi,

Post by Simon Josefsson
Our experience seems to differ, I now run Trisquel and Guix on many of
my home and machines and servers.  For my uses they all work without
non-free firmware.  You have to be careful about what hardware you buy,
and chose your use-cases.  And, yes, I use modern hardware -- i9-14900K
on desktop, i7 1260P and Ultra 155H in my two most used laptops,
ARS-111M-NR and Talos II on the server side, as well as a bunch of aging
Dell R630's.

This class of hardware *requires* non-free firmware. Lots of it, at
every system layer.

Agreed. However none of that hardware require me to load non-free
firmware from my operating system, which is my point. That situation is
sufficient for me to accept to use the hardware and install an operating
system built without non-free software on it.

/Simon

[Andrew M.A. Cater]

Post by Simon Josefsson
Agreed. However none of that hardware require me to load non-free
firmware from my operating system, which is my point. That situation is
sufficient for me to accept to use the hardware and install an operating
system built without non-free software on it.

Simon,

Installing using the Debian installer doesn't *require* you to carry on
with the firmware. You can readily remove it - especially if you use the
expert install - you are not required to enable the repository in your
/etc/apt/sources.list and so on. The installer does list the firmware
suggested for install to enable all devices - you don't have to take
that suggestion.

So - if you don't *see* the need for firmware expressed and firmware is
already in the machine you install on, that's fine?

We've *had* this argument and the Project as a whole decided by a slim
margin that the effort to maintain an installer relatively free of
firmware (but including free firmware) AND an installer containing
non-free firmware to aid installation of Debian was too much effort.

To everyone wishing for this: If you want to make a Trisquel-ised Debian
installer with a linux-libre kernel and no firmware, fine - happy for you
and relatively happy to see you succeed.

At that point there will no longer be a need for the Trisquel fork of
Debian to continue on that basis and that will represent a consolidation
of effort where Trisquel developers can then concentrate on Debian and
stop being downstream of a downstream.
.
In the interim: That makes *lots* more effort for the Debian Project,
lots more space needed for media and so on, as outlined earlier in the
thread. Please feel free to step up and contribute significant effort
yourself to see all of this come to pass.

Andy Cater

Post by Simon Josefsson
/Simon

[Marc Haber]

Post by Andrew M.A. Cater
Installing using the Debian installer doesn't *require* you to carry on
with the firmware. You can readily remove it - especially if you use the
expert install - you are not required to enable the repository in your
/etc/apt/sources.list and so on. The installer does list the firmware
suggested for install to enable all devices - you don't have to take
that suggestion.

And if you don't, none of the evil code ever gets loaded or installed,
it just sits there on the media, right?

Greetings
Marc, who likes Debian to run on the hardware people have - it saves me
time to explain why Debian doesn't run.

[Simon Josefsson]

Post by Andrew M.A. Cater

Post by Simon Josefsson
Agreed. However none of that hardware require me to load non-free
firmware from my operating system, which is my point. That situation is
sufficient for me to accept to use the hardware and install an operating
system built without non-free software on it.

Simon,
Installing using the Debian installer doesn't *require* you to carry on
with the firmware. You can readily remove it - especially if you use the
expert install - you are not required to enable the repository in your
/etc/apt/sources.list and so on. The installer does list the firmware
suggested for install to enable all devices - you don't have to take
that suggestion.
So - if you don't *see* the need for firmware expressed and firmware is
already in the machine you install on, that's fine?

While this may be fine to you it is not fine to me, and it is fine to
disagree on that. We've had this argument before, and I don't think
either us will change opinion. The situation you describe is one
motivation for efforts like linux-libre, Trisquel and Guix, and the
other FSDG-compliant distributions. My hope is that the sentiments
towards fully free installer images will change in the Debian project
and that they eventually may be official again. I believe the
supply-chain concerns with non-free firmware will trigger this happen,
but it seems we are not there yet.

/Simon

[Philip Hands]

Hi Simon,

Post by Simon Josefsson
While this may be fine to you it is not fine to me, and it is fine to
disagree on that.

If there were a method of building images that did not touch the
non-free components, I presume that would satisfy you.

Let's say that we could make that image bit-for-bit reproducible with an
image that was produced by taking the normal with-nonfree-firmware
image, and filtering it somehow (e.g. overwriting the non-free bits with
zeros, say).

Would you object if the normal way of generating the image was to apply
the filter, rather than build it in parallel?

If that would be OK, then one could have something that applied the
filter to our normal images to provide people with the images you want,
while not require duplication of building and storage.

People could always confirm that they were getting the same result as
building without the nonfree firmware by doing it themselves, and
checking things matched.

Is that something that would work for you?

Cheers, Phil.

[Simon Josefsson]

Post by Andrew M.A. Cater
Hi Simon,

Post by Simon Josefsson
While this may be fine to you it is not fine to me, and it is fine to
disagree on that.

If there were a method of building images that did not touch the
non-free components, I presume that would satisfy you.

That sounds good!

Post by Andrew M.A. Cater
Let's say that we could make that image bit-for-bit reproducible with an
image that was produced by taking the normal with-nonfree-firmware
image, and filtering it somehow (e.g. overwriting the non-free bits with
zeros, say).
Would you object if the normal way of generating the image was to apply
the filter, rather than build it in parallel?
If that would be OK, then one could have something that applied the
filter to our normal images to provide people with the images you want,
while not require duplication of building and storage.
People could always confirm that they were getting the same result as
building without the nonfree firmware by doing it themselves, and
checking things matched.
Is that something that would work for you?

This is better, assuming the "doing it themselves" property is actually
confirmed.

Your idea is really clever!

My assumption all along has been that the presence of the non-free
firmware in the build process "taint" the resulting image in a way that
makes it impossible be able to 1) zero out the non-free firmware bits
from the resulting image, and at the same time 2) be able to separately
build a bit-by-bit identical image using only free software and that
this image would become identical to the zeroed out image.

But you made me realize this is not impossible at all, it is just a
Small Matter Of Programming.

You could turn this around: how about building the images without
non-free software, and replace the zerod out bits with the non-free
firmware on final preparation of the non-free images? Then your normal
build process is not tainted by the presence of non-free software.

I don't think the above fully resolve my concerns though. The mere
presence of official documented hooks to load non-free software is
problematic from a freedom perspective. They are the enabler of the
slippery slope that leads to including non-free software by default.

Meanwhile I looked into the debian-cd project to experiment with
building images myself. Why aren't the images built in a Salsa
pipeline? Yes I understand that 20 years ago the resources required to
build the images were large. But today people build large projects in
GitHub Actions. What artifact size are we talking about? Looking at
the summary of official images at https://www.debian.org/CD/http-ftp/ it
seems like around 50GB? What is the build time on a powerful machine?
I would start to worry about the design feasability of running this in a
pipeline when the total size of artifacts from a single build is larger
than 4TB or if a single serialized job would have to run for more than a
couple of days. I'm probably missing some combinatorical explosion of
varaints that increase the total size, but there is also no requirement
that all images are built like this. I would be satisfied if the
"netinst" variant for all architectures could be reproduced from purely
free software, in a Salsa pipeline, and that seems to be a 5-10GB
artifact unless my math is off.

I worry that the builds require other non-reproducible/free steps
though. A signed boot shim where the private key is not replaceable by
a user-controlled key is equally problematic as non-free firmware.
Trisquel and Guix avoids these, and I recall seeing stuff like that in
Debian -- https://tracker.debian.org/pkg/shim-signed -- but it is good
to know that we have more things to work.

/Simon

[Ansgar 🙀]

Hi,

I don't think the above fully resolve my concerns though.  The mere
presence of official documented hooks to load non-free software is
problematic from a freedom perspective.

Maybe a "free" version of Debian could be provided with all of
/usr/share/doc/*, /usr/share/man/* and similar removed? And of course
any references to FSF-provided documentation...

But I guess this also answers my other question: removing references to
non-free firmware to make them disappear is clearly freewashing.

"Ignorance is strength^Wfreedom."

Ansgar

[Peter B]

.... in a Salsa pipeline, and that seems to be a 5-10GB
artifact unless my math is off.

Hi Simon,

sadly, Salsa pipelines will only handle up to 250MB,
a long way short of even 5GB !

https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/389


Cheers,
Peter

[Steve McIntyre]

Post by Simon Josefsson

Post by Philip Hands
Let's say that we could make that image bit-for-bit reproducible with an
image that was produced by taking the normal with-nonfree-firmware
image, and filtering it somehow (e.g. overwriting the non-free bits with
zeros, say).
Would you object if the normal way of generating the image was to apply
the filter, rather than build it in parallel?
If that would be OK, then one could have something that applied the
filter to our normal images to provide people with the images you want,
while not require duplication of building and storage.
People could always confirm that they were getting the same result as
building without the nonfree firmware by doing it themselves, and
checking things matched.
Is that something that would work for you?

Yeesh. That gets messy - live images include firmware in the squashfs,
for example. Simply replacing things with zeroes is not *quite* enough
here.

...

Post by Simon Josefsson
I don't think the above fully resolve my concerns though. The mere
presence of official documented hooks to load non-free software is
problematic from a freedom perspective. They are the enabler of the
slippery slope that leads to including non-free software by default.

Sigh. That's the same argument for removing the option to even load
firmware. We must be *so* sure of purity that we can't even
acknowledge that users might need to use/run anythinh that we don't
consider pure enough. Let's stop them!

Post by Simon Josefsson
Meanwhile I looked into the debian-cd project to experiment with
building images myself. Why aren't the images built in a Salsa
pipeline? Yes I understand that 20 years ago the resources required to
build the images were large. But today people build large projects in
GitHub Actions. What artifact size are we talking about? Looking at
the summary of official images at https://www.debian.org/CD/http-ftp/ it
seems like around 50GB?

Haha, no. Using the last bookworm release as a guide, we created a
grand total of 284 images (mix of d-i and live) totalling ~1.7T.

Post by Simon Josefsson
What is the build time on a powerful machine?

That build took ~4h end-to-end on casulana,d.o, which I believe is the
project's biggest server box. The build process needs a complete local
mirror and a *lot* of I/O and CPU.

Post by Simon Josefsson
I would start to worry about the design feasability of running this in a
pipeline when the total size of artifacts from a single build is larger
than 4TB or if a single serialized job would have to run for more than a
couple of days. I'm probably missing some combinatorical explosion of
varaints that increase the total size, but there is also no requirement
that all images are built like this. I would be satisfied if the
"netinst" variant for all architectures could be reproduced from purely
free software, in a Salsa pipeline, and that seems to be a 5-10GB
artifact unless my math is off.
I worry that the builds require other non-reproducible/free steps
though. A signed boot shim where the private key is not replaceable by
a user-controlled key is equally problematic as non-free firmware.
Trisquel and Guix avoids these, and I recall seeing stuff like that in
Debian -- https://tracker.debian.org/pkg/shim-signed -- but it is good
to know that we have more things to work.

Sigh.

[Marc Haber]

Post by Simon Josefsson
My hope is that the sentiments
towards fully free installer images will change in the Debian project
and that they eventually may be official again.

I don't see sentiments towards fully free isntaller images. There is
just nobody who wants to build them. I THINK that they might become
official some day if somebody steps up, does the work and shows that
they are willing to do that for at least one release cycle.

Until nobody is there who is willing to do the work, it is moot to
discuss whether those images could be official or not. If they don't
exist, they won't be official. Easy.

I still haven't heard arguments why people refuse to use an installer
that comes with non-free firmware, asks whether this firmware should be
used, and if answered "no", none of this non-free firmware ends up in
the installed system. The resulting system is free regardless whether
there was non-free firmware on the installation images.

Greetings
Marc

[Simon Josefsson]

Post by Marc Haber
I still haven't heard arguments why people refuse to use an installer
that comes with non-free firmware, asks whether this firmware should
be used, and if answered "no", none of this non-free firmware ends up
in the installed system. The resulting system is free regardless
whether there was non-free firmware on the installation images.

https://www.gnu.org/distros/optionally-free-not-enough.html

https://www.gnu.org/philosophy/install-fest-devil.html

The arguments are available but not everyone is convinced by them.
Similar to that the arguments for free software exists but not everyone
is convinced by those arguments and instead prefer proprietary software.

/Simon

[Marc Haber]

On Mon, 10 Mar 2025 11:56:28 +0100, Simon Josefsson

Post by Simon Josefsson

Post by Marc Haber
I still haven't heard arguments why people refuse to use an installer
that comes with non-free firmware, asks whether this firmware should
be used, and if answered "no", none of this non-free firmware ends up
in the installed system. The resulting system is free regardless
whether there was non-free firmware on the installation images.

https://www.gnu.org/distros/optionally-free-not-enough.html
https://www.gnu.org/philosophy/install-fest-devil.html

No thank you.

Greetings
Marc

[Aurélien COUDERC]

Post by Simon Josefsson
https://www.gnu.org/distros/optionally-free-not-enough.html
https://www.gnu.org/philosophy/install-fest-devil.html

… of course … that's where the core of the disagreement lies !

We're not a religion, we're just building a distro.

I think you're looking for something else than Debian.


--
Aurélien

[Simon Josefsson]

Post by Simon Josefsson
https://www.gnu.org/distros/optionally-free-not-enough.html
https://www.gnu.org/philosophy/install-fest-devil.html


 of course 
 that's where the core of the disagreement lies !

Right, I think agreement (or disagreement) with those essays explains a
lot of what practical choices you make.

We're not a religion, we're just building a distro.

I'm not sure what to make of that. Are you saying that Guix, Trisquel
etc who strive towards these concepts are not distro's?

One person's religion is another person's reasonable beliefs. I'm not
sure who has the authority to judge. I'm sure some would dismiss the
DFSG as religion, even if we happen to like it here.

It is fine for the Debian community to dismiss the arguments described
in the links above. This appears to be the case, although I hear some
voices that are open to change.

However if Debian dismiss those ideas, the argument that the fully free
installer doesn't exist because "nobody is working on this, go create
them and it will happen" does not seem valid to me. My reading is that
these images doesn't exist because Debian had a vote saying they should
not exist. I hope this will change in the future. Creating them won't
change the decision, but it may be input to renewed discussion.

/Simon

[Jonathan McDowell]

Post by Simon Josefsson
However if Debian dismiss those ideas, the argument that the fully free
installer doesn't exist because "nobody is working on this, go create
them and it will happen" does not seem valid to me. My reading is that
these images doesn't exist because Debian had a vote saying they should
not exist. I hope this will change in the future. Creating them won't
change the decision, but it may be input to renewed discussion.

Debian had a vote where we made it clear that we were ok with making use
of limited project + developer resources and only testing + shipping an
installer which also includes the non-free-firmware component. It wasn't
"this should not exist" it was "we're not trying to double your
workload, images team".

I've not seen _anyone_ suggest that the project would try and stop
someone from going off any building CD images that didn't include
non-free-firmware, just that we don't expect the existing images team to
have to expend more effort to make that happen.

J. - Bored of this argument going round in circles.

[Soren Stoutner]

Post by Simon Josefsson

Post by Simon Josefsson
https://www.gnu.org/distros/optionally-free-not-enough.html
https://www.gnu.org/philosophy/install-fest-devil.html


 of course 
 that's where the core of the disagreement lies !

Right, I think agreement (or disagreement) with those essays explains a
lot of what practical choices you make.

We're not a religion, we're just building a distro.

I'm not sure what to make of that. Are you saying that Guix, Trisquel
etc who strive towards these concepts are not distro's?
One person's religion is another person's reasonable beliefs. I'm not
sure who has the authority to judge. I'm sure some would dismiss the
DFSG as religion, even if we happen to like it here.
It is fine for the Debian community to dismiss the arguments described
in the links above. This appears to be the case, although I hear some
voices that are open to change.
However if Debian dismiss those ideas, the argument that the fully free
installer doesn't exist because "nobody is working on this, go create
them and it will happen" does not seem valid to me. My reading is that
these images doesn't exist because Debian had a vote saying they should
not exist. I hope this will change in the future. Creating them won't
change the decision, but it may be input to renewed discussion.

I want to say that I agree with Simon on this.

What we really need is the open hardware movement to catch up with the open software
movement. That will take 20 to 30 years as the open hardware movement is just getting
started. As many people have already pointed out, in most cases it isn’t practical to
operate the hardware that is generally available without the use of non-free firmware. My
sense is the majority of these people, perhaps all of them, are not saying they prefer
hardware with non-free firmware or that they don’t support the ideals of the open
hardware movement. Rather, they are making a pragmatic statement of the current state
of affairs.

To a certain degree, promoting official installer images without non-free firmware next to
installer images with non-free firmware can raise awareness of the problem. To another
degree, it probably wouldn’t do anything right now except confuse some subset of users
and require extra effort from those generating the images. Debian is simply too small of
an organization to make a very big splash by such a move.

As has already been mentioned, nothing of substance has changed since Debian held a GR
on this issue. However, if down the road open hardware with free firmware became more
widely available (I’m looking at you, RISC-V, although I understand that the most likely
short-term outcome is that companies will produce non-free firmware for their RISC-V
processors), then it might be worth reopening the issue for consideration.

[Andrey Rakhmatullin]

Post by Soren Stoutner
To a certain degree, promoting official installer images without non-free firmware next to
installer images with non-free firmware can raise awareness of the problem. To another
degree, it probably wouldn’t do anything right now except confuse some subset of users
and require extra effort from those generating the images. Debian is simply too small of
an organization to make a very big splash by such a move.

You don't really need to generate those images, as they are equally
unusable to most users whether they exist or not. Unless I guess you want
people to try them to learn a lesson that their hardware is not working
without non-free firmware?

Post by Soren Stoutner
As has already been mentioned, nothing of substance has changed since Debian held a GR
on this issue. However, if down the road open hardware with free firmware became more
widely available (I’m looking at you, RISC-V, although I understand that the most likely
short-term outcome is that companies will produce non-free firmware for their RISC-V
processors), then it might be worth reopening the issue for consideration.

That's just processors though, and processors usually contain their
non-free firmware anyway. The original issue was about hardware that
doesn't contain firmware but wants it loaded from the OS.

[Soren Stoutner]

On Wednesday, March 12, 2025 12:11:37 AM Mountain Standard Time Andrey

Post by Andrey Rakhmatullin

Post by Soren Stoutner
As has already been mentioned, nothing of substance has changed since Debian
held a GR on this issue. However, if down the road open hardware with free
firmware became more widely available (I’m looking at you, RISC-V, although
I understand that the most likely short-term outcome is that companies will
produce non-free firmware for their RISC-V processors), then it might be
worth reopening the issue for consideration.

That's just processors though, and processors usually contain their
non-free firmware anyway. The original issue was about hardware that
doesn't contain firmware but wants it loaded from the OS.

That’s a good point. RISC-V isn’t only being used as main CPUs, but also for all types of
other things that require firmware. For example, Western Digital is spending effort to
bring RISC-V to their storage controllers.

https://blog.westerndigital.com/risc-v-swerv-core-open-source/

The salient point is that the open hardware movement is just in its infancy and it is going
to be a long time before there are common production machines that can run securely
and well without the need to use and update proprietary firmware.

RISC-V has the potential to replace a lot of the current ARM micro controllers. RISC-V uses
a permissive license, somewhat akin to the Apache 2.0 License in the sense that anyone
who builds upon it can decide if they want the outcome of their work to be open or closed.
So, some RISC-V chips will ship with open hardware schematics and information and
others won’t. In addition, even if someone chooses to ship open hardware RISC-V, that
doesn’t mean they will provide the source information for the corresponding firmware, so
you could end up with a situation where there is an open hardware chip running non-free
firmware.

But it is a beginning, and some day we will probably see wireless chips and ethernet chips
and GPUs and TPMs and everything else shipping open hardware running open firmware.
At that point, it will be easy to advocate for installers that match.

Of course, there is nothing preventing companies from adopting free and open firmware
running on closed hardware. That is the current situation for most if not all of the free
firmware currently shipping in Debian. But my personal opinion is that the free firmware
movement won’t take off without the open hardware movement.

[Andrey Rakhmatullin]

Post by Simon Josefsson

Post by Marc Haber
I still haven't heard arguments why people refuse to use an installer
that comes with non-free firmware, asks whether this firmware should
be used, and if answered "no", none of this non-free firmware ends up
in the installed system. The resulting system is free regardless
whether there was non-free firmware on the installation images.

https://www.gnu.org/distros/optionally-free-not-enough.html
https://www.gnu.org/philosophy/install-fest-devil.html

I've missed the second link initially, so I'll quote it for people who
missed it too or decided not to click:

"""
My new idea is that the install fest could allow the devil to hang
around, off in a corner of the hall, or the next room. (Actually, a
human being wearing sign saying “The Devil,” and maybe a toy mask or
horns.) The devil would offer to install nonfree drivers in the user's
machine to make more parts of the computer function, explaining to the
user that the cost of this is using a nonfree (unjust) program.

The install fest would tolerate the devil's presence but not officially
sponsor the devil, or publicize the devil's availability. Therefore, the
users who accept the devil's deal would clearly see that the devil
installed the nonfree drivers, not the install fest. The install fest
would not be morally compromised by the devil's actions, so it could
retain full moral authority when it talks about the imperative for
freedom.

Those users that get nonfree drivers would see what their moral cost is,
and that there are people in the community who refuse to pay that cost.
They would have the chance to reflect afterwards on the situation that
their flawed computers have put them in, and about how to change that
situation, in the small and in the large.
"""

[Ansgar 🙀]

Hi,

Post by Simon Josefsson

Post by Ansgar 🙀
Hi,

Post by Simon Josefsson
Our experience seems to differ, I now run Trisquel and Guix on many of
my home and machines and servers.  For my uses they all work without
non-free firmware.  You have to be careful about what hardware you buy,
and chose your use-cases.  And, yes, I use modern hardware -- i9-14900K
on desktop, i7 1260P and Ultra 155H in my two most used laptops,
ARS-111M-NR and Talos II on the server side, as well as a bunch of aging
Dell R630's.

This class of hardware *requires* non-free firmware. Lots of it, at
every system layer.

Agreed.

So we agree that pretty much all hardware requires non-free firmware
these days.

Post by Simon Josefsson
However none of that hardware require me to load non-free
firmware from my operating system, which is my point.  That situation is
sufficient for me to accept to use the hardware and install an operating
system built without non-free software on it.

What is the point of this then?

Does it help users to replace/rewrite non-free firmware if it is not
supplied by the operating system? Or enable the user to not use non-
free firmware? I don't think so.

The only other reason to do this seems to be free/libre-washing by
pretending the non-free firmware is not there... But I don't think that
is something useful to spend resources on (but if people want to do so
for unofficial installer images, they are of course free to do so; as
far as I understand the FSF is in favor of free/libre-washing).

Or is there some other reason to want to do this?

Ansgar

[Simon Josefsson]

Post by Ansgar 🙀
Hi,

Post by Simon Josefsson

Post by Ansgar 🙀
Hi,

Post by Simon Josefsson
Our experience seems to differ, I now run Trisquel and Guix on many of
my home and machines and servers.  For my uses they all work without
non-free firmware.  You have to be careful about what hardware you buy,
and chose your use-cases.  And, yes, I use modern hardware -- i9-14900K
on desktop, i7 1260P and Ultra 155H in my two most used laptops,
ARS-111M-NR and Talos II on the server side, as well as a bunch of aging
Dell R630's.

This class of hardware *requires* non-free firmware. Lots of it, at
every system layer.

Agreed.

So we agree that pretty much all hardware requires non-free firmware
these days.

Right, in the sense that they embed non-free software in the hardware.

None of those machines require them to be loaded by me as a user for
them to be useful to me.

This distinction is important to me.

Post by Ansgar 🙀

Post by Simon Josefsson
However none of that hardware require me to load non-free
firmware from my operating system, which is my point.  That situation is
sufficient for me to accept to use the hardware and install an operating
system built without non-free software on it.

What is the point of this then?

For me there are several reasons for wanting this, which ought to be
understandable for anyone reading this thread. The supply-chain
security trust concern of non-free firmware is a hot topic right now.

It is fine to disagree that these are concerns worthy spending time on
within the Debian project, which is my perception of the vote outcome.

/Simon

[Jeremy Stanley]

On 2025-03-09 17:17:52 +0100 (+0100), Simon Josefsson wrote:
[...]

Post by Simon Josefsson
Right, in the sense that they embed non-free software in the
hardware.
None of those machines require them to be loaded by me as a user
for them to be useful to me.
This distinction is important to me.

[...]

Post by Simon Josefsson
For me there are several reasons for wanting this, which ought to
be understandable for anyone reading this thread. The
supply-chain security trust concern of non-free firmware is a hot
topic right now.

[...]

Isn't there also a similar concern for keeping security
vulnerabilities patched, even if they occur in the embedded non-free
firmware that shipped on your hardware? Do you patch such vulnerable
firmware manually when you happen to spot a news article about it,
or just try to ignore vulnerabilities in firmware along with
ignoring the presence of firmware?

If you patch your firmware, do you find the process of doing so
manually simple enough not to warrant assistance from your operating
system?

Note that if you don't trust your operating system to not install
compromised firmware, then perhaps consider looking a different
operating system you do trust. Your operating system has the
capacity to install new firmware behind your back regardless of
whether or you're personally okay with it doing so.

[Marc Haber]

On Sun, 09 Mar 2025 17:17:52 +0100, Simon Josefsson

Post by Simon Josefsson
Right, in the sense that they embed non-free software in the hardware.
None of those machines require them to be loaded by me as a user for
them to be useful to me.
This distinction is important to me.

I find the version where I can choose whether to use the firmare or
not superior to not having the choice.

Post by Simon Josefsson
For me there are several reasons for wanting this, which ought to be
understandable for anyone reading this thread.

It isn't. I am too stupid to understand that from the explanaition
given.

Post by Simon Josefsson
The supply-chain
security trust concern of non-free firmware is a hot topic right now.

I would place less trust on the firmware that is on the device while
it rides the supply chain from the factory to my place.

Post by Simon Josefsson
It is fine to disagree that these are concerns worthy spending time on
within the Debian project, which is my perception of the vote outcome.

There are not concerns about spending time. There are no people
willing to do so.

Greetings
Marc

[Simon Richter]

Hi,

Post by Marc Haber

Post by Simon Josefsson
It is fine to disagree that these are concerns worthy spending time on
within the Debian project, which is my perception of the vote outcome.

There are not concerns about spending time. There are no people
willing to do so.

This is, however, a long term problem.

The current state where we have free software drivers for a lot of
hardware is the result of a lot of people investing a lot of time into
creating them.

In the same way, we need to do both: support our current users by
allowing them to use non-free firmware with their current hardware,
*and* push for new devices to have free firmware.

Part of that push is informing users that what we do wrt firmware is
best-effort, support for their hardware can be dropped at any point and
the free software community cannot put them in control of their
computing experience.

We're not obligated to validate their questionable choices in buying
hardware that ships with non-free firmware, or apologize for the bad
experience they have when upstream changes something they don't like. It
is not our duty as volunteers to compensate for the shortcomings of
companies, especially companies that use our volunteer time without
compensation -- we're the *free* software community, not the *gratis*
software community.

Simon

[Andrey Rakhmatullin]

Post by Simon Richter
The current state where we have free software drivers for a lot of
hardware is the result of a lot of people investing a lot of time into
creating them.
In the same way, we need to do both: support our current users by
allowing them to use non-free firmware with their current hardware,
*and* push for new devices to have free firmware.
Part of that push is informing users that what we do wrt firmware is
best-effort, support for their hardware can be dropped at any point
and the free software community cannot put them in control of their
computing experience.
We're not obligated to validate their questionable choices in buying
hardware that ships with non-free firmware, or apologize for the bad
experience they have when upstream changes something they don't like.
It is not our duty as volunteers to compensate for the shortcomings of
companies, especially companies that use our volunteer time without
compensation -- we're the *free* software community, not the *gratis*
software community.

This is also an old argument. Some rebuttals included "this didn't work so
far", "good luck getting fully open firmware in sectors where it's
literally impossible" and "please don't call things users have no choice
over "questionable choices"".

[Simon Richter]

Hi,

Post by Andrey Rakhmatullin

Post by Simon Richter
We're not obligated to validate their questionable choices in buying
hardware that ships with non-free firmware, or apologize for the bad
experience they have when upstream changes something they don't like.
It is not our duty as volunteers to compensate for the shortcomings of
companies, especially companies that use our volunteer time without
compensation -- we're the *free* software community, not the *gratis*
software community.

This is also an old argument. Some rebuttals included "this didn't work
so far", "good luck getting fully open firmware in sectors where it's
literally impossible" and "please don't call things users have no choice
over "questionable choices"".

That's my point though: the exact same rebuttals were presented in the
1990ies about getting drivers under a free license, and yet here we are,
with excellent driver support for all but a few holdouts that users
understand to be problematic due to the politics of the vendors.

We've reached the point where people are shitting on nV for the quality
of their drivers, and a kernel that has closed-source drivers loaded is
"tainted", and the last release in which we shipped ndiswrapper was buster.

This happened precisely because of free software zealotry. Free firmware
will happen the same way: by users understanding that non-free offerings
are inferior because you need to live with all the flaws they have --
and a large part of that is that the free software community is not
apologizing for the experiences users have with closed-source drivers.

Simon

[Marc Haber]

Post by Simon Richter
We've reached the point where people are shitting on nV for the
quality of their drivers, and a kernel that has closed-source drivers
loaded is "tainted", and the last release in which we shipped
ndiswrapper was buster.

That happened because those solutions were all incredibly painful,
depending on the kernel version in use, losing compatibly during every
second kernel upgrade, and didn't work cross-architecture. Users hated
that.

non-free firmware is silent and painless. Users don't care.

tl;dr: The situation is totally different, we should not compare apples
and peaches here.

Greetings
Marc

[Jonas Smedegaard]

Quoting Marc Haber (2025-03-10 13:38:05)

Post by Marc Haber

Post by Simon Richter
We've reached the point where people are shitting on nV for the
quality of their drivers, and a kernel that has closed-source drivers
loaded is "tainted", and the last release in which we shipped
ndiswrapper was buster.

That happened because those solutions were all incredibly painful,
depending on the kernel version in use, losing compatibly during every
second kernel upgrade, and didn't work cross-architecture. Users hated
that.
non-free firmware is silent and painless. Users don't care.
tl;dr: The situation is totally different, we should not compare apples
and peaches here.

Back then some users didn't care to fix things and some found it worthy
of pouring hard work into.

Similar today.

- Jonas

[Andrey Rakhmatullin]

their questionable choices in buying hardware that ships with non-free
firmware

Is there hardware that ships with free firmware? Seriously.

Yeah, I think that should read "requires", not "ships with". Shipping with
is, as explained in other emails, is good.

[Bjørn Mork]

their questionable choices in buying hardware that ships with non-free
firmware

Is there hardware that ships with free firmware? Seriously.


Bjørn

[Michael Stone]

Post by Simon Richter
We're not obligated to validate their questionable choices in buying
hardware that ships with non-free firmware

There are a lot of competing priorities here, and it's the height of
arrogance to be so certain that one's own opinion is best as to try to
prevent other people from making their own decisions by hiding even the
existence of a mechanism to install debian on their machine.

[Geert Stappers]

Post by Michael Stone

Post by Simon Richter
We're not obligated to validate their questionable choices in buying
hardware that ships with non-free firmware

There are a lot of competing priorities here, and it's the height of
arrogance to be so certain that one's own opinion is best as to try to
prevent other people from making their own decisions by hiding even the
existence of a mechanism to install debian on their machine.

Simon,


Do know that is OK that there are differences in view, opinion,
standpoint, approaches, ideas and whatever.


And do know that the best thing to get the holy installer,
is to (start to) building it.



Groeten
Geert Stappers
Debian Developer,
Voted for 'Lets stop with telling "With the non-free-firmware ISO
would have your install through WIFI succesed"'

[Simon Josefsson]

Post by Andrew M.A. Cater

Post by Michael Stone

Post by Simon Richter
We're not obligated to validate their questionable choices in buying
hardware that ships with non-free firmware

There are a lot of competing priorities here, and it's the height of
arrogance to be so certain that one's own opinion is best as to try to
prevent other people from making their own decisions by hiding even the
existence of a mechanism to install debian on their machine.

Simon,
Do know that is OK that there are differences in view, opinion,
standpoint, approaches, ideas and whatever.

FWIW, I didn't write what you quoted above, so please check your
attributions.

/Simon

[Ansgar 🙀]

Hi,

Post by Ansgar 🙀
What is the point of this then?

If I understood the argument of FSF correctly, the point is, having the
same freedom as the hardware manufacturer to modify or not modify.In
case of hardware without firmware (or fused firmware that cannot be
modified further), this argument has some merit, I think. But if it
needs firmware to function, I think argument is hardware manufacturers
having more power than you to modify firmware.

No, the hardware manufacturer has more power with preinstalled firmware
as well: they can more easily provide updates for on-board ROMs as
well. (You can ship ROMs just like a USB media for OS-provided firmware
images; it is just a different media.)

It is all about where you want to draw the line between the hardware and
software. [...] So for hardware we are willing to give more
power to manufacturers, but not for software.

So we just declare software as hardware and suddenly it is "free"?
Cool, then the preinstalled Windows is free (in the FSF "respects your
freedom" sense) too if I don't install updates. :-)

Post by Ansgar 🙀
Does it help users to replace/rewrite non-free firmware if it is not
supplied by the operating system? Or enable the user to not use non-
free firmware? I don't think so.

In a weird way, if you don't update the firmware, then no one has the
ability to modify.

Who is "you"? The user can choose what firmware version they want to
install with OS-supplied firmware. If they don't like a newer version,
they can just provide an older one to the hardware.

Pretty much all firmware in non-free has no provisions that you have to
use the newest version as that would be a problem for Debian to
organize...

So how does this change depending on where the firmware is stored?

Basically hardware manufacturers are withholding code that they could
give you easily, at least from the point of view of actually making use
of it.

They can also give you the hardware schematics easily so you can
install it in a FPGA instead of their provided chips. (And what when
the firmware is programming for a FPGA?) That would make modifying the
hard- and firmware easier ;-)

The actual hardware design may not be as useful like firmware as
modifying that will still require ability to manufacture, but for
firmware you already have the ability to use modified version.

Debian doesn't decide what is free or not free based on what the user
is capable of doing. For some experienced hardware developer, modifying
the hardware schematics can be easier than modifying software code.

Otherwise we should factor in the programming language used in free vs
non-free which would make most shell code non-free as it is too hard to
modify in a safe way. ;-)

Post by Ansgar 🙀
The only other reason to do this seems to be free/libre-washing by
pretending the non-free firmware is not there... But I don't think that
is something useful to spend resources on (but if people want to do so
for unofficial installer images, they are of course free to do so; as
far as I understand the FSF is in favor of free/libre-washing).
Or is there some other reason to want to do this?

In an academic way, this gives user same freedom as the hardware
manufacturer - no one is able to modify the hardware (if you never
update the firmware yourself). So the hardware manufacturer don't have
control over your hardware, after you received it.

If you give root to the hardware manufacturer to manage firmware files
on your computer, then they have control. Firmware updates don't
magically arrive on your hard disk unless you either install them or
someone sneakily breaks into your computer.

From a purely academic way, we might also discuss hidden wireless

backdoors in hardware with pre-installed firmware. There pre-installed
firmware is even worse as it is harder to find backdoors if you can't
even look at the proprietary binary code.

So the value of this is, looking at your ability to easily modify, do we
have the freedom to modify?

So not providing firmware via the operating system gives users the
freedom to modify firmware? I don't follow.

Ansgar

[Stephan Verbücheln]

Basically hardware manufacturers are withholding code that they could
give you easily

It is often not that easy because of stupid laws, for example laws that
require vendors of radio devices to restrict the frequency range. That
is often used as an excuse to not publish sources.

But I totally agree that this is a deficiency. Non-free firmware should
not exist.

Regards

[Michael Stone]

Post by Matthias Urlichs
Another way to look at this outcome, and the one I personally prefer
by a wide margin, is that it'd be very cool to have them, but at this
time their utility is … questionable, given that I personally own zero
(out of umpteen) computers that would work with such an image.

And because if someone wants to avoid non-free firmware they can install
on a computer that doesn't require it--meaning that no non-free firmware
can/will be loaded. So the entire benefit of this exercise is to not
have "icky non-free firmware" sitting unused on the install media. That
seems like an utterly trivial result which can't possibly justify the
level of effort involved.

As when this came up originally, I do not understand how it can be
considered "freer" to actively prevent people from having an option,
when those who don't want that option can simply not use it.

[Andrew M.A. Cater]

Post by Bill Allombert

In the original GR, one of the options that lost was for Debian to host two sets of installer
images, one with non-free firmware and one without, and for users to be able to make an
informed decision before downloading the installer.
https://www.debian.org/vote/2022/vote_003#textc
This option did not prevail in the vote, but it would have been my preferred choice (I was
not a Debian Developer at the time and so did not vote, but I did follow the discussion).

True, but the GR does not prevent Debian of providing a second set of
installer images. What is required is someone to do the work, as usual.

For anyone interested - others will happily provide instructions as
needed but may not wish to carry out the work involved themselves,
having already done this for some years:

Please feel free to pick up the code and generate the second set of
installer images, maintaining the code to exclude non-free-firmware.
Don't forget to also do this for debian live media images and
coordinate this for all architectures,while ensuring that these are
reproducible.

Please also be prepared to deal with the number of users who complain
that the installer doesn't work for them because they no longer have
sound, WiFi or whatever. Please be prepared to help them install
tarballs of non-free firmware as appropriate to solve each issue raised.
Don't forget to coordinate wiki and Debian web site edits accordingly.

Please also be prepared to carry out release testing for each image that
is not including firmware per point release every couple of months -
I'm assuming you'll be more than happy to check twenty or thirty tests of
images yourself.
[This last should only take about four hours if you can persuade others to
help but may take longer if you are working on your own].

Thank you for volunteering to carry out these tasks.

With every good wish, as ever,

Andy Cater

Post by Bill Allombert
Cheers,
--
Imagine a large red swirl here.

[Jeremy Stanley]

On 2025-03-07 19:33:53 +0100 (+0100), Simon Josefsson wrote:
[...]

The recent AMD Microcode vulnerability is a good case-study on the
https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking
There is no way for me as a user to audit that the Debian
installer images is not including vulnerable microcode, since
source code for the firmware is not available.

[...]

Note that there's similarly no way for you as a user to audit the
microcode that shipped with your processor, and without Debian
supplying microcode updates it would be on you to track security
announcements from the hardware vendor and update it yourself with
the same inscrutable blobs (or not update it, I guess that's also a
choice).

In theory, the work required to check that microcode updates
supplied through nonfree-firmware match official vendor checksums
would be roughly the same as if you fetched them from the hardware
vendor to install manually yourself.

[Simon Josefsson]

I urge Debian to rethink its decision to officially include non-free
firmware and correct the social contract. Instead of making non-free
firmware the default, Debian should ensure that users consciously
choose to install it while being made aware of the implications.

I agree and would personally come back to use Debian on some of my
laptops if there was a supported way to install Debian from official
installer images that did not promote non-free software by including
firmware on them.

The recent AMD Microcode vulnerability is a good case-study on the
dangers of permitting non-free code to run on your CPU:

https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking

There is no way for me as a user to audit that the Debian installer
images is not including vulnerable microcode, since source code for the
firmware is not available.

My perception is that the Debian developer community rejected this, and
I'm not sure people are ready to reconsider just yet (the trend seems to
be the opposite way). Fortunately there are good libre alternatives in
Trisquel and Guix available for recommendation meanwhile.

/Simon

[Bill Allombert]

I urge Debian to rethink its decision to officially include non-free
firmware and correct the social contract. Instead of making non-free
firmware the default, Debian should ensure that users consciously
choose to install it while being made aware of the implications.

I agree and would personally come back to use Debian on some of my
laptops if there was a supported way to install Debian from official
installer images that did not promote non-free software by including
firmware on them.
The recent AMD Microcode vulnerability is a good case-study on the
https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking

Do not fall for the marketing. What was broken was the DRM which
forbid you to fix the firmware on your own CPU. This is no more a
vulnerability than letting you boot your own OS.

Cheers,

[Simon Josefsson]

Post by Bill Allombert

I urge Debian to rethink its decision to officially include non-free
firmware and correct the social contract. Instead of making non-free
firmware the default, Debian should ensure that users consciously
choose to install it while being made aware of the implications.

I agree and would personally come back to use Debian on some of my
laptops if there was a supported way to install Debian from official
installer images that did not promote non-free software by including
firmware on them.
The recent AMD Microcode vulnerability is a good case-study on the
https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking

Do not fall for the marketing. What was broken was the DRM which
forbid you to fix the firmware on your own CPU. This is no more a
vulnerability than letting you boot your own OS.

My point was that there is no reasonable way to gain confidence about
security properties of any piece of non-free microcode. Everyone can
now produce AMD microcode that corrupts your machine in advanced ways
that evade detection, but we don't know if such malicious corruption is
included in the official microcode. Having source code for the
microcode would help gain confidence in it, and is the reasonable
request. If the request is denied, I would consider the vendor not
trustworthy and look into options.

This is a similar vulnerability as installing a non-free operating
system like Windows. You essentially have to trust the vendor to
provide you with software, which you have no good way of auditing and
ultimately end up in their control. It wouldn't be a big problem if
software were free of vulnerabilities and never needed updates, but just
like Windows has had bugs, microcode have bugs.

https://www.gnu.org/philosophy/free-software-even-more-important.html

/Simon

[Aurélien COUDERC]

Post by Simon Josefsson
Having source code for the
microcode would help gain confidence in it, and is the reasonable
request. If the request is denied, I would consider the vendor not
trustworthy and look into options.

How about you try asking the vendors for that instead of speculating ?

Unless you come back with very unexpected good news you definitely need to look for alternatives.

As for Debian as a project we've voted on the topic not so long ago and decided we want to ship available firmware with the default installer. I don't see which new bits of information would make us vote differently now.


Happy hacking,
--
Aurélien

[Andrey Rakhmatullin]

If you don't trust the vendor, then it makes no difference whether or not new
official firmware/microcode can be uploaded/flashed or not. If you don't trust
the vendor, then the initial microcode that came with your device might already
be doing things that go against your interests.
Of course we cannot have much confidence in a piece of microcode of which we do
not have the source code. But we also cannot have much confidence in a piece of
hardware with non-flashable firmware of which we don't have the vhdl/verilog
sources. So what is the difference?

This is an old argument that didn't work for people holding this opinion
before and do I wouldn't expect it to work now. I don't expect that
people's opinions on this matter can be changed.

[Andrey Rakhmatullin]

Post by Andrey Rakhmatullin

If you don't trust the vendor, then it makes no difference whether or not new
official firmware/microcode can be uploaded/flashed or not. If you don't trust
the vendor, then the initial microcode that came with your device might already
be doing things that go against your interests.
Of course we cannot have much confidence in a piece of microcode of which we do
not have the source code. But we also cannot have much confidence in a piece of
hardware with non-flashable firmware of which we don't have the vhdl/verilog
sources. So what is the difference?

This is an old argument that didn't work for people holding this
opinion before and do I wouldn't expect it to work now. I don't expect
that people's opinions on this matter can be changed.

See?

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Simon Josefsson (2025-03-08 13:43:26)

Post by Simon Josefsson
My point was that there is no reasonable way to gain confidence about
security properties of any piece of non-free microcode. Everyone can now
produce AMD microcode that corrupts your machine in advanced ways that evade
detection, but we don't know if such malicious corruption is included in the
official microcode. Having source code for the microcode would help gain
confidence in it, and is the reasonable request. If the request is denied, I
would consider the vendor not trustworthy and look into options.

I do not understand something about this argument.

If you don't trust the vendor, then it makes no difference whether or not new
official firmware/microcode can be uploaded/flashed or not. If you don't trust
the vendor, then the initial microcode that came with your device might already
be doing things that go against your interests.

Of course we cannot have much confidence in a piece of microcode of which we do
not have the source code. But we also cannot have much confidence in a piece of
hardware with non-flashable firmware of which we don't have the vhdl/verilog
sources. So what is the difference?

If I don't trust vendor X, then I cannot buy hardware from them independent of
whether or not the vendor allows me to flash proprietary binary blobs from
them. If I do trust vendor X, then why would I not trust their proprietary
binary blobs?

I do not think you will find many on this list who will disagree with the
sentiment that it would be great if we had sources, schematics etc for many
more things. On the other hand, I don't think you can currently buy a device
that is capable to run, for example, a modern web browser and is fully open.
This is why I voted in the last GR as I did. I'm typing this on an MNT Reform
which is probably among the most open computers you can buy today but the chips
in it are *not* open silicon. Yes, it would be great if they were and it would
be great if the firmware blobs I need would not be proprietary. But I already
chose to trust the manufacturers of the chips in my laptop or otherwise I would
not be typing these lines. Why would I trust the silicone from vendor X and
distrust the firmware/microcode from vendor X? Having non-free-firmware enabled
by default in the Debian installer just continues pursuing a trust relationship
you already decided on entering when you bought the hardware, no?

Thanks!

cheers, josch

[Simon Josefsson]

Post by Johannes Schauer Marin Rodrigues
Hi,
Quoting Simon Josefsson (2025-03-08 13:43:26)

Post by Simon Josefsson
My point was that there is no reasonable way to gain confidence about
security properties of any piece of non-free microcode. Everyone can now
produce AMD microcode that corrupts your machine in advanced ways that evade
detection, but we don't know if such malicious corruption is included in the
official microcode. Having source code for the microcode would help gain
confidence in it, and is the reasonable request. If the request is denied, I
would consider the vendor not trustworthy and look into options.

I do not understand something about this argument.
If you don't trust the vendor, then it makes no difference whether or not new
official firmware/microcode can be uploaded/flashed or not. If you don't trust
the vendor, then the initial microcode that came with your device might already
be doing things that go against your interests.
Of course we cannot have much confidence in a piece of microcode of which we do
not have the source code. But we also cannot have much confidence in a piece of
hardware with non-flashable firmware of which we don't have the vhdl/verilog
sources. So what is the difference?

These are good questions and I believe that if you can see that there is
a difference between the two positions, it is easier to appreciate the
need for fully free operating systems, and that not offering fully free
Debian installer images (even as an option) is problematic.

Many years ago I also reacted the same way you and many others do --
"there is no difference between the act of loading non-free firmware
into my hardware and then using it compared to the act of using my
hardware that contains non-free software in it".

However I have come to realize that, yes, there is a significant and
fundamental difference between these two cases.

I'm not good at explaining this difference, and I believe the reason so
many still believe there is no differeence between these positions
suggests that we need better ways to articulate the difference. I'm
sure most people here are familiar with RMS' argument on this:

https://www.gnu.org/distros/free-system-distribution-guidelines.html

The way that I came to understand and appreciate the difference between
the act of loading non-free firmware into hardware, and the act of using
non-free firmware in hardware, is to first acknowledge that hardware is
different from software. Software people often think that their ideals
on how to design things should apply equally to hardware. Hardware
people often think the reverse. I've seen these patterns collide many
times, notably when I was involved with Yubico. The escape mechanism is
to acknowledge that there has to be different ideals. You don't have to
design hardware the way you design software, and vice versa. If you are
stuck applying the same ideals for both concepts, it is harder to work
out what is right for software and what is right for hardware
separately. And harder for experts to work efficiently within their own
area.

So what are good ideals for software? There are many patterns to
subscribe to, but I believe https://www.gnu.org/philosophy/free-sw.html
and https://www.gnu.org/distros/free-system-distribution-guidelines.html
are worthy to aspire to. Non-free firmware doesn't belong here.

I'm not a hardware person, so I'm less confident what good designs for
hardware should be, and it seems there is less consensus what the
desirable properties really are. One fundamental property that I would
like is that I want to be able to examine and modify all steps that
ultimately lead to production of the hardware. I'm sure there are more
properties that are desirable. It is easy to see that this is a
required but not sufficient condition: otherwise you can end up
producing a closed device ecosystem like an iPhone.

Post by Johannes Schauer Marin Rodrigues
If I don't trust vendor X, then I cannot buy hardware from them independent of
whether or not the vendor allows me to flash proprietary binary blobs from
them. If I do trust vendor X, then why would I not trust their proprietary
binary blobs?

One difference is that you could chose to trust their hardware (CPUs)
but don't trust their software (non-free firmware).

Consumer level protection in society is generally different when I buy a
hardware product compared to if I'm granted a license to use some
software. If I buy a bike or helmet it has to meet certain criteria for
it to be allowed to be sold (at least where I live) but different laws
apply if I use a piece of software under some legal terms of services.

Just because I place trust in entity X for the purpose of A doesn't mean
that I necessarily must trust entity X for the purpose of B. That is
the slippery slope that vendors want you to walk into so they can
excercise more control.

Post by Johannes Schauer Marin Rodrigues
I do not think you will find many on this list who will disagree with the
sentiment that it would be great if we had sources, schematics etc for many
more things. On the other hand, I don't think you can currently buy a device
that is capable to run, for example, a modern web browser and is fully open.
This is why I voted in the last GR as I did. I'm typing this on an MNT Reform
which is probably among the most open computers you can buy today but the chips
in it are *not* open silicon. Yes, it would be great if they were and it would
be great if the firmware blobs I need would not be proprietary. But I already
chose to trust the manufacturers of the chips in my laptop or otherwise I would
not be typing these lines. Why would I trust the silicone from vendor X and
distrust the firmware/microcode from vendor X? Having non-free-firmware enabled
by default in the Debian installer just continues pursuing a trust relationship
you already decided on entering when you bought the hardware, no?

Right, I see that if you don't appreciate the difference between these
two cases, it is reasonable and logical to regard non-free firmware as
unproblematic.

/Simon

[t***@tuxteam.de]

Post by Johannes Schauer Marin Rodrigues
Hi,
Quoting Simon Josefsson (2025-03-08 13:43:26)

Post by Simon Josefsson
My point was that there is no reasonable way to gain confidence about
security properties of any piece of non-free microcode. Everyone can now
produce AMD microcode that corrupts your machine in advanced ways that evade
detection, but we don't know if such malicious corruption is included in the
official microcode. Having source code for the microcode would help gain
confidence in it, and is the reasonable request. If the request is denied, I
would consider the vendor not trustworthy and look into options.

I do not understand something about this argument.
If you don't trust the vendor, then it makes no difference whether or not new
official firmware/microcode can be uploaded/flashed or not. If you don't trust
the vendor, then the initial microcode that came with your device might already
be doing things that go against your interests.

Trust in wendors (actually also their trustworthiness) is a function of
time. Remember when Github was bought by Microsoft? Remember when Twitter
was bought by -- uh -- whatever?

Cheers

[Stephan Verbücheln]

Am Samstag, dem 08.03.2025 um 14:51 +0100 schrieb Johannes Schauer

If you don't trust the vendor, then it makes no difference whether or
not new official firmware/microcode can be uploaded/flashed or not.
If you don't trust the vendor, then the initial microcode that came
with your device might already be doing things that go against your
interests.

The trust relationships are more complex than you put it. You have to
trust the chip vendors, the OEMs, the merchants, the delivery company,
the hotel room service etc. etc.
Since Snowden, we know that custom hardware bugs installed by anyone in
the supply chain are a real thing. The recommendation for risk groups
like journalists and lawyers nowadays is to buy random hardware from
the store and pay with cash.
However, I agree with you that we do not have a lot of options when it
comes to affordable consumer hardware. Even the various projects which
try to create openness still depend on proprietary firmware.
The situation is improving compared to what it used to be, but we still
have a long way to go.

Regards
Stephan

[Stephan Verbücheln]

The ideal laptop in my dreams is running pure Debian on a RISC-V CPU,
and all firmware from BIOS/EFI to peripheral devices has the source
code available with a license which allows the free-software community
to maintain it and remove undesired features.

Unfortunately, even though we are getting closer every year, we do not
have such hardware yet for the greater market for a reasonable price.
If you want to run an Intel- or AMD-based laptop, you have no choice
but to run their firmware, BIOS, EFI, microcode etc. More firmware is
required for video and network devices. Unfortunately, you cannot run
much of it without proprietary firmware, no matter if that firmware is
on the Debian CD or not.

Please note that firmware is something different than drivers. The best
option that I see at the moment with commodity hardware is to buy
hardware which does not require proprietary drivers. So at least the
main CPU and memory is free from undesired code. This is much easier
today then it used to be. I run my primary workstations without any
proprietary driver, application or library for years.

I really feel with you. I really wish there were more options without
proprietary firmware. But I not see any options.

The POWER9-based Raptor systems are advertised with free firmware, but
they use AMD video cards and Broadcom Ethernet. So I think that what
they mean by free firmware only applies to the BIOS/EFI. The coreboot
and libreboot projects also need some blobs for Intel and AMD based
systems.

Microcode is fortunately a thing of the past. It is an idea from the
1960's CISC design which is uncommon and unnecessary for RISC
processors. So the most important goal is to get develop laptop with
free EFI and free video firmware.

Regards
Stephan

[Stephan Verbücheln]

I acknowledge that some users—myself included—may need to install
non-free firmware for WiFi, Bluetooth, or graphics driver
I understand that users need proprietary drivers to run certain
hardware, and Debian should not ignore this reality.

Drivers and firmware are different things. There are no drivers in non-
free-firmware.

Regards

[Andrey Rakhmatullin]

I wonder if we get a reply from the OP or if this was just an attempt
to trigger a flame war. We will see...

Yup.