Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The FSF’s relationship with firmware is harmful to free software users

ariadne.space

Post reply on HN
Print view View original

141–150 of 205 posts

Re: The FSF’s relationship with firmware is harmful to free software users

#141

Post by throwaway81523 »

MathMonkeyMan wrote: post #138
oefrha wrote: post #58

Earlier quoted context omitted.

TFA is very specific about the harm done by FSF's policy, unfortunately you either missed the arguments or chose to left them out. E.g. > The FSF “Respects Your Freedom” certification has a loophole so large you could drive a truck through it called the “secondary processor exception”. > ... > This means that users of the Librem 5 phone are objectively harmed in three ways: first, they are unaware of the existence of…

I referred to that when I mentioned "loopholes." It's a contradiction for sure, but either you have a "libre" device with non-free components isolated over a serial interface, or you have a less capable device. Disingenuous, maybe.

I have sometimes thought of ditching my phone plan and getting a wifi hotspot, just to stop the phone carrier from messing with the software in my phone through OTA updates and whatnot. All communication would be through TCP and that would stop the phone carrier from talking to the mobile baseband processor, which could be completely disabled or removed. It would even allow ditching the whole phone and using a wifi-only tablet instead. Both sides (the wifi box and the phone) are hard to make entirely free, but by isolating them from each other, some higher control can be achieved.

Re: The FSF’s relationship with firmware is harmful to free software users

#142

Post by throwaway81523 »

cmeacham98 wrote: post #9
MathMonkeyMan wrote: post #3

I'm well out of my realm of expertise here, but I had a gut reaction to: > Libreboot, being FSF-recommended, also has this policy of disallowing firmware blobs in the source tree, despite it being a source of nothing but problems. Later the author points out how there isn't any contemporary libre hardware that would satisfy users (vaguely but reasonably described), and so "free" solutions utilize loopholes in the leg…

> Why accuse the FSF of hypocrisy? I'm not sure I fully agree with the author, but I think their point is that the FSF makes exceptions for binary blobs in some places because of usability, but then denies similar exceptions elsewhere because they're not libre. The complaint is that the decision on what counts as being included in the loopholes appears largely arbitrary, at least from an outsider's perspective.

Is that hypocrisy, or just an oversight / unintended consequence?

Re: The FSF’s relationship with firmware is harmful to free software users

#143

Post by serendipitous »

Teknoman117 wrote: post #37
irfwashere wrote: post #28

If you'll forgive my naivete here I've been thinking a lot about the FSF philosophy and wanted to ask HN: how big of a project would it be to create a fully libre (whatever you want to call you it) laptop? Like how feasible is it to use "free" components put together into a package and what kind of budget would be required? I think China has a few companies working on domestic processors. Let's say they are convinced…

For something considered modern, pretty much next to impossible. All of the modern CPUs require blobs to function, whether it's microcode, embedded firmware, binary driver blobs, or otherwise. I don't believe there is a wireless card (wifi, Bluetooth, etc.) on the market that doesn't use binary, closed source firmware. In fact, it's almost mandated by law that there can't be. FCC regulations require that devices be m…

> That's why so few of them tend to advertise transmit capabilities.

Any SDR that has transmit capability freely advertises it and there are many of them. The makers of one of them (bladeRF) also develops an open source 802.11 PHY that can run on their SDR's FPGA if you want to run an open source WiFi radio. (and you don't mind using $700 hardware to run older generation WiFi) Legality of the transmission may be a concern for users of the SDRs but is not for those selling them.

Re: The FSF’s relationship with firmware is harmful to free software users

#144

Post by arminiusreturns »

voidhorse wrote: post #105
BrS96bVxXBLzf5B wrote: post #74

Attending an RMS talk at a university ~8 years ago, some (increasingly irritated) lecturers questioned him on the use of proprietary graphics drivers in image processing for use in medical equipment and research. While RMS argued his absolute stance that proprietary drivers are never permissible, the lecturers argued that the drivers were literally saving lives and people would die without them. "They should die for…

I get what you’re saying, but this form of argument sort of talks past the stance of the RMS’s of the world. The fact that the software being used is proprietary is a historical accident and not an attribute of the software that makes it function a certain way—it’s entirely possible to write non-proprietary life saving software. RMS is arguing for principles and ideals. Sure when it comes down to it, it’s absurd to s…

At this point I'm seriously considering the idea of pushing for using whatever security umbrella fad of the day is to argue for imminent domaining and then forcible open sourcing infrastructure critical technology. Roll it in with a fresh healthcare for all deployment to test. Open source the resulting data, find some solutions.

Re: The FSF’s relationship with firmware is harmful to free software users

#145

Post by _ph_ »

chii wrote: post #92
d0mine wrote: post #89

Earlier quoted context omitted.

Imagine you are fighting for peasants rights; feudal doesn’t like it and orders to kill one peasant per day until you surrender. Question are you the bad guy for not surrendering?

