Hello Debian-Devel mailing list =D imho, an interesting topic. In conjunction with [1] my first notion was: We should not guide that proprietary software is insecure. That's not correct, i.e. in the case of non-free-firmware it is nearly equivalent to say that the usage of proprietary hardware is insecure.
Instead we need begin to define, what is hardware in a philosophic way
and then define an clear interface (or policy) between hard- and
software. I.e. in that interface it should be defined how software is
verifying that it runs on the correct hardware, like TPMs it do. Or I
could imagine that an verification-chain beginning from firmware-blobs
(loaded by driver) through the hardware which ends in the
kernel-module driver (back to driver, means the chain makes a
round-trip).
It is correct that also in that case it is not possible to understand
what is going on in the firmware itself. But from my knowledge, it is
an logistic issue to make firmware open source. Imagine you are
developing classical mainboards (equivalent to current SoC
development), then you need to provide the firmware of the chipset in
your mainboard driver. But you can imagine that the most chipset
companies don't like to provide the sources of the blobs, they just
specify how to load these into the chipset. In my opinion this is the
most relevant issue why most firmware is not available as open source.
In practice it means: If you have an favorite mainboard company, would
you like that these are able to modifying the blobs of the chipset
vendors? My clearly opinion is no.
Okay we could say: It is just required, that the chipset company needs
to sign it's blobs and then it can provide the sources of the
firmware. But
1. also in that case we need an verify-mechanism between soft- and
hardware.
2. it need's a kind of "Open Hardware" infrastructure.
Now we can go back to the philosophic point of view: If we have such
an interface between hard- and software then the open source software
is just one layer of a full-stack machine. You can install
proprietary software upon an purely open-source-system, also you can
have proprietary hardware blow an purely open-source-system. The
question is at which point begins hardware below such an purely
open-source-system.
If we really think, that firmware is software then need adapt our
vision (or policy, interface) at which point begins the hardware
layer.
Also, if we have such a well defined vision then this is not enough.
The next step needs to be to develop a vision (or policy) of "Open
Hardware" on which hardware companies can act.
Reference: [1] https://www.gnu.org/philosophy/compromise.html
End Of Opinion,
Dirk =D
On 3/7/25 6:35 PM, pan...@disroot.org wrote:
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 <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.htmlImagine hiding the “devil” by making it an official part of Debian. *Debian is Debian—the "devil" should not be an official part of it.*I would like to close with a modified stanza from the Free Software Song, which fits this situation perfectly: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
OpenPGP_0xE2A3766F21F02BD5.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
