Debian Begins A General Resolution To Decide What To Do With Non-Free Firmware

[stormcrow]

Why bother? FW that just sits there inertly on disk an is never loaded by any device isn't going to give your CPU cooties. At worst it's a slight waste of download bandwidth and disk space, though OTOH splitting up the FW's into a zillion packages comes with costs too.



Don't most free video drivers these days rely on proprietary firmware? IIRC Intel and AMD both do, and NVIDIA as well (open if you use the new openRM driver).

Yes. And many hardware devices that have viewable source code have closed firmware and hardware designs. It's the norm rather than the exception. Debian's stance one way or the other won't change that because it's purely a political stance and they have no real pull with corporations like ARM, Qualcomm, IBM, etc.

What really bugs me is the way some distros & project packagers try to tell people conclusively what the law says, which may very well be illegal itself in some jurisdictions - especially in the US. They can say "our lawyer has X opinion on this package". What they can't do is tell people definitively X license is incompatible with Y license so you shouldn't use it. Or they can say "because our lawyer said there's a legal problem with X package, we're not including it in our repository." But they can't say "You can't use X package because it's illegal to do so." At least, they aren't supposed to in jurisdictions where legal advice is restricted to licensed practitioners.

This is my opinion of the situation based on personal research (and it's only relevant to the US legal system). Take it or leave it. Ask a real copyright/IP lawyer if you're a maintainer or consumer of these products to find out what your own national and local laws say on the subject. Don't assume you know, and definitely don't assume the legal blurbs some of these packages trigger before you can install them are even accurate or enforceable.

[brad0]

a better option would be to actually work on developing free firmware instead of wasting so much effort on handwringing over non-free firmware.

but at least Debian doesn't go out of their way to make development of free firmware more difficult like the FSF does.

Easier said than done. The few projects that try to do so tend to not complete the task.

[kevmif]

As I understand it, modern hardware has really blurred the line between firmware and drivers.

Perhaps someone who understands the relationship a little better could explain it in a nicer way, but as I understand it, firmware should be shipped on the device, not needed to be manually loaded at boot time. What should be loaded at boot time, is the driver, so the OS understands how to interact with the hardware.

Important to push back on this or before we know it, open source distros will start shipping closed source drivers by default due to no other option to make the hardware 'work'.

[brad0]

firmware should be shipped on the device, not needed to be manually loaded at boot time.

Your understanding is so far off. That's a bizarre assumption at best and has nothing to do with modern hardware.

[kevmif]

Your understanding is so far off. That's a bizarre assumption at best and has nothing to do with modern hardware.

Fair enough. So the OS needs to load the firmware to tell the hardware how to work, then the drivers, to tell the OS how to interface with the hardware? Is that right?
Cause to me, that seems bizarre. Why is the firmware not built in to the hardware and up-gradable if necessary? Like updating a motherboard BIOS (which is kinda its own OS now thanks to EFI?), or the firmware on your SSD?

Keen to understand why the OS loading firmware is such a necessity these days?

[pal666]

why debian hypocrites are blatantly ignoring non-free hardware other than firmware?

[phoron]

I would prefer a distro with no proprietary software at all, and people to concentrate in hardware that works with it, preferably open hardware. But I find it very sad that the status quo in Debian is not even an option to be voted anymore ? Or one just votes no to all three options and then things are left as they were ?

I can't read minds but to me people who say the general public can't install current Debian in mainstream computers and they magically could if Debian included proprietary firmware automatically are not seeing reality clearly, and are kind of assuming everyone is similar to them, so what gives them less work would be easier for everyone. I think worringly too much modern hardware won't let people install Debian unless Debian is turned into a meaningless and powerless blob carrier (and then increasingly too much hardware won't just let users install anything at all, just update what the vendor feeds them) and at the same time most of the general public won't be able to install and use Debian comfortably even if Debian bends lower still to proprietary stuff.

Installing and using Debian is not hard and it is not unnecessarily hard, but using computers without thinking is hard, and culture helps thinking, so getting into free software culture helps use, understand and master free software. The minimum for that is being able to distinguish free from proprietary software. If users can't even be asked to understand what freedoms they lose with their choice of hardware, they won't understand stable vs testing, or upstream vs downstream or where to search for help or report bugs or in which ways. Installing is just one step of their way. Once they have redistributable proprietary firmware sneaking unasked in their Debian they will complain they don't get unredistributable proprietary stuff. When Debian can't license that as hardware vendors or deep pocket corporations do, those users will just deride and abandon Debian. They will just expect Debian to abuse them like they're used other OSes do and think they have to accept everything as is without ever learning, customizing, or sharing and contributing anything. And that's the way to use a TV, not the way to use a computer.

[redgreen925]

Fair enough. So the OS needs to load the firmware to tell the hardware how to work, then the drivers, to tell the OS how to interface with the hardware? Is that right?
Cause to me, that seems bizarre. Why is the firmware not built in to the hardware and up-gradable if necessary? Like updating a motherboard BIOS (which is kinda its own OS now thanks to EFI?), or the firmware on your SSD?

Keen to understand why the OS loading firmware is such a necessity these days?