> are you the bad guy for not surrendering? those peasants who died are killed by the feudal lord, so no - 100% not the bad guy for fighting. The only way you could be considered a bad guy is if you used peasants as suicide bombers - and only if those people didn't volunteer.

I disagree to the blanket form of statement. Yes, it is the feudal lord who does the killing, but that doesn't mean there is no guilt if your actions effectively lead to the named peasants are killed. Whether one shares some guilt by the actions has to be judged in each case separately.

Re: The FSF’s relationship with firmware is harmful to free software users

#146

Post by serendipitous »

marcodiego wrote: post #38
smitop wrote: post #35

Earlier quoted context omitted.

Here's where Purism says that the reason for the workaround is indeed for attempting to get RYF certified: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...

At most, the Purism case is a good a example of how hard it is to game the certification.

What the article describes is not particularly difficult to implement. But claiming that storing the firmware in a way that prevents the user from updating it via software somehow makes the device more "free" is absurd.

Re: The FSF’s relationship with firmware is harmful to free software users

#147

Post by YEwSdObPQT »

seanhunter wrote: post #134
marcodiego wrote: post #70

Earlier quoted context omitted.

I understand your position, but it would be better if the compromise was made by "the other side".

Everyone always thinks it would be better if the compromise was made by the other side, don't they? What you're describing is just a concession. A compromise is where neither side quite gets everything they want and both have to give a little.

The otherside in this case is selling you a thing and in some cases restricting you what you can and can't do with the hardware you bought. Which means you don't really own it.

We have given them money. They should let us use our hardware as we see fit. In the case of nvidia literally detecting certain workloads and deliberately reducing the performance. Whether you think Crypto mining should be a thing or not, they purchased the hardware legally and should be able to use it as they see fit (as long as it is not illegal).

With AMD GPUs it literally doesn't make anysense. They've released millions of lines of code to the Linux kernel so their GPUs work correctly with Linux and then I have to download a proprietary firmware for my card to initialise properly. Is the firmware really that secret? I doubt it.

Re: The FSF’s relationship with firmware is harmful to free software users

#148

Post by marcan_42 »

mlyle wrote: post #139
marcan_42 wrote: post #136

Earlier quoted context omitted.

The idea for Precursor is that every user runs a different random build of the design.

The only thing that seems to be randomized in building precursor is the P&R seed. https://github.com/betrusted-io/betrusted-soc/blob/main/betr... That prevents attacks where you have a known place on the FPGA is naughty, but not when you have a lot of elements that are naughty on certain input. It doesn't even really protect against known-naughty-place: there's not infinite freedom on P&R with fixed I/O locations.

Right now, sure, but there are more mitigations that can be added. This is an area ripe for research. The idea is that this kind of device and approach allows for further research, which can benefit users in the future since it's soft logic.

Again, I'm not saying this is a silver bullet, I'm saying it's an interesting approach and can claim to at least mitigate the risk of silicon backdoors by making them harder to pull off, which is more than can be said of the typical hard logic approach.

Re: The FSF’s relationship with firmware is harmful to free software users

#149

Post by deknos »

people have opinions. more news at 11.

sorry, but i think the FSF is totally justified. the ME engine and stuff like that showed that the industry does not have the best interest of customers (business and endusers alike) at heart and will fuck them over for more money.

and then the whining here is great again and it's like "Stallman was right" and at the next turn "but ma feetures" complaints come around, because it costs more money or time which also would be the ethical thing to do often enough

Re: The FSF’s relationship with firmware is harmful to free software users

#150

Post by tlamponi »

marcan_42 wrote: post #107
r283492 wrote: post #86

Earlier quoted context omitted.

If you try to pin down someone on the fly who is publicly advocating for something on what exceptions are ok, expect them to be stubborn. But there is a lot of pragmatism at work. It's why we have the LGPL, GPL, and AGPL. https://www.gnu.org/philosophy/pragmatic.en.html

Ah yes, the AGPL. The license that wants to be an EULA (because that's the only way you can actually close the SaaS loophole), but can't, because being an EULA would be against the FSF's core values (Freeedom Zero), so instead it's a cute hack that is trivial to work around if you want to, while simultaneously being almost impossible to comply with for regular developers. And then the FSF plays it like it has EULA po…

> Step 2: Make a change to the code - oops, license violation! Clause 13! I need to change the source code offer first!

No you don't, as that's not creating any users, the source code repo is the source code repo, not a distributed program you provide as service for anybody.

It seems there are further misunderstandings in that wall of text, I'd heavily recommend talking to someone with (FOSS) legal experience if you're involved in such distributions, no offense meant.

We're providing most of our code base under the AGPLv3 and have never faced any such issue either for people contributing to our projects or us contributing to other AGPLv3 projects. Granted, some FANG company refused to use us (officially that is, I know personally of unofficial use), but that's not something really hurting us in any way, and definitively better than getting stabbed in the back like some other projects got from some SaaS companies due to having a permissive license that allowed them to deploy changes without giving them back anymore.

Post reply on HN