Hi Enrico,

Thanks for getting in touch.

While Copilot is available for free, it still must be enabled by individuals before it can be used, like any feature. You have not enabled it, and not accepted the terms of service so Copilot is not active on your account.

“A procedure I can use…”

Git log?

Isn't "unreasonable" their entire schtick?

I mean, unreasonable got some good things started, but by this point, we probably need a completely different brand of unreasonable.

> users would benefit from most (if not all) firmware being free software

yes

> So I think this is less of a philosophical discussion

no, that does not follow

The stance of FSF is that developing proprietary software is immoral. Therefore, all software is *required* to be free

Just because something is beneficial to users does not mean it's morally required

Therefore, I think there's still a philosophical discussion here: where is the line between the vendors' rights and the users'

I mean, in an ideal world, it would be awesome of firmware were libre/free open source too I suppose?

We don't live in an ideal world.

I am hardly a proponent of the FSF even though I have been using libre/free open source software that is older than its existence.

However, the one time I bothered to get a story published to slashdot, it was right in this realm (for reference: slashdot.org/story/51339 )

The long story short is that in OpenBSD's instance, even if developers went through the effort to reverse engineer and re-implement a proprietary closed source WiFi driver, having cooperation and consent from vendors in order to redistribute their firmware binary blobs, is still a necessity for having that WiFi chipset work. This might be particularly important say, during OS install, where you more often than not, might be installing tarballs over a network and that network might be wireless.

Sure, there are workarounds. Windows drivers being installed from floppy disk after OS install come to mind as something many hardware vendors would probably prefer (ignoring the headaches of RAID controller drivers and OS installs which is a completely different nightmare I would rather not remember as it's kind of tangential). You could expect users to install the pertinent firmware themselves in OpenBSD after install too I suppose, but it makes for a crummier experience (particularly in a day and age where increasingly laptops don't even have physical network cards anymore, they might only have WiFi chipsets onboard without plugging in a dongle).

I guess in theory super idealistic libre/free open source folks could advocate for reverse engineering and re-implementing SDR firmware for such WiFi chip sets?

However, OpenBSD's objective then (and presumably now) was just to get permission to redistribute vendor firmware. In many instances, vendors were more than happy to cooperate!

It just isn't a given and not something that OpenBSD could reasonably ship on boot media (remember when OpenBSD still sold physical install CDs? Ah, the stickers and complementary music tracks!) without vendor permission.

I don't think OpenBSD's position was unreasonable, nor untenable.

But then, OpenBSD is also a far cry from the FSF even if their objectives, at least in this instance, may have significant overlap in interests.

>Freedom isn't necessary.
Well there it is.

Unlike a PCIe Wi-Fi card, remote network servers don't have DMA access to the main memory space (IOMMU is a pretty shoddy workaround).

Microcode in ROM in an intel CPU is hardware circuits that don't have a proprietary software license attached to it that restricts you and you do have the right to do whatever you want to your own hardware - even to sell it.

As far as I can tell, the microcode in ROM doesn't contain malicious circuits, as intel knows that a decapping enjoyer is going to take a look eventually and report on any found malicious circuits.

Meanwhile, microcode updates are software, with nasty proprietary license terms that require acceptance and this line from the software license confirms that the updates are partially proprietary malware;
>3. No reverse engineering, decompilation, or disassembly of this software is permitted.

That's right "reverse engineering our updates and finding the malware is not allowed, even though we've made every effort at doing so extremely difficult with encryption and an undocumented instruction set and only around a dozen people knowing how microcode updates work".

All software running on a computer should be free and I am working towards achieving that.

Encouraging the user to accept a proprietary license for proprietary peripheral software only leads the user away from freedom, as such software almost never gets replaced (there are arguments that RAM loaded proprietary software is easier to replace than EEPROM installed proprietary software, but for some reasons EEPROM installed proprietary software gets replaced much more often? (maybe it's something to do with how the RAM loaded software often has license terms and digital handcuffs that try to prevent replacement, while EEPROM included software on peripheral devices usually has no such restrictions)).

@asu @marcan @darkling As far as I can guess, it breaks down into two fundamental concerns:

1) We can't allow our flock to be tempted. Make them rip out anything that would run proprietary software.

2) We need a way to "grandfather" into compliance the devices we have already been using. If we say the proprietary firmware in the Embedded Controller (and countless other cores) in RMS' Thinkpad is "just part of the hardware" for <some reason> we can pretend it doesn't exist.