Removing this package would also break [gnome-firmware].

fwupd is also a TPPM.

this is just a guess, but it is likely that linux-libre would not load any of these firmwares - if they are kernel modules, then the package is harmless and useless

flashrom is a dependency and the database it connects to hosts all kinds of propritary firmware so I suspect it will try to flash BIOS and EEPROM firmware, hence linux-libre could not stop it.

The fwupd repo <https://github.com/fwupd/fwupd> states "This project is configured by default to download firmware from the Linux Vendor Firmware Service (LVFS) <https://fwupd.org/> ."

Checking out that site shows the latest firmware uploaded to it is proprietary <https://fwupd.org/lvfs/devices/com.intel.INTEL-670P-670PSSDPEKNU010TZNVME1TB.7XX1> .

I suspect this service is little more than a convenient way to install proprietary firmware not usually packaged by distros.

There may be some libre firmware on there also.

I'd say it's a TPPM for your-system-sanity, and it's technically free, but downloads proprietary firmware automatically as a daemon.

fwupd largely deals with the firmwares on peripheral devices. That's code that distros traditionally don't deal with. USB devices. Laptop components with their own flash chip that stores the firmware. The Linux kernel and linux-firmware deal with things that receive their firmware from the CPU at boot-time; fwupd deals with devices that store their own firmware, devices that 90% of the time you can pretend are block boxes that have their software burned in to ROM so that for FSDG purposes you can pretend aren't software.

AFAICT, LVFS doesn't really track if firmwares are FOSS or not. Vendors upload a zip file of the binary firmwares and call it a day.

That's a very real FSDG concern. And I'm not sure what to do about it. Lots of the firmwares are free software, and to remove fwupd and and the LVFS library of firmwares would be a huge disservice and anti-feature to free-systems users. That problem's been eating at me for a few years.

I mean the "big picture" answer would be to build a FOSS-oriented alternative service to LVFS. But (IMO) that's beyond the manpower of Parabola. Should FSDG distros band together to create that? Should we propose that to the FSF as a high-priority project? IMO, we can get everyone and their dog to say it's important, but without actually getting a group of people to actually do it, it won't happen.

So I'm not sure what to do.

Not that I've been terribly active in Parabola for the last couple of years, but:

Empirically, my answer has been to look the other way; because IMO fwupd/LVFS is more [helpful to users of purely-FSDG-software] than it is [facilitating of using non-FSDG software]. That view might not be entirely compliant with the FSDG, but IMO it's the view that results in the best outcome for users who want to use entirely free software.

To remove fwupd because it can install non-free firmware doesn't remove the non-free firmware; that firmware is still on a flash chip on the device; it just removes your ability to modify that firmware. It's sticking your head in the sand and pretending the firmware is hardware. As long as you have that hardware, you'll have the non-free firmware, whether or not Parabola ships fwupd. (Unless someone reverse-engineers the hardware and provides a free firmware for it--and guess what, you'll need fwupd to update to that firmware.)

fwupd/LVFS might be technically in violation of the FSDG, but (IMO) fwupd's removal would be strictly harmful to user freedom, as its removal WOULD NOT help users avoid non-free firmware. That isn't to say that things can't be improved. But the way to improve things isn't to remove fwupd.

lukeshu, there's no need to keep things to yourself which make you upset; I'm sure we'd love to discuss any issues on the forums. I just worry that you may be sitting on other instances of proprietary software in unaudited packages in the Parabola repos that you aren't willing to share because you disagree with the FSDG, although I assume good faith.

As controversial as this issue of firmware seems to be in the free software community, I presume Parabola wants to remain FSDG compliant.

My answer is to see it for what it is: a proprietary software downloader.

If you have a ROM then it's technically crossed the realm from software to hardware. I know that's a bit of a cop out but it's true. If nobody can change it, then nobody has power over the users aside from whatever is burnt into it before it is shipped from the factory. It would be better if it were an EEPROM with libre firmware, but this is a compromise.

If you have an EEPROM then it's software because it's just the same as any other storage medium.

I think we have to remove fwupd to remain FSDG compliant.

I also suspect the "LVFS" is 99% proprietary, although a patched fwupd in the [libre] repo which uses a forked Parabola repo (eg. fwupd-firmware) would be an ideal solution.

Also, "FOSS" is listed as a word to avoid or use with care in the so-named GNU article.

lukeshu - this would be a great discussion for the FSDG mailing list - i dont like the idea of each distro freely re-interpreting the FSDG

i think that WRT the FSDG, this reduces to the CPU microcodes issue, and those are generally consider to be prohibited - if the user can compile and replace it, then it is software by any definition; and if the user had the source code, it can be replaced with a modified version - so, parabola should require them to be freely licensed with source code available - everyone knows that a lot of hardware is not going to work with a libre distro; and that users can get blobs from arch if they really need them

to argue that point to the FSDG, is effectively an argument for allowing microcode updates too