Yes it is pretty much how it works, the firmware gets loaded then the driver is able to use that firmware to run the hardware. If the firmware is built into the hardware unless there is a reprogram-able chip option used then it can never be updated. Most of them reprogram-able chips use windows/dos programs to do it when they are used leaving Linux users in the same spot with the hardware lock-in. At least when you load a firmware blob it can be changed and updated by the people who provide them to give fixes for security problems among other things.

[rleigh]

as I understand it, firmware should be shipped on the device, not needed to be manually loaded at boot time.
...
Important to push back on this or before we know it, open source distros will start shipping closed source drivers by default due to no other option to make the hardware 'work'.

Firmware is one place where the free software movement has some very skewed priorities. Back when I was a Debian developer and all-out free software zealot I would rail against the evils of proprietary firmware along with the rest of them. Today, I lead an embedded software development team and I see things from the other side of the fence, and I've changed my mind quite a bit as a result.

The crux of the philosophical conundrum is where do you choose to place the boundary between the parts of the system which run free software, and the parts which are just "peripheral components". You could argue that the free software part is basically just what runs on the CPU at one extreme, or you could require every last part in the system to only run free software at the other. However, the former is a solved problem while the latter is a completely unachieveable goal.

Firstly, the devices which are running proprietary firmware are running completely independently from the CPU where Linux is running. These range from small discrete parts on your motherboard all the way to your storage devices and GPU, and can be FPGAs, CPLDs, CPUs and MCUs all the way through to small parts which have primitive sequencers running on them. A typical computer system will have dozens of them. The CPU running Linux will use a device driver of some sort to communicate with them, but that part is completely separate to the device itself.

The assertion that the firmware should be "shipped on the device" would mean that the code would need putting into the actual masks as a ROM area, or it would need flashing on at manufacture to some persistent storage, possibly write-once. The former and write-once updating would preclude any possibility for future updating to fix problems or change behaviour without respinning the silicon or replacing the part, yet this inflexible and wasteful strategy is the preference of the FSF! The latter implies having the capability to store the firmware in a persistent manner, but not all hardware has that capability--some hardware requires the firmware loading on after powering it up, and it's lost once the power is removed, but it's flexible and better for the environment because it reduces waste.

The other aspect is that these parts are not general-purpose computers. Many of these parts use custom and very expensive tooling to produce the firmware image. Someday we might have good open-source FPGA synthesis, but today we do not. There's simply no way to take the VHDL and have it synthesise a comparable image to that made with the original tools. In theory, this might happen eventually, but it's not at all practical to consider it today. The other parts might each need a separate custom toolchain. GCC won't work for everything here. This is a completely different world to conventional CPUs, and it's a world in which free software is not the rule, it is the exception. I'll look forward to the day we have this, but that day is not today.

Firmware is written to do very specific things, requiring intimate understanding of the problem domain and the part design. Unlike regular computers, these really are not amenable to casual tinkering by non-experts. In many cases these parts have undergone extensive validation and verification to comply with various standards, including safety standards. While they might contain firmware, the part itself is classed as hardware, and it's sold and used as such. Even if the part was fully open to modification, few people would have the capability or the resources to reproduce that effort. Possibly in theory someone might do that, but at what cost, and for what benefit?

Personally, I'd look at these parts as you look at any other electronic component: it's a black box with defined inputs and defined outputs, and you read the datasheet to understand how it all works and how to control it. What's happening inside the box is largely uninteresting from the point of view of using it. When you design your circuit you'll select an appropriate part for the job that meets the requirements and the BOM budget. Whether a part uses open-source firmware or not is not on the radar of most of the electrical engineers, and why should it be? It's a non-issue which was created by free-software fanatics who haven't really examined the problem in full detail. Their issue is a political one of their own making, and that has absolutely no bearing on manufacturing a working product that complies with the necessary regulatory and safety rules.

Looking at the options on the GR, it looks like most of them are actually acknowledging this reality to varying degrees, even if they don't say that directly.

[Waethorn]

Do they have a distribution license for non-free firmware or not?

If they do, they could just include the firmware on the media and note during install that the piece of hardware in question won't function fully without it, and then offer the choice. This means less installation media, and it gives the user the freedom to choose, not impose choices or ideals on them. This at least allows the user to fully utilize their hardware that they chose to install Debian on.

The biggest issue that users trying to use Linux will face is whether their hardware is supported or not, and many don't know anything about how the GPL affects hardware support. Linux DE's don't have something akin to Windows' Device Manager. It may seem trivial, but it simplifies hardware enumeration vastly over trying to weed through lines of text from lspci, lsusb, dmesg, etc. I've used Linux on and off for a number of years, and this is one thing that bugs me about Linux DE's so much - having to find and troubleshoot hardware incompatibilities. Users often assume that this other operating system should be about as compatible as Windows. And if they do separate the two installation ISO's, do you really think Debian is going to want to put up a big long-winded list on the main download page of all the hardware not supported by the fully-free download?? I'd bet not.

Even Torvalds says that ideals shouldn't get in the way of usability. If you make something hard for the user, you're not doing it right. Of course, he's not too keen on Debian either.