i forgot to mention that there is a long standing discussion about how to treat TPPMs generally - gap was suggesting that this package should be considered as another TPPM (if we keep it) - it doesnt need to be a FSF high priority - RMS has already suggested years ago, that GNU would host libre repos for any TPPM - o/c people need to volunteer to curate them - that is a lot of work o/c; so we have also suggested some simpler alteratives, such as moving them to a non-standard repo

https://labs.parabola.nu/issues/1035

we'd love to discuss any issues on the forums

it is best to discuss development issues on the dev mailing list - i am probably the only team member who reads the forum regularly

To be clear: I'm not keeping things to myself because I don't want to talk about them or to slide things through. To the degree that I'm keeping things to myself, it's because I lack the energy/time to deal with them. fwupd came on to my radar about the time that my involvement in Parabola dropped off.

gap wrote:

Also, "FOSS" is listed as a word to avoid or use with care in the so-named GNU article.

I used "FOSS" because: It's my understanding that LVFS is a Linux Foundation project. The Linux Foundation uses the OSI's definitions and licenses; any tracking of licenses that they do will be oriented around "open source", not around "free". Of course, we care about "free". So both "open source" and "free" are in play here, so that's why I used the term "FOSS".

I was using it with care, but it wasn't clear that I was using it with care. For that, I apologize.

I'm sorry, I'm not familiar with the term "TPPM".

bill-auger wrote:

to argue that point to the FSDG, is effectively an argument for allowing microcode updates too

The type of firmwares that fwupd deals with are different than microcode updates. If you don't load a microcode update at boot-time, then it just falls back to what's implemented in hardware. If you don't use fwupd to update the firmware, it falls back to the most recently flashed firmware. Not loading a microcode update removes the code; not running fwupd doesn't remove the code.

gap wrote:

If you have a ROM then it's technically crossed the realm from software to hardware. I know that's a bit of a cop out but it's true. If nobody can change it, then nobody has power over the users aside from whatever is burnt into it before it is shipped from the factory. It would be better if it were an EEPROM with libre firmware, but this is a compromise.

If you have an EEPROM then it's software because it's just the same as any other storage medium.

Right. What I'm saying is that removing fwupd doesn't remove the software on the EEPROM, which is the real issue. Pretending that removing fwupd resolves the issue is to pretend that the EEPROM is a ROM; which it isn't.

Again, I'm not saying that it's OK that LVFS serving non-free firmwares is OK, I'm saying that removing fwupd isn't the answer.

gap wrote:

I also suspect the "LVFS" is 99% proprietary, although a patched fwupd in the [libre] repo which uses a forked Parabola repo (eg. fwupd-firmware) would be an ideal solution.

Looking through the LVFS, damn near everything is mislabeled. I see a few firmwares that I know to be Free marked as "proprietary", and a few marked as having a Free licenses, but are actually proprietary.

This discussion has motivated my drunk-at-3am-on-a-Friday-night self to want to create an FSDG alternative to LVFS. We'll see if my sober-on-a-Saturday self follows through. I've messaged Andrew at the FSF about using firmware.libre.dev for this purpose, so that it can be shared between distros. (the FSF owns libre.dev, but doesn't seem to be using it for anything real ATM. If they didn't already own it, I'd have registered it.)

On Sat, 03 Apr 2021 10:09:24 +0000 labs@parabola.nu wrote:

I'm sorry, I'm not familiar with the term "TPPM".

"third-party package manager" - we coined that, because ...
we got tired of typing it

pip, rubygems, npm, guix, etc - any program which indexes and
downloads software from a third-party repository - most of them
do not indicate licenses, and most have no licensing standards,
so they are all problematic for the FSDG - (almost all), haskell
cabal is the only one i found, that has FSDG-fit licensing standards

also, they can be dangerous - for example, i triaged an obscure
bug, reported by a user, one day "octopi is broken" - i
eventually asked: "what happens if you open a terminal and type
`/usr/bin/pacman` - the user responded that it launched a pacman
video game - the user then remembered running `sudo pip install
pacman` - obviously, that user had to bootstrap, in order to
re-install the real pacman, because it was clobbered

Not loading a microcode update removes the code; not running fwupd doesn't remove the code.

i think the important factor, is that although the non-free firmware is on the device, parabola did not put it there - it was effectively user-installed, same as if the user got the firmware update from arch

I think the short-term solution might to be to stick rm -f "$pkgdir"/etc/fwupd/remotes.d/lvfs* at the end of the package().

#3000 is a duplicate. See #2909. I apologise for not checking first to see if an issue of the same topic was already open.

It's interesting to see the solution reached in this thread matches what Guix did (keep the package, but remove mentions of the LVFS), whereas GNUtoo chose to blacklist the package.
I think either solution is fine, but AFAICT there are no FSDG-compliant repos to use with `fwupd` anyway, so even if it were to be kept it would be relatively useless in the free world until such repositories are started.