The FSF’s relationship with firmware is harmful to free software users(ariadne.space)
ariadne.space
The FSF’s relationship with firmware is harmful to free software users
https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/
204 comments
> Why accuse the FSF of hypocrisy?
If I ship some piece of hardware on a PC with its firmware burned into a ROM and do not provide the source (a binary blob), the FSF will happily say my hardware is RYF-certified.
If I ship the exact same hardware with the exact same firmware as a binary blob but in Flash RAM or loaded at init by a driver they'll accuse me of not "respecting freedom".
Same hardware. Same firmware. Same vendor. The FSF is hypocritical because their RYF certification allows me to get certified so long as I make my hardware impossible to update. I don't have to provide any source or actually respect anyone's freedom to get in their good graces, I just need to burn my binary blob into a ROM.
If I save a dollar per unit by loading the same firmware blob through a driver into the device's RAM, I'm an evil freedom disrespecting jerk.
Besides being hypocritical it also makes for extremely poor security practice and affects longevity and e-waste. If I can't update a device firmware it might have some security flaw that can't be patched and maintain the RYF certification. If I roll an updated firmware and have the driver push it to the device I lose my previous certification unless the new blob is open sourced.
Devices that can't be updated are also more likely to be discarded. An updated OS might be incompatible with my old firmware in ROM so needs to be tossed when upgrading. Same if a security fix can't be pushed out.
So the FSF doesn't seem to actually care about freedoms, just whether a vendor technically meets their requirements. They also engender a poor security posture with their policy. Libre hardware is a worthy goal but the FSF's policies and technicalities around certification don't really lead to that goal.
If I ship some piece of hardware on a PC with its firmware burned into a ROM and do not provide the source (a binary blob), the FSF will happily say my hardware is RYF-certified.
If I ship the exact same hardware with the exact same firmware as a binary blob but in Flash RAM or loaded at init by a driver they'll accuse me of not "respecting freedom".
Same hardware. Same firmware. Same vendor. The FSF is hypocritical because their RYF certification allows me to get certified so long as I make my hardware impossible to update. I don't have to provide any source or actually respect anyone's freedom to get in their good graces, I just need to burn my binary blob into a ROM.
If I save a dollar per unit by loading the same firmware blob through a driver into the device's RAM, I'm an evil freedom disrespecting jerk.
Besides being hypocritical it also makes for extremely poor security practice and affects longevity and e-waste. If I can't update a device firmware it might have some security flaw that can't be patched and maintain the RYF certification. If I roll an updated firmware and have the driver push it to the device I lose my previous certification unless the new blob is open sourced.
Devices that can't be updated are also more likely to be discarded. An updated OS might be incompatible with my old firmware in ROM so needs to be tossed when upgrading. Same if a security fix can't be pushed out.
So the FSF doesn't seem to actually care about freedoms, just whether a vendor technically meets their requirements. They also engender a poor security posture with their policy. Libre hardware is a worthy goal but the FSF's policies and technicalities around certification don't really lead to that goal.
See https://www.fsf.org/campaigns/free-bios.html for the rationale.
Basically, FSF had to make a compromise here. If you use Flash ROM (or other writable medium), the firmware counts as a nonfree software. However, if you use actual ROM, the firmware might as well have been a circuit baked right in the product, so it counts as hardware; nevertheless, it counts as non-free.
FSF's ultimate goal would of course be to be able to certify that every component (hard or soft) of the system is actually free. However, this isn't very practical, since no consumer-grade computers will be considered free due to proprietary CPUs (e.g. Intel, AMD, ARM), which is why FSF is stuck in a weird situation. (How would you make exceptions for the CPU stock microcode and not the BIOS, for example?)
For that matter, I hope RISC-V helps us go a step forward...
Basically, FSF had to make a compromise here. If you use Flash ROM (or other writable medium), the firmware counts as a nonfree software. However, if you use actual ROM, the firmware might as well have been a circuit baked right in the product, so it counts as hardware; nevertheless, it counts as non-free.
FSF's ultimate goal would of course be to be able to certify that every component (hard or soft) of the system is actually free. However, this isn't very practical, since no consumer-grade computers will be considered free due to proprietary CPUs (e.g. Intel, AMD, ARM), which is why FSF is stuck in a weird situation. (How would you make exceptions for the CPU stock microcode and not the BIOS, for example?)
For that matter, I hope RISC-V helps us go a step forward...
Yes, they have a rationale, but it's a poor one. Followed to its logical conclusion, I can make any program free. All I have to do it put it in ROM. Then I can pretend it is part of the hardware. Software in ROM is not hardware, it's just software that can't be improved or fixed.
The other point they ignore that if some part is programmable but currently requires proprietary firmware, it's possible (and this has happened) that people reverse-engineer it and produce free software that runs on it. BUt if you bought the FSF-blessed version of that device you're then stuck with the proprietary version of that program forever, and worse, you can't get any updates for that program. You can't get a security fix, and you can't replace it with the free program.
The other point they ignore that if some part is programmable but currently requires proprietary firmware, it's possible (and this has happened) that people reverse-engineer it and produce free software that runs on it. BUt if you bought the FSF-blessed version of that device you're then stuck with the proprietary version of that program forever, and worse, you can't get any updates for that program. You can't get a security fix, and you can't replace it with the free program.
> The other point they ignore that if some part is programmable but currently requires proprietary firmware, it's possible (and this has happened) that people reverse-engineer it and produce free software that runs on it.
If this is possible, then device makers should do it, ship the free-software firmware on the device, and then get it RYF-certified. No blobs needed, ROM or otherwise! Problem solved!
It seems like a feature, not a bug, that the RYF certification process makes it more painful and expensive to release devices that rely on proprietary software.
If this is possible, then device makers should do it, ship the free-software firmware on the device, and then get it RYF-certified. No blobs needed, ROM or otherwise! Problem solved!
It seems like a feature, not a bug, that the RYF certification process makes it more painful and expensive to release devices that rely on proprietary software.
> If this is possible, then device makers should do it, ship the free-software firmware on the device, and then get it RYF-certified. No blobs needed, ROM or otherwise! Problem solved!
The device maker could ship with programmable proprietary firmware and have the possibility of being RYF-certified in the future if someone writes free firmware. Or they could ship with proprietary firmware in ROM and be guaranteed RYF certification immediately. The rules encourage them to pick the second option, and it's no surprise that companies such as Purism have done so.
Yet that option is never better for user freedom, since making software un-upgradeable does not make it any more free. And occasionally it is worse, in the event free firmware becomes available later on.
The device maker could ship with programmable proprietary firmware and have the possibility of being RYF-certified in the future if someone writes free firmware. Or they could ship with proprietary firmware in ROM and be guaranteed RYF certification immediately. The rules encourage them to pick the second option, and it's no surprise that companies such as Purism have done so.
Yet that option is never better for user freedom, since making software un-upgradeable does not make it any more free. And occasionally it is worse, in the event free firmware becomes available later on.
It sure sucks that device makers just have to wait and hope someone writes free firmware. If only they had some way to cause the firmware to be written, perhaps involving things like "money" or "employees" or "contracts with vendors".
The alternatives to this policy are allowing all blobs, in which case the RYF certification isn't actually verifying anything, or not allowing any blobs, in which case RYF cannot certify any devices made after 2009 (something the author also takes issue with). Making it expensive and risky for device makers to rely on blobs is the only middle ground that makes sense.
The alternatives to this policy are allowing all blobs, in which case the RYF certification isn't actually verifying anything, or not allowing any blobs, in which case RYF cannot certify any devices made after 2009 (something the author also takes issue with). Making it expensive and risky for device makers to rely on blobs is the only middle ground that makes sense.
You seem to miss that these devices are often full of patented parts, so in most cases even if the manufacturer wanted to, they can’t provide sources. Also, modems are often legally mandated to have certain firmware (so that restricted frequencies are adhered to)
> even if the manufacturer wanted to, they can’t provide sources
In many cases they don't even have them or may not be aware that there's an upgradable firmware in some of the components they're using at all.
In many cases they don't even have them or may not be aware that there's an upgradable firmware in some of the components they're using at all.
Why would they spend time and effort on this, when there's a far simpler way to get the certification with existing non-free blobs?
No, the alternative is to not be a binary yes or no certification, but to construct a nonbinary scale to measure how free it is.
[deleted]
Whether it's loaded into RAM or ROM is the most useless distinction to make. It's functionally identical. Now whether a driver requires executing proprietary code on the host CPU, that is a useful distinction to make, because it allows independent OS implementations to create free drivers.
It isn't identical. With a fixed ROM, every user is denied an opportunity to upgrade rather than just those without an anointed OS. It's about equal access.
Sounds like a good reason to certify hardware that puts firmware in RAM.
Most peripheral ICs have an on board micro with internal RAM and flash. Their RAM isn't typically accessible.
Nevertheless, the first thing the driver for wifi in my laptop does is load up a big firmware file from disk, caused to be shoved into IC RAM, and then proceed to connect to the network. That this process could somehow become more free by embedding a frozen firmware image blows my mind.
And it's not like I haven't seen what the other side looks like. The Broadcom "full MAC" chipsets are also supported, with their remotely exploitable firmware. But those are also "fully" free. Hurray.
And it's not like I haven't seen what the other side looks like. The Broadcom "full MAC" chipsets are also supported, with their remotely exploitable firmware. But those are also "fully" free. Hurray.
RISC-V is foremost about freedom from licensing rather than open-source so I'd hold my breath
The FSF had to make a compromise, but many people think they drew the line in the wrong place. When no reasonable hardware can meet the "compromise" version of RYF it just causes users to bounce off.
I think the issue isn't that much that no reasonable hardware can archive it, but that the "compromise" actively encourages not just insecure systems, but also making systems even less free.
It's a bit like saying that a Windows notebook is only "free" if you can't install other systems and updates are disabled. There probably is more or less reasonable hardware which could implement these restrictions, but such hardware would in no way be more "free" than a notebook where you could just install Linux.
It's a bit like saying that a Windows notebook is only "free" if you can't install other systems and updates are disabled. There probably is more or less reasonable hardware which could implement these restrictions, but such hardware would in no way be more "free" than a notebook where you could just install Linux.
I think a good analogy is the parable of the cobra problem. A city suffers from too many cobras so the government puts a bounty on each dead cobra you hand in. The result? People massively breed cobras to hand them in. The government realizes this and stops the program. Subsequently all breeders lose interest and dump the cobras, leading to an even bigger problem.
So first off, putting something in mask ROM[0] does not make it equivalent to a circuit. Circuits cannot be copyrighted[1] but mask ROM programs can be; meaning the latter is just as non-Free as rewritable software. It is legally silly to distinguish between read-only and rewritable software, even if it might have a small engineering upside of prohibiting the imposition of new antifeatures.
That doesn't mean that mask ROM is free of antifeatures, though - in fact, often times mask ROM is the highest privilege level in the system and thus the best place to put antifeatures. In the case of x86 PCs, the BIOS gets it's own privilege level above the kernel; ARM PSCI also runs in EL3 above normal kernels or hypervisors. These can still actively damage user freedom even if it's "technically hardware" and non-updatable.
Also, the fact that it's not rewritable means that...
1. Security bugs[2] will never be fixed[3], rendering the hardware unsafe to use over time.
2. We cannot practically replace the firmware with a Free equivalent.
It should not be understated that the vast, vast majority of hardware did not come Free. We had to open it ourselves through painstaking reverse-engineering and reimplementation work. This is an ongoing burden that the community must meet for the foreseeable future. Manufacturers are not going to stop shipping hardware with proprietary firmware or drivers anytime soon. Ergo, anything that stands in the way of firmware or driver reimplementation is, in my opinion, bad. This includes making it more difficult to update or replace firmware by putting it into a mask ROM.
My personal opinion is that you can't really draw a line in the sand and say, "this hardware respects your Freedom, but this other hardware doesn't". Hardware manufacturers have zero interest in fully-Free firmware, and I don't expect this to ever change. Not even with RISC-V, which will almost certainly have even more "embedded" fragmentation than ARM does. Whatever standard the FSF writes for "Respects Your Freedom" hardware, someone is going to try and rules-lawyer non-Free software into getting that badge. So they should not provide a strict standard at all.
There's also another question of how much energy we actually want to burn on getting Free firmware into chips. An alternate interpretation of the idea behind the Free BIOS campaign is that the BIOS itself got "interesting" enough to be a Freedom threat. Back when it was still a ROM, Free kernels could ignore it entirely; now it gets it's own privilege level and has to at least be considered. CPU microcode is less of a threat than the BIOS, here - the microcode just lets you patch how certain instructions get decoded, while the BIOS can actively debug and spy on Linux.
[0] I am going to use the term "mask ROM" loosely. Consider one-time programmable memories like PROM or EPROM to be in the same category, as they cannot be electronically erased and then reprogrammed by the same circuit that uses them.
[1] There is a sui generis right for "mask works", but it is far less toxic than software copyright. For one, it has a reasonable term length.
[2] I am assuming security from the standpoint of an end-user, of course. Being able to defeat TiVoization is not a security bug for me.
[3] It is possible to swap ROM chips in some cases, if the part is socketed, or if it is soldered and the user has the appropriate level of soldering skill. However, at this point this is no longer read-only. It's just Flash memory with extra steps. There is no legal or ethical difference between reflashing a chip with proprietary software on it and replacing it with a new chip with new, proprietary software on it.
That doesn't mean that mask ROM is free of antifeatures, though - in fact, often times mask ROM is the highest privilege level in the system and thus the best place to put antifeatures. In the case of x86 PCs, the BIOS gets it's own privilege level above the kernel; ARM PSCI also runs in EL3 above normal kernels or hypervisors. These can still actively damage user freedom even if it's "technically hardware" and non-updatable.
Also, the fact that it's not rewritable means that...
1. Security bugs[2] will never be fixed[3], rendering the hardware unsafe to use over time.
2. We cannot practically replace the firmware with a Free equivalent.
It should not be understated that the vast, vast majority of hardware did not come Free. We had to open it ourselves through painstaking reverse-engineering and reimplementation work. This is an ongoing burden that the community must meet for the foreseeable future. Manufacturers are not going to stop shipping hardware with proprietary firmware or drivers anytime soon. Ergo, anything that stands in the way of firmware or driver reimplementation is, in my opinion, bad. This includes making it more difficult to update or replace firmware by putting it into a mask ROM.
My personal opinion is that you can't really draw a line in the sand and say, "this hardware respects your Freedom, but this other hardware doesn't". Hardware manufacturers have zero interest in fully-Free firmware, and I don't expect this to ever change. Not even with RISC-V, which will almost certainly have even more "embedded" fragmentation than ARM does. Whatever standard the FSF writes for "Respects Your Freedom" hardware, someone is going to try and rules-lawyer non-Free software into getting that badge. So they should not provide a strict standard at all.
There's also another question of how much energy we actually want to burn on getting Free firmware into chips. An alternate interpretation of the idea behind the Free BIOS campaign is that the BIOS itself got "interesting" enough to be a Freedom threat. Back when it was still a ROM, Free kernels could ignore it entirely; now it gets it's own privilege level and has to at least be considered. CPU microcode is less of a threat than the BIOS, here - the microcode just lets you patch how certain instructions get decoded, while the BIOS can actively debug and spy on Linux.
[0] I am going to use the term "mask ROM" loosely. Consider one-time programmable memories like PROM or EPROM to be in the same category, as they cannot be electronically erased and then reprogrammed by the same circuit that uses them.
[1] There is a sui generis right for "mask works", but it is far less toxic than software copyright. For one, it has a reasonable term length.
[2] I am assuming security from the standpoint of an end-user, of course. Being able to defeat TiVoization is not a security bug for me.
[3] It is possible to swap ROM chips in some cases, if the part is socketed, or if it is soldered and the user has the appropriate level of soldering skill. However, at this point this is no longer read-only. It's just Flash memory with extra steps. There is no legal or ethical difference between reflashing a chip with proprietary software on it and replacing it with a new chip with new, proprietary software on it.
> Also, the fact that it's not rewritable means that...
> 1. Security bugs[2] will never be fixed[3], rendering the hardware unsafe to use over time.
But on the other hand: security bugs will never be introduced post-manufacturing. Additional DRM cannot be forced onto you, after you bought the product. Or: DRM bugs that allow you to fully use your hardware cannot later be patched by the vendor.
> 1. Security bugs[2] will never be fixed[3], rendering the hardware unsafe to use over time.
But on the other hand: security bugs will never be introduced post-manufacturing. Additional DRM cannot be forced onto you, after you bought the product. Or: DRM bugs that allow you to fully use your hardware cannot later be patched by the vendor.
Without the source there could be all sorts of timebombs or tripwires in the firmware. For instance a device refusing to operate unless another device was present or changing behavior after a certain date.
This is the insight I wanted.
Now I want to hear what FSF has to say about this...
Now I want to hear what FSF has to say about this...
[deleted]
[deleted]
Bookmarking it.
The malicious/abusive parts of nonfree software are almost always tied to it's updatability. Avoiding updatable nonfree software prevents users from entering into an abusive relationship with a nonfree software vendor. https://www.gnu.org/proprietary/proprietary.en.html, 550 instances of malicious functionalities, I'd bet all instances are for software where the vendor can update it.
Your argument is like "Banning guns will incentivize people to use knives, people who want to only ban guns for violence sake are hypocrites." There is a kernel of truth, but it's really just ignoring the bigger reality.
Your argument is like "Banning guns will incentivize people to use knives, people who want to only ban guns for violence sake are hypocrites." There is a kernel of truth, but it's really just ignoring the bigger reality.
People keep bringing this up like proprietary software can always be unilaterally updated by the vendor. That's not how it works with firmware blobs, the vast, vast majority of the time. The user has the choice to run whatever firmware version they want, for as long as they want. They have strictly more freedom than if the software were not updatable, since they can choose the least evil version.
I can't believe people are still trying to use this argument. It's plainly evident that mutable software gives you more choice than immutable software. Making the argument that autoupdaters are evil and can be abused doesn't suddenly make all mutable software more evil than immutable software.
I can't believe people are still trying to use this argument. It's plainly evident that mutable software gives you more choice than immutable software. Making the argument that autoupdaters are evil and can be abused doesn't suddenly make all mutable software more evil than immutable software.
Incidentally, I'm on their list as a victim:
> 2010-03
> Sony restricted access to the PlayStation 3 GPU, so people who installed a GNU/Linux operating system on the console couldn't use it at full capacity. When some of them broke the restriction, Sony removed the ability to install other operating systems. Then users broke that restriction too, but got sued by Sony.
I'm one of the people who got sued by Sony. And I still think the FSF's take on all this is terrible.
> 2010-03
> Sony restricted access to the PlayStation 3 GPU, so people who installed a GNU/Linux operating system on the console couldn't use it at full capacity. When some of them broke the restriction, Sony removed the ability to install other operating systems. Then users broke that restriction too, but got sued by Sony.
I'm one of the people who got sued by Sony. And I still think the FSF's take on all this is terrible.
The rationale seems to be that if the vendor is able to update the firmware at a later date, then the customer should also have that ability in order for it to be certified.
I just wanted to say I appreciated this comment. You clearly condensed what the problem is, and now I feel like I better understand the situation. It does sound like hypocrisy but in an unworkable, non-starting situation for the FSF.
(Bravo.)
(Bravo.)
Thanks. I understand what the FSF is trying to do. I just think they've gone about it in a stupid way. I see it as an outgrowth if Stallman's old "microwave argument".
He is super zealous about using free software everywhere...until he isn't. His argument being that something like a microwave, despite having some non-Free software, isn't something that can be changed post-sale so he's ok using them.
1. It's actually an outdated example since we're now seeing appliances with Internet connectivity and EULAs.
2. It breaks down almost immediately with modern computer hardware. We're not running big beige towers whose only connectivity is some RS323 ports on the back. Most people are running computers with multiple highly regulated radios, internal batteries, and security subsystems. Fully user programmable functions of these are combinations of impractical, dangerous, and illegal.
I still donate every year to the FSF but these crusades just make me slap my forehead. They're feel good campaigns and encourage more harm than good.
He is super zealous about using free software everywhere...until he isn't. His argument being that something like a microwave, despite having some non-Free software, isn't something that can be changed post-sale so he's ok using them.
1. It's actually an outdated example since we're now seeing appliances with Internet connectivity and EULAs.
2. It breaks down almost immediately with modern computer hardware. We're not running big beige towers whose only connectivity is some RS323 ports on the back. Most people are running computers with multiple highly regulated radios, internal batteries, and security subsystems. Fully user programmable functions of these are combinations of impractical, dangerous, and illegal.
I still donate every year to the FSF but these crusades just make me slap my forehead. They're feel good campaigns and encourage more harm than good.
This is what I missed, well put.
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 the blobs to begin with, second they do not have the ability to study the blobs, and third, they do not have the ability to replace the blobs. By pursing RYF certification, Purism released a device that is objectively worse for the practical freedom of their customers.
> 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 the blobs to begin with, second they do not have the ability to study the blobs, and third, they do not have the ability to replace the blobs. By pursing RYF certification, Purism released a device that is objectively worse for the practical freedom of their customers.
> that users of the Librem 5 phone are objectively harmed in three ways
That's not true though.
First: things that were done in order to move the blobs out of PureOS weren't hidden in any way, to the contrary - they were loudly announced as "steps towards RYF certification", describing exactly how that's supposed to work in public blog posts[0]. I can't see how that counts as "[users] unaware of the existence of the blobs".
Second: the blobs are perfectly accessible to anyone who wants to study them - not only you can download them from repositories online, but you can even access the flash where they're stored on your device; you can also read and modify the code that loads them. What's more - you can even bypass that loading mechanism and load them directly by yourself from the main CPU if you don't care about keeping the blobs out of your rootfs (and some alternative OSes do that already). Which gets us to...
Third: users do have the ability to replace the blobs. Not only can they run an OS that loads the blobs directly - they can even reflash the storage where the blobs are being stored. And no, no disassembling, special tools or weird hardware tricks are necessary - you can just lift the read-only lock purely in software (it's a one-line change to the device tree), which is there mostly to prevent you from accidentally shooting yourself in the foot than anything else.
You may disagree whether the additional effort that went into creating these solutions was worth it - and that's a valid opinion to have, but nothing's artificially locked out from the user, so nobody is "objectively harmed" by it. That part is just false.
Disclaimer: I work for Purism on the Librem 5.
[0] https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...
That's not true though.
First: things that were done in order to move the blobs out of PureOS weren't hidden in any way, to the contrary - they were loudly announced as "steps towards RYF certification", describing exactly how that's supposed to work in public blog posts[0]. I can't see how that counts as "[users] unaware of the existence of the blobs".
Second: the blobs are perfectly accessible to anyone who wants to study them - not only you can download them from repositories online, but you can even access the flash where they're stored on your device; you can also read and modify the code that loads them. What's more - you can even bypass that loading mechanism and load them directly by yourself from the main CPU if you don't care about keeping the blobs out of your rootfs (and some alternative OSes do that already). Which gets us to...
Third: users do have the ability to replace the blobs. Not only can they run an OS that loads the blobs directly - they can even reflash the storage where the blobs are being stored. And no, no disassembling, special tools or weird hardware tricks are necessary - you can just lift the read-only lock purely in software (it's a one-line change to the device tree), which is there mostly to prevent you from accidentally shooting yourself in the foot than anything else.
You may disagree whether the additional effort that went into creating these solutions was worth it - and that's a valid opinion to have, but nothing's artificially locked out from the user, so nobody is "objectively harmed" by it. That part is just false.
Disclaimer: I work for Purism on the Librem 5.
[0] https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...
How much engineering effort went in to this, instead of other improvements like reducing power consumption / increasing battery life?
I would have bought a Librem 5 but haven't only beceause of the power issues (which is same reason I didn't get a Pinephone).
I would have bought a Librem 5 but haven't only beceause of the power issues (which is same reason I didn't get a Pinephone).
Compared to other areas, I'd say "negligible" - but I wasn't involved personally (only joined the team later on), so take it with a grain of salt as it's not impossible that I'm missing something.
The M4 core was already there in the SoC sitting unused, it's not like it was added just for firmware loading ;)
The M4 core was already there in the SoC sitting unused, it's not like it was added just for firmware loading ;)
The problem of course is that Purism markets the phone for security conscious people.
Not hackers who have the skills and impulse to mess around with binary blobs and microcode.
That’s dishonest.
Go take a look at the Purism’s website about the Libre yourself: “Security”, “peace of mind”, “digital privacy”.
You’re openly marketing the phone to regular people and businesses who care about privacy.
Nowhere on the site does it say: “BTW: We’re selling you a crippled phone because we wanted to get a fanatics approval. But if you study computer science you can fix that yourself!”
Not hackers who have the skills and impulse to mess around with binary blobs and microcode.
That’s dishonest.
Go take a look at the Purism’s website about the Libre yourself: “Security”, “peace of mind”, “digital privacy”.
You’re openly marketing the phone to regular people and businesses who care about privacy.
Nowhere on the site does it say: “BTW: We’re selling you a crippled phone because we wanted to get a fanatics approval. But if you study computer science you can fix that yourself!”
> Nowhere on the site does it say: “BTW: We’re selling you a crippled phone because we wanted to get a fanatics approval. But if you study computer science you can fix that yourself!”
Which is good, because it's not "crippled" in any way no matter how technical you are, and having a clear boundary between user's operating system and the hardware with potentially nonfree firmware can be useful even when you're not a "fanatic". Thanks to this boundary, whatever you download from PureOS repositories on the phone is known to provide you the four freedoms, with no exceptions.
Of course not everyone needs to value that, but at least that's the value proposition Purism is offering with PureOS.
Which is good, because it's not "crippled" in any way no matter how technical you are, and having a clear boundary between user's operating system and the hardware with potentially nonfree firmware can be useful even when you're not a "fanatic". Thanks to this boundary, whatever you download from PureOS repositories on the phone is known to provide you the four freedoms, with no exceptions.
Of course not everyone needs to value that, but at least that's the value proposition Purism is offering with PureOS.
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.
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.
Another HN user, tptacek, has made comments going back years now that point out how modern Android (at least Pixels) and iPhones all isolate the baseband behind a serial/USB peripheral interface. I'm not sure you would gain anything at all by going with your surmised setup above.
Many carriers do OTA config stuff when you insert their SIM,
cooperated with by your carrier.
cooperated with by your carrier.
> 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.
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.
last time i looked at their guidelines i understood it that proprietry blobs will be tolerated as long as libre alternatives dont exist. for an organisation that values free software above all else (including security) i think this is a principled approach. i fail to see any hypocricy
on the other hand whenever there is some GNU/FSF topic on hn there are always the same people taking the opportunity to throw mud at these organisations. think of this what you will
on the other hand whenever there is some GNU/FSF topic on hn there are always the same people taking the opportunity to throw mud at these organisations. think of this what you will
Is that hypocrisy, or just an oversight / unintended consequence?
There is a very short list of hardware they do endorse here. I’m not sure if it uses those loopholes or not
https://ryf.fsf.org/
https://ryf.fsf.org/
They do. That bluetooth dongle? Hundreds of kilobytes of proprietary ROM implementing an entire Bluetooth stack (these things always implement at least the lower layers and invariably also support doing the upper layers for HID emulation mode). Those ThinkPads? Embedded microcontrollers with updatable proprietary blobs in Flash memory that you can't audit, and which have direct access to all system RAM via the LPC bus.
What's funny about this list is how much of it amounts to a few companies -- ThinkPenguin, Libiquity, and Technoethical -- rebranding commodity hardware like Atheros wireless cards. There's nothing unique about this hardware which makes it more "free" than any other off-the-shelf Atheros cards, and the drivers were open-source long before any of these companies got involved.
It has been fairly well established that in practice, some of the companies selling with RYF certification are basically scammers. Lots of people have been charged without orders being shipped. Google around the company names for the horror stories.
https://www.reddit.com/r/libreboot/comments/pqs0g0/technoeth...
https://www.reddit.com/r/linux/comments/4hy9hf/ordered_a_lib...
https://www.reddit.com/r/libreboot/comments/pqs0g0/technoeth...
https://www.reddit.com/r/linux/comments/4hy9hf/ordered_a_lib...
I think the ideology of the FSF is a perfectly fine one. It's the hardware vendors that insist on binary blobs that are the problem here.
Nobody produces truly free consumer hardware and nobody has produced any for years now. Everything is hidden away because of fears of patent lawsuits and other people copying this One Neat Trick when initializing the devices.
Intel would lose very little if it published the source code for the blobs loaded into their processors, because the signature requirements prevent anyone else from developing their own microcode, yet it still encrypts and obfuscates the compiled code. The same is true for most chip and UEFI suppliers.
I hope riscv will soon take off in a way that foregoes all of these blobs, though I highly doubt it since modern hardware is encumbered by patents and secrets. It's a sad reality that free, libre computers do not exist and blaming the FSF for having high standards is the wrong approach.
Nobody produces truly free consumer hardware and nobody has produced any for years now. Everything is hidden away because of fears of patent lawsuits and other people copying this One Neat Trick when initializing the devices.
Intel would lose very little if it published the source code for the blobs loaded into their processors, because the signature requirements prevent anyone else from developing their own microcode, yet it still encrypts and obfuscates the compiled code. The same is true for most chip and UEFI suppliers.
I hope riscv will soon take off in a way that foregoes all of these blobs, though I highly doubt it since modern hardware is encumbered by patents and secrets. It's a sad reality that free, libre computers do not exist and blaming the FSF for having high standards is the wrong approach.
At this point, I think that's become a cop-out on their part. If they really want to make their vision of truly open hardware a reality, they need to roll up their sleeves and make it happen.
Mostly open (due to reverse-engineering) FPGAs are a thing, SkyWater is a thing, RISC-V is a thing. Take one of the open source RISC-V designs, design and build a test system using an FPGA[1] (or more than one... depending on what is needed) so you've got something to put on a board, once the design is validated use SkyWater to produce a small run of actual chips to replace the (proprietary) FPGA(s) and produce a 100% open CPU etc. as needed.[2] Sure, performance will be dismal compared to the latest silicon from Apple/Intel/AMD but it will be infinitely better than the Unobtainium processor / system they continue to fantasize about.[3] Yes, they'll probably have to jettison things like cellular and probably WiFi support due to IP issues. (note: that's not to say a wireless solution would be impossible, just that it wouldn't be one of the widely deployed or mainstream ones[4]) I understand that this isn't a simple task but how would it be more work than whining for decades with virtually nothing to show for it (given their requirements) on the hardware front?
Build a bad open source device that you can iterate on rather than complaining about for-profit companies behaving like for-profit companies. Right now open source hardware is decades behind and sitting around waiting doesn't seem to be accomplishing much.
[1] Better yet, design a fully open source FPGA of their own. Sure, it will be a couple/few decades behind the state of the art. But it would provide a starting point to build on.
[2] Of course this would take multiple iterations. One approach would be to see if Google would sponsor this as part of their partnership with SkyWater. Worst case, the FSF might have to do some light fundraising for the iterations.
[3] Again, it would likely be a couple of decades or more behind the state of the art. This too would provide a starting point. Then they could use the finished product as a fund raising aid (i.e. sell it) to fund future iterations.
[4] Open source SDR is a thing, for example.
Mostly open (due to reverse-engineering) FPGAs are a thing, SkyWater is a thing, RISC-V is a thing. Take one of the open source RISC-V designs, design and build a test system using an FPGA[1] (or more than one... depending on what is needed) so you've got something to put on a board, once the design is validated use SkyWater to produce a small run of actual chips to replace the (proprietary) FPGA(s) and produce a 100% open CPU etc. as needed.[2] Sure, performance will be dismal compared to the latest silicon from Apple/Intel/AMD but it will be infinitely better than the Unobtainium processor / system they continue to fantasize about.[3] Yes, they'll probably have to jettison things like cellular and probably WiFi support due to IP issues. (note: that's not to say a wireless solution would be impossible, just that it wouldn't be one of the widely deployed or mainstream ones[4]) I understand that this isn't a simple task but how would it be more work than whining for decades with virtually nothing to show for it (given their requirements) on the hardware front?
Build a bad open source device that you can iterate on rather than complaining about for-profit companies behaving like for-profit companies. Right now open source hardware is decades behind and sitting around waiting doesn't seem to be accomplishing much.
[1] Better yet, design a fully open source FPGA of their own. Sure, it will be a couple/few decades behind the state of the art. But it would provide a starting point to build on.
[2] Of course this would take multiple iterations. One approach would be to see if Google would sponsor this as part of their partnership with SkyWater. Worst case, the FSF might have to do some light fundraising for the iterations.
[3] Again, it would likely be a couple of decades or more behind the state of the art. This too would provide a starting point. Then they could use the finished product as a fund raising aid (i.e. sell it) to fund future iterations.
[4] Open source SDR is a thing, for example.
IMHO, we need a free hardware foundation today just like we needed FSF in the 80-90's.
I'm with you, and that's probably a good summary of my point. At this stage it's probably safe to say that the FSF isn't likely to ever add much value in the hardware realm.
> I think the ideology of the FSF is a perfectly fine one. It's the hardware vendors that insist on binary blobs that are the problem here.
Their ideology has led them into preferring proprietary firmware that is inaccessible to the user like in the Purism example. I hate that, there is hope that a device that requires binary blobs from the main OS can be reverse engineered and free software developed for it. Making it inaccessible to tinkering is strictly worse for the user in all respects.
Their ideology has led them into preferring proprietary firmware that is inaccessible to the user like in the Purism example. I hate that, there is hope that a device that requires binary blobs from the main OS can be reverse engineered and free software developed for it. Making it inaccessible to tinkering is strictly worse for the user in all respects.
> Making it inaccessible to tinkering is strictly worse for the user in all respects.
"all respects" is wrong. It also makes it so the proprietary developer can't say "here is a new version, but you must agree to some very nasty license terms, or accept some malicious feature along with it." NOT having a capability does have advantages, a physical book is impossible to be remotely deleted out of existence by DRM, but sure, you can't tinker with the software.
edit: yes, I understand in that the case of sticking the exact same software in a rom vs a read-write memory hurts the ability of a user reverse engineering it, which could ironically decrease user freedom over time. Calling this out for FSF to address is a good thing.
"all respects" is wrong. It also makes it so the proprietary developer can't say "here is a new version, but you must agree to some very nasty license terms, or accept some malicious feature along with it." NOT having a capability does have advantages, a physical book is impossible to be remotely deleted out of existence by DRM, but sure, you can't tinker with the software.
edit: yes, I understand in that the case of sticking the exact same software in a rom vs a read-write memory hurts the ability of a user reverse engineering it, which could ironically decrease user freedom over time. Calling this out for FSF to address is a good thing.
You're taking the vendor at their word. You can't do this. It has happened before (see Intel vPro) that some feature is not actually impossible to activate, etc.
> proprietary firmware that is inaccessible to the user like in the Purism example. I hate that
Personally I'd hate that too - thankfully, that's not what happens on the Librem 5 (see my other comments in this thread for details).
Personally I'd hate that too - thankfully, that's not what happens on the Librem 5 (see my other comments in this thread for details).
People are parroting "the purism example...". Just stop it! Librem-5 is NOT certified!
But they want to be certified, and the hilarious RAM initialization workaround was absolutely done as part of trying to get certified.
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.
FWIW, nothing stops Librem 5 users from just throwing away all that nonsense code they wrote to load the firmware from a dedicated flash, and just flash standard U-Boot (which already includes a mechanism to embed the blob, which is the normal way to do it), at which point you can of course modify it or replace it.
Basically, it's a whole bunch of wasted engineering effort, but it in no way accomplishes actually turning the blob into "hardware" or making it immutable. It's just rules-lawyering. Which makes it even more pointless and nonsensical. The sticking point seems to have actually been not having the main CPU touch the physical bits of the blob (not execute; touch); avoiding that magically made it RYF-certifiable. This is why they moved the loading process to a secondary core (that still runs open source code, which then loads the blob into a third core that runs it).
Basically, it's a whole bunch of wasted engineering effort, but it in no way accomplishes actually turning the blob into "hardware" or making it immutable. It's just rules-lawyering. Which makes it even more pointless and nonsensical. The sticking point seems to have actually been not having the main CPU touch the physical bits of the blob (not execute; touch); avoiding that magically made it RYF-certifiable. This is why they moved the loading process to a secondary core (that still runs open source code, which then loads the blob into a third core that runs it).
> storing the firmware in a way that prevents the user from updating it via software
Nothing prevents the firmware being updated by the user on the Librem 5. The default kernel marks the SPI flash as read-only (mostly to prevent accidental soft-brick situations), but you can simply lift it up, or reflash it from the bootloader where there's no such restriction applied.
The firmware update is not intended to be done by the user - PureOS does not ever ask you to do that and it does not even provide the blobs in its repos; but if you want to update it for some reason, you're not prevented from doing so. You could always reflash the SPI flash with a hardware flasher (or even completely replace it) anyway, so it would be pointless to artificially prevent a motivated user from doing so in software. After all, they may be trying to use a free replacement that may show up in the future.
Nothing prevents the firmware being updated by the user on the Librem 5. The default kernel marks the SPI flash as read-only (mostly to prevent accidental soft-brick situations), but you can simply lift it up, or reflash it from the bootloader where there's no such restriction applied.
The firmware update is not intended to be done by the user - PureOS does not ever ask you to do that and it does not even provide the blobs in its repos; but if you want to update it for some reason, you're not prevented from doing so. You could always reflash the SPI flash with a hardware flasher (or even completely replace it) anyway, so it would be pointless to artificially prevent a motivated user from doing so in software. After all, they may be trying to use a free replacement that may show up in the future.
DRM garbage also adds to the incentives of using blob firmware.
For example for GPUs it goes a bit like this:
You need to support HDCP? Use a blob. You want to have a separate FOSS firmware without HDCP? An extra expense that bean counters won't like.
For example for GPUs it goes a bit like this:
You need to support HDCP? Use a blob. You want to have a separate FOSS firmware without HDCP? An extra expense that bean counters won't like.
Not only does the FSF object to the inclusion of nonfree firmware, but it also objects to even so much as making it available. Case study here would be OpenBSD, which is about as free of an operating system as it gets, and which does not ship with nonfree firmware by default. However, because of the existence of the `fw_update` command (which - by the explicit consent of the user/owner of the machine - fetches any nonfree firmware necessary for the hardware on one's system), OpenBSD doesn't qualify for the FSF's endorsement.
The FSF's stance here also impacts the "ports" trees of various BSDs and (GNU/)Linuxen; if they so much as include instructions for compiling and installing nonfree software (regardless of whether they actually include nonfree software), the FSF considers the whole OS nonfree. Same deal with any (GNU/)Linux distro that maintains a nonfree repo - even if that repo is disabled by default.
The rationale for these sorts of stances is that even so much as making nonfree software available for installation is an "endorsement" of that software. In spite of that rationale, the FSF maintains officially-sanctioned precompiled ports of software like GIMP for nonfree operating systems like Windows and macOS - because apparently it's okay to endorse those nonfree operating systems, because reasons.
The FSF's stance here also impacts the "ports" trees of various BSDs and (GNU/)Linuxen; if they so much as include instructions for compiling and installing nonfree software (regardless of whether they actually include nonfree software), the FSF considers the whole OS nonfree. Same deal with any (GNU/)Linux distro that maintains a nonfree repo - even if that repo is disabled by default.
The rationale for these sorts of stances is that even so much as making nonfree software available for installation is an "endorsement" of that software. In spite of that rationale, the FSF maintains officially-sanctioned precompiled ports of software like GIMP for nonfree operating systems like Windows and macOS - because apparently it's okay to endorse those nonfree operating systems, because reasons.
They explicitly rationalize the Windows builds of Emacs, so I can only assume that's the same rationale as for any other GNU software
> To improve the use of proprietary systems is a misguided goal. Our aim, rather, is to eliminate them. We include support for some proprietary systems in GNU Emacs in the hope that running Emacs on them will give users a taste of freedom and thus lead them to free themselves.
Taken from https://www.gnu.org/software/emacs/download.html
> To improve the use of proprietary systems is a misguided goal. Our aim, rather, is to eliminate them. We include support for some proprietary systems in GNU Emacs in the hope that running Emacs on them will give users a taste of freedom and thus lead them to free themselves.
Taken from https://www.gnu.org/software/emacs/download.html
We include support for some proprietary systems in GNU Emacs in the
hope that running Emacs on them will give users a taste of freedom
The weakness of this sauce is staggering. I understand GNU Emacs wanting to preserve forty years of hard work supporting Windows and MacOS, but justifying it via the "taste of freedom" sets off my hypocrisy alarm. It's also just patently false because emacs users stick with Windows precisely because emacs still works there.
The weakness of this sauce is staggering. I understand GNU Emacs wanting to preserve forty years of hard work supporting Windows and MacOS, but justifying it via the "taste of freedom" sets off my hypocrisy alarm. It's also just patently false because emacs users stick with Windows precisely because emacs still works there.
Not to mention that running a free operating system with a handful of nonfree programs is by every objective measure a far bigger taste of freedom than running a nonfree operating system with a handful of free programs.
the FSF maintains officially-sanctioned precompiled ports of software like GIMP for
nonfree operating systems like Windows and macOS - because apparently
it's okay to endorse those nonfree operating systems, because reasons.
I've been for the last year shouting myself hoarse on emacs forums regarding this hypocrisy.
I've been for the last year shouting myself hoarse on emacs forums regarding this hypocrisy.
I think it's important to understand that "being free" and "endorsed by FSF" are two completely distinct states. It's not enough to be fully free to get endorsed - FSF has their right to decide fully arbitrarily what's acceptable enough to endorse it and what isn't, and being technically free is just one of the aspects they are considering. Endorsement isn't technical, it's political.
> the FSF considers the whole OS nonfree
As an example, the FSF does not consider Debian nonfree - they even acknowledge that "Debian is the only common non-endorsed distribution to keep nonfree blobs out of its main distribution"; they just don't want to endorse it because it points people to nonfree software. As a user, I don't mind that it does so I use Debian, but FSF is free to not want to endorse it because of that.
> the FSF considers the whole OS nonfree
As an example, the FSF does not consider Debian nonfree - they even acknowledge that "Debian is the only common non-endorsed distribution to keep nonfree blobs out of its main distribution"; they just don't want to endorse it because it points people to nonfree software. As a user, I don't mind that it does so I use Debian, but FSF is free to not want to endorse it because of that.
> Not only does the FSF object to the inclusion of nonfree firmware, but it also objects to even so much as making it available
Guix is FSF approved and also gives the ability to enable nonfree-firmware?
I know Debian is excluded for hosting nonfree software, even if disabled by default
Guix is FSF approved and also gives the ability to enable nonfree-firmware?
I know Debian is excluded for hosting nonfree software, even if disabled by default
About the microcode: the argument is basically "It is good nonfree software, just give up and accept it." Sorry? This is FSF. And no, it is not always good: https://www.theregister.com/2018/08/21/intel_cpu_patch_licen..., and when people don't accept it, https://www.theregister.com/2018/08/23/intel_microcode_licen.... If a majority of intel's customers said: sorry, we'll find other solutions rather than accepting your nonfree license, intel would freely license it.
> In other words, you can’t microcode update a CPU to add or substantially change capabilities.
There is CCC security presentation floating around where someone reversed engineered microcode before it was signed, and designed a backdoor into it, a remote code execution triggered by going to a specific webpage. That is a substantial capability that exists in todays microcode.
> In other words, you can’t microcode update a CPU to add or substantially change capabilities.
There is CCC security presentation floating around where someone reversed engineered microcode before it was signed, and designed a backdoor into it, a remote code execution triggered by going to a specific webpage. That is a substantial capability that exists in todays microcode.
> It is good nonfree software, just give up and accept it.
You already accepted it when you bought the CPU and it came with the base version. Your choices are to install a bugfix, or not. The FSF advocates for not installing the bugfix, or even informing users of the possibility of doing so. That is utterly illogical. There is no reason whatsoever to run broken proprietary software over fixed proprietary software.
You already accepted it when you bought the CPU and it came with the base version. Your choices are to install a bugfix, or not. The FSF advocates for not installing the bugfix, or even informing users of the possibility of doing so. That is utterly illogical. There is no reason whatsoever to run broken proprietary software over fixed proprietary software.
> You already accepted it when you bought the CPU and it came with the base version.
No, that is a version you can't physically modify. The other version is one you can't modify because of it's license and signature verification. You are simply ignoring important differences, like saying an elevator is no different than a flight of stairs, they both get you up, and anyone who avoids elevators must be an idiot.
No, that is a version you can't physically modify. The other version is one you can't modify because of it's license and signature verification. You are simply ignoring important differences, like saying an elevator is no different than a flight of stairs, they both get you up, and anyone who avoids elevators must be an idiot.
... but you can modify the base version. That's how microcode updates work, they patch it (via a patch register CAM). Are you trying to argue that the physical mechanism used for patching matters? That's an implementation detail, it has nothing to do with freedom.
Your CPU comes with patchable proprietary software. Period.
Your CPU comes with patchable proprietary software. Period.
> ... but you can modify the base version.
There is some read-only memory that contains the base version. It is executed on boot. You can tell the cpu to run a different version by pointing it to a different version during the boot process (or later). You can't change the version in the read-only memory.
There is some read-only memory that contains the base version. It is executed on boot. You can tell the cpu to run a different version by pointing it to a different version during the boot process (or later). You can't change the version in the read-only memory.
That's not how it works.
The way it works is that the microcode update gets loaded into some (smaller) RAM next to the ROM, and then patch registers are loaded which virtually rewrite some ROM locations to jump to the RAM (at least for the duration of this boot), in order to update the broken bits.
You are literally hot-patching the ROM with an overlay. You are not replacing it wholesale.
And either way, as I said, the underlying technical mechanism is completely irrelevant for the purposes of assessing user freedom. You're running proprietary code. You could be running a less buggy version of the same proprietary code. Choosing not to is silly and only hurts you. Trying to take that option away from users of your software is anti-freedom.
The way it works is that the microcode update gets loaded into some (smaller) RAM next to the ROM, and then patch registers are loaded which virtually rewrite some ROM locations to jump to the RAM (at least for the duration of this boot), in order to update the broken bits.
You are literally hot-patching the ROM with an overlay. You are not replacing it wholesale.
And either way, as I said, the underlying technical mechanism is completely irrelevant for the purposes of assessing user freedom. You're running proprietary code. You could be running a less buggy version of the same proprietary code. Choosing not to is silly and only hurts you. Trying to take that option away from users of your software is anti-freedom.
If the FSF thinks that even having proprietary blobs is bad, why does the rule apply only to mutable copies? Why not just refuse to certify devices with hardware that contains blobs contrary to their values? There's no practical argument as to why it's only acceptable to allow a nonfree blob if it's not burned into silicon. Even if it did matter, from the perspective of a normal person, microcode in a chip versus microcode loaded after boot offers no meaningful distinction in functionality or freedoms. If the point is high standards, then why have this loophole at all?
If the answer is "because then nothing could be certified or recommended" (which I expect it would be) then you need to stop marketing the certification as a recommendation for actual people to buy hardware and instead market it as a certification of whether the product is in line with their ideals.
If the answer is "because then nothing could be certified or recommended" (which I expect it would be) then you need to stop marketing the certification as a recommendation for actual people to buy hardware and instead market it as a certification of whether the product is in line with their ideals.
> ...In other words, you can’t microcode update a CPU to add or substantially change capabilities...
> ... vulnerabilities such as Meltdown and Spectre, which were partially mitigated through a microcode update ...
Of these two snippets, only one can be true. Either opaque microcode updates can substantially change how a system performs, or they can't. These mitigations are major changes to how the processor works.
This post looks to me like a fairly typical "doesn't quite get what they mean by freedom" take, of which there are many (which is cool, freedom isn't everyone's cup of tea). The FSF has been quite consistent that if there is a choice to be made, the user should have a practical way of making that choice. If the manufacturer can change how a CPU works with a microcode update, the user should be able to as well.
The FSF has a clear role here. Their job is to say "this software is free, this software is not". People constantly call on them to compromise on that role in the name of security/convenience/helpfulness/strategic adoption concerns/the impractical nature of their stance. The FSF should and does ignore those people. They are a (slightly quirky, yes) moral lighthouse more than an adoption friendly technical project. This microcode is not free software and someone should be pointing that out and complaining about it. If the FSF isn't taking a stand against non-free microcode, who will?
> ... vulnerabilities such as Meltdown and Spectre, which were partially mitigated through a microcode update ...
Of these two snippets, only one can be true. Either opaque microcode updates can substantially change how a system performs, or they can't. These mitigations are major changes to how the processor works.
This post looks to me like a fairly typical "doesn't quite get what they mean by freedom" take, of which there are many (which is cool, freedom isn't everyone's cup of tea). The FSF has been quite consistent that if there is a choice to be made, the user should have a practical way of making that choice. If the manufacturer can change how a CPU works with a microcode update, the user should be able to as well.
The FSF has a clear role here. Their job is to say "this software is free, this software is not". People constantly call on them to compromise on that role in the name of security/convenience/helpfulness/strategic adoption concerns/the impractical nature of their stance. The FSF should and does ignore those people. They are a (slightly quirky, yes) moral lighthouse more than an adoption friendly technical project. This microcode is not free software and someone should be pointing that out and complaining about it. If the FSF isn't taking a stand against non-free microcode, who will?
A majority of microcode updates aren't actual code, but are programming large swaths of undocumented registers known as "chicken bits" which turn off functionality and affect system operation. You can see what a rough fix looks like in Linux patches for devices that don't get these microcode updates: https://lore.kernel.org/lkml/b4ad7273efbb0c60a6c93ae68f82a44...
No, the details of what these MSR registers do isn't public. But it's far from being code; it's simply rather tweaking a large switchboard of functionality which already existed on your CPU. It is not adding new features or code to the execution pipeline.
Modern process development pipelines are already far too long that a common thing to do is to put an experimental feature in all CPUs and only enable it with the right microcode and chicken bits when it works well enough for general use. It's not uncommon for new processor features to have a 5-6 lag from "first buggy implementation" to "general implementation".
No, the details of what these MSR registers do isn't public. But it's far from being code; it's simply rather tweaking a large switchboard of functionality which already existed on your CPU. It is not adding new features or code to the execution pipeline.
Modern process development pipelines are already far too long that a common thing to do is to put an experimental feature in all CPUs and only enable it with the right microcode and chicken bits when it works well enough for general use. It's not uncommon for new processor features to have a 5-6 lag from "first buggy implementation" to "general implementation".
> Their job is to say "this software is free, this software is not".
But if they say "this software is free because the hardware is more locked down" then I don't see that as standing for user freedoms.
> People constantly call on them to compromise
It's about being more nuanced, not about making compromises.
But if they say "this software is free because the hardware is more locked down" then I don't see that as standing for user freedoms.
> People constantly call on them to compromise
It's about being more nuanced, not about making compromises.
Yet they are fine with running microcode as long you don't update it. It doesn't make sense. Blobs don't disappear just because they are hidden in ROM.
Apparently it's OK because both the vendor and the user are prevented from updating it. Thus there's no power differential between them on that specific point.
That one kinda makes sense, because, when you can't update it, there isn't really much of a practical difference between something implemented in hardware or firmware. So not allowing blobs in rom would almost be hypocritical if you don't also mandate that the actual silicon of the chip is completely free.
FSF's hardline attitude has always rubbed me the wrong way. I respect and support their goals but at the end of the day software should respect the needs and desires of their users
I saw this on the nonguix repo for all non free software for guix
> Please do NOT promote this repository on any official Guix communication channels, such as their mailing lists or IRC channel, even in response to support requests! This is to show respect for the Guix project’s strict policy against recommending nonfree software, and to avoid any unnecessary hostility.
To do my job and boot my laptop nonguix is required but not even allowed to talk about it with the OS it intends to support, is not something I can agree with
I think the above is the type of side-effects seen with a hardline policy of the FSF. Obviously I'm not the target of this type of policy, but I still feel more good can be done in the long run with a little compromise to the realities of using a computer today
I saw this on the nonguix repo for all non free software for guix
> Please do NOT promote this repository on any official Guix communication channels, such as their mailing lists or IRC channel, even in response to support requests! This is to show respect for the Guix project’s strict policy against recommending nonfree software, and to avoid any unnecessary hostility.
To do my job and boot my laptop nonguix is required but not even allowed to talk about it with the OS it intends to support, is not something I can agree with
I think the above is the type of side-effects seen with a hardline policy of the FSF. Obviously I'm not the target of this type of policy, but I still feel more good can be done in the long run with a little compromise to the realities of using a computer today
> To do my job and boot my laptop nonguix is required but not even allowed to talk about it with the OS it intends to support, is not something I can agree with
The OS isn't a person. The OS has online discussion forums and the people who develop the OS CAN talk about it in the appropriate forum. Identifying and separating nonfree issues is a useful tool in their goals.
The FSF last year started a new campaign that is specifically meant to not be hardline and to respect the needs and desires of users: https://www.fsf.org/blogs/community/support-the-freedom-ladd....
The OS isn't a person. The OS has online discussion forums and the people who develop the OS CAN talk about it in the appropriate forum. Identifying and separating nonfree issues is a useful tool in their goals.
The FSF last year started a new campaign that is specifically meant to not be hardline and to respect the needs and desires of users: https://www.fsf.org/blogs/community/support-the-freedom-ladd....
> Identifying and separating nonfree issues is a useful tool in their goals.
Issues are not always easily separated but I understand it's a tool for their goals. It's just not for me
> The FSF last year started a new campaign that is specifically meant to not be hardline and to respect the needs and desires of users: https://www.fsf.org/blogs/community/support-the-freedom-ladd....
I was not aware of this - I will read up on it. Thank you
Issues are not always easily separated but I understand it's a tool for their goals. It's just not for me
> The FSF last year started a new campaign that is specifically meant to not be hardline and to respect the needs and desires of users: https://www.fsf.org/blogs/community/support-the-freedom-ladd....
I was not aware of this - I will read up on it. Thank you
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.
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.
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.
Oh, sure, that would be preferred but I can't see that happening anytime soon. I guess it all depends on whether you feel like the FSFs polices will bring improvement for open blobs etc
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 by Stallman's charisma to make chips that are not cutting edge but decent, and libre.
Whatever your thoughts are on China but I would suggest to the FSF to slowly move in that direction. Where all the component schematics are open and viewable. At least to go for auditability since no one trusts the Chinese.
Like I said, forgive the naivete, but it feels like a noble yet lofty goal.
And then proceed to go into every industry with right to repair issues. Deere tractor competitors, home appliances, and so on. In the name of component longevity and repairability. All of this to repudiate forced obsolescence and to promote end user freedoms.
It's a stretch but I enjoy dreaming about it. Hoping a better world is possible.
I think China has a few companies working on domestic processors. Let's say they are convinced by Stallman's charisma to make chips that are not cutting edge but decent, and libre.
Whatever your thoughts are on China but I would suggest to the FSF to slowly move in that direction. Where all the component schematics are open and viewable. At least to go for auditability since no one trusts the Chinese.
Like I said, forgive the naivete, but it feels like a noble yet lofty goal.
And then proceed to go into every industry with right to repair issues. Deere tractor competitors, home appliances, and so on. In the name of component longevity and repairability. All of this to repudiate forced obsolescence and to promote end user freedoms.
It's a stretch but I enjoy dreaming about it. Hoping a better world is possible.
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 made resistant to attempts to change their function in an effort to limit people's ability to transmit stuff unintentionally (or intentionally). Modern radio protocols are heavily dependent on SDR (software defined radio), so fixed function is probably infeasible. You could make the firmware unchangeable, but now any bugs discovered in your public source code are now entirely uncorrectable.
Heck, even the SDR community is having to be really careful about not drawing the ire of the FCC. That's why so few of them tend to advertise transmit capabilities.
The main ARM cores have been generally blob-less, but that's only the cores. Various SOCs require blobs to initialize. Their GPUs are all proprietary blobs up and down the stack.
So you basically would have to make your own GPU, your own radios, etc. and integrate them into your own SOC - and get the regulatory bodies to certify them for sale in their various countries. You then have to fight the entrenched companies in court over IP for years. The GPU portion will be especially tricky. The moment you try, lawyers from Nvidia, AMD, Imagination Technologies, Apple, etc. will be all over you. The radios will have Qualcomm, Broadcom, and Intel all over you.
So technical, legal, and regulatory hurdles - which is why I say next to impossible, especially on the FSF's budget.
- a jaded hobbyist
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 made resistant to attempts to change their function in an effort to limit people's ability to transmit stuff unintentionally (or intentionally). Modern radio protocols are heavily dependent on SDR (software defined radio), so fixed function is probably infeasible. You could make the firmware unchangeable, but now any bugs discovered in your public source code are now entirely uncorrectable.
Heck, even the SDR community is having to be really careful about not drawing the ire of the FCC. That's why so few of them tend to advertise transmit capabilities.
The main ARM cores have been generally blob-less, but that's only the cores. Various SOCs require blobs to initialize. Their GPUs are all proprietary blobs up and down the stack.
So you basically would have to make your own GPU, your own radios, etc. and integrate them into your own SOC - and get the regulatory bodies to certify them for sale in their various countries. You then have to fight the entrenched companies in court over IP for years. The GPU portion will be especially tricky. The moment you try, lawyers from Nvidia, AMD, Imagination Technologies, Apple, etc. will be all over you. The radios will have Qualcomm, Broadcom, and Intel all over you.
So technical, legal, and regulatory hurdles - which is why I say next to impossible, especially on the FSF's budget.
- a jaded hobbyist
There are some old WiFi devices with libre firmware, but they only support old WiFi standards.
https://github.com/qca/open-ath9k-htc-firmware https://github.com/chunkeey/carl9170fw http://netweb.ing.unibs.it/~openfwwf/
Some also call into the initial version of their code that is in the ROM, and don't have enough RAM to update all of the ROM to the current code. Things like the Osmocom Baseband code also do this.
https://www.osmocom.org/projects/baseband/
https://github.com/qca/open-ath9k-htc-firmware https://github.com/chunkeey/carl9170fw http://netweb.ing.unibs.it/~openfwwf/
Some also call into the initial version of their code that is in the ROM, and don't have enough RAM to update all of the ROM to the current code. Things like the Osmocom Baseband code also do this.
https://www.osmocom.org/projects/baseband/
> 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.
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.
> it's almost mandated by law that there can't be. FCC regulations require that devices be made resistant to attempts to change their function in an effort to limit people's ability to transmit stuff unintentionally (or intentionally). Modern radio protocols are heavily dependent on SDR (software defined radio), so fixed function is probably infeasible. You could make the firmware unchangeable, but now any bugs discovered in your public source code are now entirely uncorrectable.
1. You can use signed firmwares to make it both compliant and upgradable.
2. You can separate the controller/receiver and the transmitter, and only lock up/restrict the transmitter part. Alternatively, you can implement the restriction at the hardware level if feasible (effectively making it fixed function).
3. Finally, you can sell the parts individually to serve a separate market segment.
1. You can use signed firmwares to make it both compliant and upgradable.
2. You can separate the controller/receiver and the transmitter, and only lock up/restrict the transmitter part. Alternatively, you can implement the restriction at the hardware level if feasible (effectively making it fixed function).
3. Finally, you can sell the parts individually to serve a separate market segment.
> You can separate the controller/receiver and the transmitter, and only lock up/restrict the transmitter part.
Unfortunately this isn't quite enough for compliance, because of stuff like DFS channels/radar detection.
> Alternatively, you can implement the restriction at the hardware level if feasible
Not super feasible, and --- inability to update/fix bugs isn't a feature.
Unfortunately this isn't quite enough for compliance, because of stuff like DFS channels/radar detection.
> Alternatively, you can implement the restriction at the hardware level if feasible
Not super feasible, and --- inability to update/fix bugs isn't a feature.
> You can use signed firmwares to make it both compliant and upgradable.
The FSF would not be okay with this though, as it would be a GPLv3 violation to prevent users from replacing the firmware with a modified version.
The FSF would not be okay with this though, as it would be a GPLv3 violation to prevent users from replacing the firmware with a modified version.
That "libre" gives you auditability is a common myth believed by those pushing for libre hardware. The reality is you can't audit silicon, because it's a destructive process requiring extremely expensive analysis equipment.
You always have to trust the chip manufacturer; doesn't matter how documented the chip design is, even if the masks are outright public. You can never know that your CPU is not backdoored. That's just a physical reality.
There is one exception: FPGAs, under the premise that "generically" backdooring an FPGA is computationally infeasible. That's how Precursor gets to seriously claim trustability.
https://www.crowdsupply.com/sutajio-kosagi/precursor
But if you want more than a 100MHz RISC-V softcore you're going to have to trust the silicon vendor.
You always have to trust the chip manufacturer; doesn't matter how documented the chip design is, even if the masks are outright public. You can never know that your CPU is not backdoored. That's just a physical reality.
There is one exception: FPGAs, under the premise that "generically" backdooring an FPGA is computationally infeasible. That's how Precursor gets to seriously claim trustability.
https://www.crowdsupply.com/sutajio-kosagi/precursor
But if you want more than a 100MHz RISC-V softcore you're going to have to trust the silicon vendor.
> There is one exception: FPGAs, under the premise that "generically" backdooring an FPGA is computationally infeasible.
IMO, this isn't a reasonable premise.
- The entire boundary scan chain is a backdoor. You could have an embedded processor poking around looking for things that look like RISC-V code and adding implants or observe state.
- You could make SERDESes do various kinds of naughty things when certain patterns go by-- dump some scan chain info, so you can kick some special packets and read out state remotely. Same thing for other dedicated peripherals that are connected to the outside world. This could be a pretty small number of gates compared to the processor implant idea.
- You could make naughty patterns of bits crossing places do bad stuff. Think of dynamic effects like rowhammer being deliberately included, so if you know the design you can figure out what outside data will trigger bits to flip and state to leak. (Yes, I know that block rams are SRAMs, but that doesn't mean you can't deliberately add capacitive coupling or screw up synchronizers in various ways. And it looks like we may have block NVRAMs soon, so that opens the possibility for various evil even more).
- You could deliberately break some kinds of operations-- e.g. make elliptic curve cryptography unreliable in some cases so you leak key data.
Note the various defense and national security applications of FPGAs. They're a wonderful target for state actors to try to backdoor.
IMO, this isn't a reasonable premise.
- The entire boundary scan chain is a backdoor. You could have an embedded processor poking around looking for things that look like RISC-V code and adding implants or observe state.
- You could make SERDESes do various kinds of naughty things when certain patterns go by-- dump some scan chain info, so you can kick some special packets and read out state remotely. Same thing for other dedicated peripherals that are connected to the outside world. This could be a pretty small number of gates compared to the processor implant idea.
- You could make naughty patterns of bits crossing places do bad stuff. Think of dynamic effects like rowhammer being deliberately included, so if you know the design you can figure out what outside data will trigger bits to flip and state to leak. (Yes, I know that block rams are SRAMs, but that doesn't mean you can't deliberately add capacitive coupling or screw up synchronizers in various ways. And it looks like we may have block NVRAMs soon, so that opens the possibility for various evil even more).
- You could deliberately break some kinds of operations-- e.g. make elliptic curve cryptography unreliable in some cases so you leak key data.
Note the various defense and national security applications of FPGAs. They're a wonderful target for state actors to try to backdoor.
> The entire boundary scan chain is a backdoor. You could have an embedded processor poking around looking for things that look like RISC-V code and adding implants or observe state.
The point is that is not feasible when the design layout is randomized. Reverse engineering FPGA bitstreams is a notoriously hard problem. You might detect your synthesis of RISC-V but there is no algorithm that can detect any RISC-V, and definitely no algorithm that can do that in a tiny low power embedded processor that can pass by unnoticed.
> You could make SERDESes do various kinds of naughty things when certain patterns go by-- dump some scan chain info, so you can kick some special packets and read out state remotely.
Yes, backdooring I/O is still possible. But it significantly raises the bar for the backdoor, since now you're relying on significant back and forth to probe deeper into the system. This isn't an absolute defense, it's just better than hard silicon because you can make backdooring the core logic impractical, especially self-contained.
> You could make naughty patterns of bits crossing places do bad stuff. Think of dynamic effects like rowhammer being deliberately included, so if you know the design you can figure out what outside data will trigger bits to flip and state to leak. (Yes, I know that block rams are SRAMs, but that doesn't mean you can't deliberately add capacitive coupling or screw up synchronizers in various ways. And it looks like we may have block NVRAMs soon, so that opens the possibility for various evil even more).
With design randomization, you can make it hard to detect patterns like that. Think things like randomizing the polarity of each bit line going in/out of RAM. Again, the point is the backdoor has to work with any design, and this opens up a wide range of mitigations that you can implement at that stage, that make it a lot less practical.
Keep in mind I'm bringing this up in the context of people believing that some ThinkPad the FSF rubber-stamped respects your freedom (and security) when it contains microcontrollers hooked up to LPC running secret blobs. Yes, if we want to go deeper down the rabbit hole of hardware trustability, there is definitely more to be done after Precursor, but it's a particularly clever example of how to at least attempt to begin to solve the silicon trust problem.
The point is that is not feasible when the design layout is randomized. Reverse engineering FPGA bitstreams is a notoriously hard problem. You might detect your synthesis of RISC-V but there is no algorithm that can detect any RISC-V, and definitely no algorithm that can do that in a tiny low power embedded processor that can pass by unnoticed.
> You could make SERDESes do various kinds of naughty things when certain patterns go by-- dump some scan chain info, so you can kick some special packets and read out state remotely.
Yes, backdooring I/O is still possible. But it significantly raises the bar for the backdoor, since now you're relying on significant back and forth to probe deeper into the system. This isn't an absolute defense, it's just better than hard silicon because you can make backdooring the core logic impractical, especially self-contained.
> You could make naughty patterns of bits crossing places do bad stuff. Think of dynamic effects like rowhammer being deliberately included, so if you know the design you can figure out what outside data will trigger bits to flip and state to leak. (Yes, I know that block rams are SRAMs, but that doesn't mean you can't deliberately add capacitive coupling or screw up synchronizers in various ways. And it looks like we may have block NVRAMs soon, so that opens the possibility for various evil even more).
With design randomization, you can make it hard to detect patterns like that. Think things like randomizing the polarity of each bit line going in/out of RAM. Again, the point is the backdoor has to work with any design, and this opens up a wide range of mitigations that you can implement at that stage, that make it a lot less practical.
Keep in mind I'm bringing this up in the context of people believing that some ThinkPad the FSF rubber-stamped respects your freedom (and security) when it contains microcontrollers hooked up to LPC running secret blobs. Yes, if we want to go deeper down the rabbit hole of hardware trustability, there is definitely more to be done after Precursor, but it's a particularly clever example of how to at least attempt to begin to solve the silicon trust problem.
> With design randomization, you can make it hard to detect patterns like that. Think things like randomizing the polarity of each bit line going in/out of RAM. Again, the point is the backdoor has to work with any design, and this opens up a wide range of mitigations that you can implement at that stage, that make it a lot less practical.
This doesn't really work-- assume the adversary has your design. Then they can appropriately figure out how to get the right bits across some part of it that matters.
This doesn't really work-- assume the adversary has your design. Then they can appropriately figure out how to get the right bits across some part of it that matters.
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.
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.
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.
You can still backdoor a FPGA in the style of Reflections on Trusting Trust... wait for known code to be installed into the FPGA and then patch it.
"Known" is the key word. You can randomize an FPGA design's layout and synthesis details, and it is impractical to implement dynamic reverse engineering of the design in order to patch it (certainly in an undetectable way - that's more compute power you'd need than was available to begin with). That's the premise behind Precursor, that users can run their own randomized bitstream, not a shared build.
[deleted]
[deleted]
> how big of a project would it be to create a fully libre (whatever you want to call you it) laptop?
But what does it mean by "Libre"? You see, the entire disagreement is about a problem of our definition: How does one define "a hardware system without non-proprietary software"?
Ideally, if every single chip in a computer has free hardware design down to the logic gate or HDL level, that would certainly qualify as 100% libre in both hardware and software (if a free operation system is also used). But obviously it's not practical, and it's also out of scope of what the FSF does, it's the Free Software Foundation, and it only cares about software, not hardware. Thus, the FSF defines "Respect Your Freedom" as a hardware system that doesn't require you to execute any nonfree software to use.
This sounds like a straightforward definition, right? But for many different types of hardware - essentially 90% of all digital electronics - if you open it up, decap the chips, you'll find a general-purpose microprocessor core executing code in a hard-wired Mask ROM. The chip can be a CPU with embedded microcode, a serial port transceiver, a USB controller, or even a Voltage Regulator Module (just search "DigiVRM"). Sometimes you don't even know it's implemented in this way. Thus, a practical boundary between hardware and software must be drawn.
The FSF's argument is basically the following: Consider a blackbox hardware system, such as a chip. Inside the chip, you may find a bunch of logic gates, hardwired to be a finite state machine, or you may find a read-only Mask ROM driving the microprocessor. But it's irrelevant: from the perspective of the software user outside the chip, it doesn't make any difference, it's just an implementation detail in the hardware realm that matters to a hardware engineer, not a software developer. Externally they can even be indistinguishable, if not at the electrical level, at least at the software level. Thus, as long as the logic is not controllable by software, it's not considered as a form of "non-free software" and it gets "Respect Your Freedom" approval. I think there's little to no disagreement at this point, but it gets controversial next.
Now, consider two chips, one is a controller and another is its ROM. The FSF argues that, if the ROM is not reprogramable via software even by its vendor after it leaves the factory (if the ROM is 100% read-only, or if the Write function is permanently disabled at hardware level), the controller and its own ROM are collectively considered equivalent to some hard-wired electronic circuitry in the pure hardware realm, using the same argument. Thus it also gets "Respect Your Freedom" approval.
However, if the ROM can be reprogrammed (e.g. has an enabled "Write" function) or controlled by software (e.g. uploading a blob by the device driver to the chip), it's considered as a form of non-free software, thus the FSF say it "Does Not Respect Your Freedom".
And this is where the disagreement starts.
The FSF may insist that a software-controlled firmware is strictly a type of computer program, thus it must be non-free software, meanwhile firmware not controlled by software may as well be a collection of hard-wired logic gates, so it's a "don't care" item for a software user - or at least a form of compromise. The counterargument is that, regardless of whether the firmware control is enabled or disabled, you're ultimately running the same non-free software in both cases (even though, the first case is invisible to software and the second case is visible to software), and it's just a matter of location, either ROM or disk. Since running fixed non-free software is better than running vulnerable non-free software, the "Respect Your Freedom" hardware's "quasi hard-wired" firmware is a waste of time and provides less user freedom.
I only described the disagreements, it's up to you to decide. Now, I'm curious to know what would be your definition of "Libre", after learning what I've told you?
But what does it mean by "Libre"? You see, the entire disagreement is about a problem of our definition: How does one define "a hardware system without non-proprietary software"?
Ideally, if every single chip in a computer has free hardware design down to the logic gate or HDL level, that would certainly qualify as 100% libre in both hardware and software (if a free operation system is also used). But obviously it's not practical, and it's also out of scope of what the FSF does, it's the Free Software Foundation, and it only cares about software, not hardware. Thus, the FSF defines "Respect Your Freedom" as a hardware system that doesn't require you to execute any nonfree software to use.
This sounds like a straightforward definition, right? But for many different types of hardware - essentially 90% of all digital electronics - if you open it up, decap the chips, you'll find a general-purpose microprocessor core executing code in a hard-wired Mask ROM. The chip can be a CPU with embedded microcode, a serial port transceiver, a USB controller, or even a Voltage Regulator Module (just search "DigiVRM"). Sometimes you don't even know it's implemented in this way. Thus, a practical boundary between hardware and software must be drawn.
The FSF's argument is basically the following: Consider a blackbox hardware system, such as a chip. Inside the chip, you may find a bunch of logic gates, hardwired to be a finite state machine, or you may find a read-only Mask ROM driving the microprocessor. But it's irrelevant: from the perspective of the software user outside the chip, it doesn't make any difference, it's just an implementation detail in the hardware realm that matters to a hardware engineer, not a software developer. Externally they can even be indistinguishable, if not at the electrical level, at least at the software level. Thus, as long as the logic is not controllable by software, it's not considered as a form of "non-free software" and it gets "Respect Your Freedom" approval. I think there's little to no disagreement at this point, but it gets controversial next.
Now, consider two chips, one is a controller and another is its ROM. The FSF argues that, if the ROM is not reprogramable via software even by its vendor after it leaves the factory (if the ROM is 100% read-only, or if the Write function is permanently disabled at hardware level), the controller and its own ROM are collectively considered equivalent to some hard-wired electronic circuitry in the pure hardware realm, using the same argument. Thus it also gets "Respect Your Freedom" approval.
However, if the ROM can be reprogrammed (e.g. has an enabled "Write" function) or controlled by software (e.g. uploading a blob by the device driver to the chip), it's considered as a form of non-free software, thus the FSF say it "Does Not Respect Your Freedom".
And this is where the disagreement starts.
The FSF may insist that a software-controlled firmware is strictly a type of computer program, thus it must be non-free software, meanwhile firmware not controlled by software may as well be a collection of hard-wired logic gates, so it's a "don't care" item for a software user - or at least a form of compromise. The counterargument is that, regardless of whether the firmware control is enabled or disabled, you're ultimately running the same non-free software in both cases (even though, the first case is invisible to software and the second case is visible to software), and it's just a matter of location, either ROM or disk. Since running fixed non-free software is better than running vulnerable non-free software, the "Respect Your Freedom" hardware's "quasi hard-wired" firmware is a waste of time and provides less user freedom.
I only described the disagreements, it's up to you to decide. Now, I'm curious to know what would be your definition of "Libre", after learning what I've told you?
You would make an EXCELLENT moderator or facilitator. You gave fair shrift and explanation to the various perspectives anc concerns this thread is full of. I will happily vote for you if you ever run for public office.
I'm not arguing with your overall comment, because I think it's a decent summary of the FSF's position. But a few nitpicks with their position:
> The FSF's argument is basically the following: Consider a blackbox hardware system, such as a chip. Inside the chip, you may find a bunch of logic gates, hardwired to be a finite state machine, or you may find a read-only Mask ROM driving the microprocessor. But it's irrelevant: from the perspective of the software user outside the chip, it doesn't make any difference, it's just an implementation detail in the hardware realm that matters to a hardware engineer, not a software developer.
This contains an assumption about the behavior complexity of the black box chip. A digital SMPS controller could also be replaced by an appropriate discrete analog signal conditioning and an appropriate beefing up of the power electronics. Instead it uses some advanced digital processing (assorted operating modes based on current draw, etc), which is why the manufacturer chose to use a general purpose CPU programmed with software. As soon as something rises to the level of using software, I would say the FSF has "jurisdiction" - the complexity of software is being deployed without a way for the end-user to grok that complexity. It's only historic pragmatism for why the FSF gave it a pass.
> if the ROM is 100% read-only, or if the Write function is permanently disabled at hardware level
Except that for the most part true mask "ROM" isn't a thing except for tiny bootloaders, and we're mostly talking FLASH which remains writable. Tying !write_enable high and calling that a "ROM" is more rules lawyering than an appropriate description of the actual situation. Especially when the developer of the proprietary blob expects to release updates (ie has released unfinished software), and this one device's implementation is unusual to prohibit such updates.
> I'm curious to know what would be your definition of "Libre"
Due to "software eating the world", close to nothing these days is actually "Libre". I think it needs to be a scale, for things that afford you more or less freedom. Furthermore it needs to take into account anti-Freedom developments such as signature lockdowns and the upgrade treadmill. Furthermore a complex device needs multiple numbers to take into account where the code is running - on the main CPU domain versus an isolated subprocessor.
For example my desktop is a librebooted KGPE with an AMD video card. The AMD video card is locked down hard and itself is very poor for software freedom, but the overall device is excellent for software freedom because the main CPU domain is completely Libre. So ideally it would have a combined score saying "this is one of the best Libre options you have right now", combined with another metric on the same scale describing the peripherals. If you wanted an actual Libre video card, then you'd need some newly designed thing which also endeavored to be open, not just a video card from one of the big three full of proprietary software, in assorted stages of being reverse engineered.
FWIW on such a scale I would make higher numbers more Free, as we obviously have a lot of headroom with regards to embedded/hardware freedom, and manufacturer community engagement.
> The FSF's argument is basically the following: Consider a blackbox hardware system, such as a chip. Inside the chip, you may find a bunch of logic gates, hardwired to be a finite state machine, or you may find a read-only Mask ROM driving the microprocessor. But it's irrelevant: from the perspective of the software user outside the chip, it doesn't make any difference, it's just an implementation detail in the hardware realm that matters to a hardware engineer, not a software developer.
This contains an assumption about the behavior complexity of the black box chip. A digital SMPS controller could also be replaced by an appropriate discrete analog signal conditioning and an appropriate beefing up of the power electronics. Instead it uses some advanced digital processing (assorted operating modes based on current draw, etc), which is why the manufacturer chose to use a general purpose CPU programmed with software. As soon as something rises to the level of using software, I would say the FSF has "jurisdiction" - the complexity of software is being deployed without a way for the end-user to grok that complexity. It's only historic pragmatism for why the FSF gave it a pass.
> if the ROM is 100% read-only, or if the Write function is permanently disabled at hardware level
Except that for the most part true mask "ROM" isn't a thing except for tiny bootloaders, and we're mostly talking FLASH which remains writable. Tying !write_enable high and calling that a "ROM" is more rules lawyering than an appropriate description of the actual situation. Especially when the developer of the proprietary blob expects to release updates (ie has released unfinished software), and this one device's implementation is unusual to prohibit such updates.
> I'm curious to know what would be your definition of "Libre"
Due to "software eating the world", close to nothing these days is actually "Libre". I think it needs to be a scale, for things that afford you more or less freedom. Furthermore it needs to take into account anti-Freedom developments such as signature lockdowns and the upgrade treadmill. Furthermore a complex device needs multiple numbers to take into account where the code is running - on the main CPU domain versus an isolated subprocessor.
For example my desktop is a librebooted KGPE with an AMD video card. The AMD video card is locked down hard and itself is very poor for software freedom, but the overall device is excellent for software freedom because the main CPU domain is completely Libre. So ideally it would have a combined score saying "this is one of the best Libre options you have right now", combined with another metric on the same scale describing the peripherals. If you wanted an actual Libre video card, then you'd need some newly designed thing which also endeavored to be open, not just a video card from one of the big three full of proprietary software, in assorted stages of being reverse engineered.
FWIW on such a scale I would make higher numbers more Free, as we obviously have a lot of headroom with regards to embedded/hardware freedom, and manufacturer community engagement.
Thanks for the comment. I think your comment still has some unresolved problems on drawing the hardware and software boundary. Before I start, I have to say the same thing: I'm not arguing with your overall comment, I think it's an interesting argument. But some details need improvements.
Using the same SMPS controller chip as an example. It can be either an analog system, a digital finite state machine, or be driven by a microprocessor core with firmware. Since it's only an internal implementation detail in the silicon, in my original comment, I said that the FSF's opinion is to classify this chip as "hardware" and to ignore its existence.
You said this is undesirable, because software is still software, and for an organization that promotes free software, embedded firmware buried deep inside silicon should not be willfully ignored but seriously considered - as soon as it "rises to the level of using software" - especially when it's a piece of highly complex and sophisticated control system that we use every day but know very little on its internal workings. The same argument also applies to all types of firmware in controllers. Let me call it the Deep Firmware Argument, and to me it's very understandable.
And what you're proposing is that, instead of giving systems a Boolean pass or fail software freedom rating with edge cases and undesirable "rules lawyering", one should rate software freedom in a continuous spectrum: no system is fully free, only more free or less free. This is much more useful because the impacts of all non-free components are considered and reflected in a weighted score.
So far so good, I must say it's an interesting opinion.
But still, how do you define a piece of hardware that "rises to the level of using software"? In particular:
1. You argue that, in most controllers, true Mask ROM and One Time Programmable ROM are rarely used in today's systems. In fact, many are meant to be updated by the vendor. Thus, even if you make a motherboard and tying !write_enable HIGH in your own system, it's only a special case and doesn't change the big picture that the vendor is shipping non-free software to everybody. Thus, it is a strong argument for considering it as (non-free) software. Let me call it the Firmware Update Argument.
My question is, how would you apply this argument back to the SMPS controller chip example? To my best knowledge, most monolithic SMPS controllers are truly One Time Programmable, once the firmware is finished, it's set in stone, considered finished, and is only changed in a silicon update. Thus, I may as well push the Firmware Update Argument to the opposite conclusion - these systems are hardware, not software.
Thus, in this case, Deep Firmware Argument says yes, but Firmware Update Argument says no. How do you reconcile them? Are you suggesting that the firmware buried deep inside the silicon can be ignored, or at least is less important to care?
2. In your later example, you said a PC with proprietary GPU is still free enough, because "the main CPU domain is completely Libre." But is the main CPU domain really completely Libre?
The internal operation of an x86_64 CPU is controlled by a microsequencer running its own microcode. Furthermore, the microcode even supports runtime update. Using the Deep Firmware Argument, I argue that the CPU itself has already "rises to the level of using software", and using the Firmware Update Argument, it further strengthens this argument. Thus, the CPU is not completely Libre but you said it's Libre.
Yet when you were talking about a graphics card, you said because these graphics cards contain proprietary microcode or firmware, "you'd need some newly designed thing which also endeavored to be open, not just a video card from one of the big three full of proprietary software".
Therefore, I think you're contradicting with yourself in this example.
3. Where does the Deep Firmware Argument end?
If a digital power controller powered by a microprocessor core and a Mask ROM counts as software, a CPU powered by a microsequencer running its own microcode also counts as software, and "it's turtles all the way down" and we apply the argument repeatedly. Ultimately we come to the conclusion that even simple combinational logic formed by a bunch of AND and OR gates would be considered as software in some cases, which is an undesirable conclusion.
If you decap the chip and look at the die of a MOS 6502 from 1975, you see a large matrix in a rectangular shape. This is basically a large decoder ROM, responsible for generating all the control signals internal to the CPU. This is usually considered as pure hardware, because although it works as a ROM but it's not meant to be a general-purpose circuitry. Rather, it's hard-wired to output some prearranged signals already determined by the designers. Indeed, microcode-like CPU designs appeared very early in computer history long before software took over the world.
Then, consider a hypothetical MOS 6502 CPU in 2020. Inside the chip you'll find circuitry that resembles an off-the-shelf FPGA. Before this chip leaves the factory, a FPGA burner writes the bitstream data of a 6502 emulator into a ROM via a test point on the chip. The bitstream cannot be further changed after the fact.
Clearly, chip #1 is not using software, at least if the Deep Firmware Argument is not pushed to its extreme. Meanwhile, chip #2 is obviously using software according to your argument (although the FSF would choose to ignore it), because the 6502 emulator is clearly the work of a programmer.
Finally, consider another hypothetical MOS 6502 CPU. This time, the only difference is that we use a general-purpose PROM block in place of the hard-wired decoder ROM in the original 6502. Before this chip leaves the factory, a PROM burner writes the decoder ROM data into the PROM via a test point on the chip. The PROM cannot be further changed after the fact.
Now, does this CPU contain software? Perhaps not. Chip #1 and Chip #3 is essentially the same hardware, the only difference is a physical implementation detail. However, one can also argue it contains software because both Chip #2 and Chip #3 have programmed microcode, the only difference is how much.
4. If I were you, I think there is a simple solution to simultaneously fix all the problems in your argument. Just like how free and non-free can be rated on a continuous spectrum, whether something is more hardware-like or software-like can be rated on a continuous spectrum as well. A random logic controller can get a hardware score of 1.0, a hard-wired ROM controller can be 0.9, a OTP ROM controller can be 0.8, and finally a FPGA controller can be 0.2. The degree of "Libreness" can be calculated by taking both into considerations.
However, it introduces huge complexity to the evaluation process and I think it often requires access to the underlying chip design and thus impractical. Which lead us back to the original question: how do you define a piece of hardware that "rises to the level of using software"?
Using the same SMPS controller chip as an example. It can be either an analog system, a digital finite state machine, or be driven by a microprocessor core with firmware. Since it's only an internal implementation detail in the silicon, in my original comment, I said that the FSF's opinion is to classify this chip as "hardware" and to ignore its existence.
You said this is undesirable, because software is still software, and for an organization that promotes free software, embedded firmware buried deep inside silicon should not be willfully ignored but seriously considered - as soon as it "rises to the level of using software" - especially when it's a piece of highly complex and sophisticated control system that we use every day but know very little on its internal workings. The same argument also applies to all types of firmware in controllers. Let me call it the Deep Firmware Argument, and to me it's very understandable.
And what you're proposing is that, instead of giving systems a Boolean pass or fail software freedom rating with edge cases and undesirable "rules lawyering", one should rate software freedom in a continuous spectrum: no system is fully free, only more free or less free. This is much more useful because the impacts of all non-free components are considered and reflected in a weighted score.
So far so good, I must say it's an interesting opinion.
But still, how do you define a piece of hardware that "rises to the level of using software"? In particular:
1. You argue that, in most controllers, true Mask ROM and One Time Programmable ROM are rarely used in today's systems. In fact, many are meant to be updated by the vendor. Thus, even if you make a motherboard and tying !write_enable HIGH in your own system, it's only a special case and doesn't change the big picture that the vendor is shipping non-free software to everybody. Thus, it is a strong argument for considering it as (non-free) software. Let me call it the Firmware Update Argument.
My question is, how would you apply this argument back to the SMPS controller chip example? To my best knowledge, most monolithic SMPS controllers are truly One Time Programmable, once the firmware is finished, it's set in stone, considered finished, and is only changed in a silicon update. Thus, I may as well push the Firmware Update Argument to the opposite conclusion - these systems are hardware, not software.
Thus, in this case, Deep Firmware Argument says yes, but Firmware Update Argument says no. How do you reconcile them? Are you suggesting that the firmware buried deep inside the silicon can be ignored, or at least is less important to care?
2. In your later example, you said a PC with proprietary GPU is still free enough, because "the main CPU domain is completely Libre." But is the main CPU domain really completely Libre?
The internal operation of an x86_64 CPU is controlled by a microsequencer running its own microcode. Furthermore, the microcode even supports runtime update. Using the Deep Firmware Argument, I argue that the CPU itself has already "rises to the level of using software", and using the Firmware Update Argument, it further strengthens this argument. Thus, the CPU is not completely Libre but you said it's Libre.
Yet when you were talking about a graphics card, you said because these graphics cards contain proprietary microcode or firmware, "you'd need some newly designed thing which also endeavored to be open, not just a video card from one of the big three full of proprietary software".
Therefore, I think you're contradicting with yourself in this example.
3. Where does the Deep Firmware Argument end?
If a digital power controller powered by a microprocessor core and a Mask ROM counts as software, a CPU powered by a microsequencer running its own microcode also counts as software, and "it's turtles all the way down" and we apply the argument repeatedly. Ultimately we come to the conclusion that even simple combinational logic formed by a bunch of AND and OR gates would be considered as software in some cases, which is an undesirable conclusion.
If you decap the chip and look at the die of a MOS 6502 from 1975, you see a large matrix in a rectangular shape. This is basically a large decoder ROM, responsible for generating all the control signals internal to the CPU. This is usually considered as pure hardware, because although it works as a ROM but it's not meant to be a general-purpose circuitry. Rather, it's hard-wired to output some prearranged signals already determined by the designers. Indeed, microcode-like CPU designs appeared very early in computer history long before software took over the world.
Then, consider a hypothetical MOS 6502 CPU in 2020. Inside the chip you'll find circuitry that resembles an off-the-shelf FPGA. Before this chip leaves the factory, a FPGA burner writes the bitstream data of a 6502 emulator into a ROM via a test point on the chip. The bitstream cannot be further changed after the fact.
Clearly, chip #1 is not using software, at least if the Deep Firmware Argument is not pushed to its extreme. Meanwhile, chip #2 is obviously using software according to your argument (although the FSF would choose to ignore it), because the 6502 emulator is clearly the work of a programmer.
Finally, consider another hypothetical MOS 6502 CPU. This time, the only difference is that we use a general-purpose PROM block in place of the hard-wired decoder ROM in the original 6502. Before this chip leaves the factory, a PROM burner writes the decoder ROM data into the PROM via a test point on the chip. The PROM cannot be further changed after the fact.
Now, does this CPU contain software? Perhaps not. Chip #1 and Chip #3 is essentially the same hardware, the only difference is a physical implementation detail. However, one can also argue it contains software because both Chip #2 and Chip #3 have programmed microcode, the only difference is how much.
4. If I were you, I think there is a simple solution to simultaneously fix all the problems in your argument. Just like how free and non-free can be rated on a continuous spectrum, whether something is more hardware-like or software-like can be rated on a continuous spectrum as well. A random logic controller can get a hardware score of 1.0, a hard-wired ROM controller can be 0.9, a OTP ROM controller can be 0.8, and finally a FPGA controller can be 0.2. The degree of "Libreness" can be calculated by taking both into considerations.
However, it introduces huge complexity to the evaluation process and I think it often requires access to the underlying chip design and thus impractical. Which lead us back to the original question: how do you define a piece of hardware that "rises to the level of using software"?
I'm not drawing a hardware/software boundary, but rather rejecting the hard dichotomy. The "deep firmware" argument is pointing out that calling something hardware or a "black box" is itself a convenient abstraction rather than some hard and fast rule. I would say that it doesn't "end" anywhere - end user understanding and modification is an asymptote to strive for. That also includes understanding and modifying hardware.
The FSF had to pick a boundary for their view of the problem (and hardware used to be much more open back then), but now that boundary is being rules lawyered it's important to point out that it is still an arbitrary boundary.
I also reject designating some hard "Libre" line, where we would say a device is either full "free" or "not free". Freedom in the wider world is not a binary property, and so we wouldn't expect software to be. That was the point of designating less free things with a lower number - so that as the norms and expectations of freedom advance, higher numbers can be allocated. For example, imagine a device that comes documented with a schematic. A schematic doesn't fall under the definition of "software freedom", and yet is quite handy to have if you're modifying the device's software!
In fact continuing this line of thought, I think a large part of the original topic's critique (which I share) is due to the FSF taking their hard line of "free and "non-free" software (which is a hard distinction because every software has a license), and attempting to transplant it to analyze devices.
The libreboot / AMD video card example was is to describe a different issue - the orthogonality of the freedom of a device's main domain versus its peripherals. In order to make use of a Libre device, we have to compromise on freedom of its surrounding peripherals. To support my Libreboot desktop, there are countless non-free blobs that I write off as "non-updateable", if I'm even aware of them.
If I do focus on any one of these devices specifically (say a USB hub, network card, or a video card), then it makes sense to talk about its own software freedom (cutting through this current "hardware" terminus). But its own Libre status doesn't reflect on the main domain, regardless of how it gets its firmware. If it runs a proprietary blob that gets loaded by the main CPU domain, then the main domain's freedom is only affected if the process of loading that blob is also a blob. If the loading is done by Free software, then the main CPU domain is still fully Libre. And so if we're talking about an integrated device, which is any device, then it makes sense to split out freedom scores into different categories of the main processor plus support systems.
And yes, I have completely ignored the microcode in my processor for that example. In fact, I personally even go against the FSF and install the updated microcode, because I don't see much philosophical difference to trusting AMD of when they manufactured my processors, or trusting AMD of when the virtualization-fixing microcode was released.
IMO the Freedom compromise isn't merely updating the microcode, but rather using a microprocessor with changeable microcode and other undocumented locked-down internals in the first place. But for a performant desktop, I believe this is one of the best solutions right now. This is also why I want to leave room at the top of the freedom scale, so that better solutions can get recognized for Freedom improvements, whether they are yet to be developed or currently existing solutions that trade off performance (eg some of the RISC-V/FPGA ideas).
The FSF had to pick a boundary for their view of the problem (and hardware used to be much more open back then), but now that boundary is being rules lawyered it's important to point out that it is still an arbitrary boundary.
I also reject designating some hard "Libre" line, where we would say a device is either full "free" or "not free". Freedom in the wider world is not a binary property, and so we wouldn't expect software to be. That was the point of designating less free things with a lower number - so that as the norms and expectations of freedom advance, higher numbers can be allocated. For example, imagine a device that comes documented with a schematic. A schematic doesn't fall under the definition of "software freedom", and yet is quite handy to have if you're modifying the device's software!
In fact continuing this line of thought, I think a large part of the original topic's critique (which I share) is due to the FSF taking their hard line of "free and "non-free" software (which is a hard distinction because every software has a license), and attempting to transplant it to analyze devices.
The libreboot / AMD video card example was is to describe a different issue - the orthogonality of the freedom of a device's main domain versus its peripherals. In order to make use of a Libre device, we have to compromise on freedom of its surrounding peripherals. To support my Libreboot desktop, there are countless non-free blobs that I write off as "non-updateable", if I'm even aware of them.
If I do focus on any one of these devices specifically (say a USB hub, network card, or a video card), then it makes sense to talk about its own software freedom (cutting through this current "hardware" terminus). But its own Libre status doesn't reflect on the main domain, regardless of how it gets its firmware. If it runs a proprietary blob that gets loaded by the main CPU domain, then the main domain's freedom is only affected if the process of loading that blob is also a blob. If the loading is done by Free software, then the main CPU domain is still fully Libre. And so if we're talking about an integrated device, which is any device, then it makes sense to split out freedom scores into different categories of the main processor plus support systems.
And yes, I have completely ignored the microcode in my processor for that example. In fact, I personally even go against the FSF and install the updated microcode, because I don't see much philosophical difference to trusting AMD of when they manufactured my processors, or trusting AMD of when the virtualization-fixing microcode was released.
IMO the Freedom compromise isn't merely updating the microcode, but rather using a microprocessor with changeable microcode and other undocumented locked-down internals in the first place. But for a performant desktop, I believe this is one of the best solutions right now. This is also why I want to leave room at the top of the freedom scale, so that better solutions can get recognized for Freedom improvements, whether they are yet to be developed or currently existing solutions that trade off performance (eg some of the RISC-V/FPGA ideas).
I questioned myself about it many times. AFAIK, the rockpi4 without WiFi is ryf-certifiable. DisplayPort may need blobs, but USB-C is used only for power.It has blob free FLOSS drivers for the GPU and VPU. Its arm trusted firmware is fully open source.
So, yes it is possible to have a modern and affordable ryf-certified system.
So, yes it is possible to have a modern and affordable ryf-certified system.
I expect the USB-C chip has proprietary software running on it, since USB-C chargers have more computing power than the Apollo 11 Guidance Computer:
https://forrestheller.com/Apollo-11-Computer-vs-USB-C-charge...
https://forrestheller.com/Apollo-11-Computer-vs-USB-C-charge...
Fully ROM, secondary processor. Ryf-certifiable.
Software in ROM is worse, since you can't pull vendor updates to fix any security bugs and you can't reverse engineer it, produce free firmware and replace the proprietary firmware.
And then we fall on the whole subject we're discussing here. In this particular case, a "power controller chip" I can even consider a fix or a change that improves efficiency... Nevertheless, I doubt most devices allow the update of a firmware for such a thing, in the end, it wouldn't make much of a difference.
If the firmware is open source, sign me in! No opposition! Neither from me nor from the FSF. FSF would not oppose libre firmware.
If it is not open source... well, then this is discussed in the other comments.
If the firmware is open source, sign me in! No opposition! Neither from me nor from the FSF. FSF would not oppose libre firmware.
If it is not open source... well, then this is discussed in the other comments.
> 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?
Very big, and unfeasible?
I think, to start with, the goal can't be "a laptop". It'll be obsolete in an instant, likely even long before hitting the market. IMHO the goal should be building up a ecosystem of companies producing libre components (from which one hopefully eventually would be able to source everything needed for a laptop). There is some movement in this direction (e.g. OSHWA, FOSSi, Skywater PDK), but you know, starting from the bottom so currently mostly microcontroller level stuff. Long way from a laptop still.
> China
A regime hellbent on surveilling everything their citizens do suddenly caring about the personal freedoms Stallman worries about?
I'm quite sure that whatever China is doing to rein in the surveillance capitalists it's not because of their threat to personal freedom but rather because they have become powerful enough to pose a threat to the party.
> And then proceed to go into every industry with right to repair issues. Deere tractor competitors, home appliances, and so on. In the name of component longevity and repairability. All of this to repudiate forced obsolescence and to promote end user freedoms.
I have great hopes for the right to repair movement. They might eventually achieve something big. As opposed to RYF, which is problematic as the article and this discussion points out, and is destined to be nothing but an extremely niche thing only a few fanatics will ever care about.
Very big, and unfeasible?
I think, to start with, the goal can't be "a laptop". It'll be obsolete in an instant, likely even long before hitting the market. IMHO the goal should be building up a ecosystem of companies producing libre components (from which one hopefully eventually would be able to source everything needed for a laptop). There is some movement in this direction (e.g. OSHWA, FOSSi, Skywater PDK), but you know, starting from the bottom so currently mostly microcontroller level stuff. Long way from a laptop still.
> China
A regime hellbent on surveilling everything their citizens do suddenly caring about the personal freedoms Stallman worries about?
I'm quite sure that whatever China is doing to rein in the surveillance capitalists it's not because of their threat to personal freedom but rather because they have become powerful enough to pose a threat to the party.
> And then proceed to go into every industry with right to repair issues. Deere tractor competitors, home appliances, and so on. In the name of component longevity and repairability. All of this to repudiate forced obsolescence and to promote end user freedoms.
I have great hopes for the right to repair movement. They might eventually achieve something big. As opposed to RYF, which is problematic as the article and this discussion points out, and is destined to be nothing but an extremely niche thing only a few fanatics will ever care about.
[deleted]
Very few people or organizations willingly give up control. The whole reason of using copyright law to "enforce" freedom by preventing free software from becoming unfree was because of how much the current legal framework around imaginary property is stacked against a libre approach. So, it's a tough game to play, but FSF didn't achieve what it has thus far by being soft or compromising. Substantial change with hostile parties doesn't happen by constantly yielding.
Since hardware vendors by and large ignore RYF certification and the FSF’s opinions in general, it’s hardly “yielding” for the FSF to change its policies if the existing policies are harmful to the free software community.
The people who are most vocal about FSF’s incorrect views on firmware are those who themselves are bringing free operating systems to new hardware, writing drivers, and reverse engineering hardware and firmware. They are not hostile parties—their contributions are among the most important to free software today, and their opinions should hold more weight.
The people who are most vocal about FSF’s incorrect views on firmware are those who themselves are bringing free operating systems to new hardware, writing drivers, and reverse engineering hardware and firmware. They are not hostile parties—their contributions are among the most important to free software today, and their opinions should hold more weight.
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 the cause."
Harm isn't very present on the FSF priority list.
"They should die for the cause."
Harm isn't very present on the FSF priority list.
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 say we should save someone’s life because of the proprietary nature of the software, but that’s not really the point — the point is to strive for a world in which life-saving software isn’t proprietary in the first place. When one is arguing for absolute ideals, one tends to speak in absolutes and ignore historical circumstance since that’s sort of the point (though of course it’s also very silly in its own way). There’s a difference between advocating for a principle/ideal and solving concrete problems in a world that doesn’t yet meet that ideal.
If we were to constantly let proprietary software stick around because it served some crucial function and never put in the work to replace such software with non-proprietary alternatives, we’d never realize a world without proprietary software—so you can see how someone purportedly striving for that ideal really can’t capitulate.
RMS is arguing for principles and ideals. Sure when it comes down to it, it’s absurd to say we should save someone’s life because of the proprietary nature of the software, but that’s not really the point — the point is to strive for a world in which life-saving software isn’t proprietary in the first place. When one is arguing for absolute ideals, one tends to speak in absolutes and ignore historical circumstance since that’s sort of the point (though of course it’s also very silly in its own way). There’s a difference between advocating for a principle/ideal and solving concrete problems in a world that doesn’t yet meet that ideal.
If we were to constantly let proprietary software stick around because it served some crucial function and never put in the work to replace such software with non-proprietary alternatives, we’d never realize a world without proprietary software—so you can see how someone purportedly striving for that ideal really can’t capitulate.
You don't get what they're saying at all. There are about a thousand better ways he could have responded while still trying to convey his ideas. Instead, he said probably the single most offensive thing he could. He either did it on purpose to piss them off, or he didn't understand how offensive it would be, or he didn't care.
He has no idea how to be persuasive, no idea how to adjust his arguments or present his ideas effectively, no idea how he comes off to others, no idea how to read a room, no idea how to see other people's perspectives on issues, and doesn't care to try. He hasn't demonstrated the slightest intellectual or emotional self-improvement in thirty years.
He has no idea how to be persuasive, no idea how to adjust his arguments or present his ideas effectively, no idea how he comes off to others, no idea how to read a room, no idea how to see other people's perspectives on issues, and doesn't care to try. He hasn't demonstrated the slightest intellectual or emotional self-improvement in thirty years.
I disagree. The Buddha was the same way in his direct speech because the clarity of a message that would live on and instruct the lives of others thousands of years later was more important than appeasement at clarity's cost:
“Nanda, I do not praise the conception of a life even a little bit. I do not praise the conception of a [new] life for even one moment. Why is that? The conception of life is suffering. In the same way that even a little vomit stinks, Nanda, even the momentary conception of a tiny life is suffering. Nanda, a being for whom there is the arising of material form, establishment [in the womb], development, emergence [from the womb], sensation, intellect, volitions, consciousness, indeed, any being at all that is established, develops, and emerges, is miserable. Abiding [in the womb] is sickness. Emerging [from the womb] is old age and death. Nanda, for this reason, what profit is there for the one lodged in the womb, craving life so deeply?”
Nobody decided for Nvidia to make proprietary drivers for their graphics cards, neither is the customer blameless: Nvidia got its start making gaming graphics card long before it muscled into machine learning. Those gamers funded its purses and every time they did empowered the machine to continue its filthy work.
"But I need to play these games or I'll die," they cry. Well now they've got the data scientists over a barrel and it won't ever stop unless we start saying no.
“Nanda, I do not praise the conception of a life even a little bit. I do not praise the conception of a [new] life for even one moment. Why is that? The conception of life is suffering. In the same way that even a little vomit stinks, Nanda, even the momentary conception of a tiny life is suffering. Nanda, a being for whom there is the arising of material form, establishment [in the womb], development, emergence [from the womb], sensation, intellect, volitions, consciousness, indeed, any being at all that is established, develops, and emerges, is miserable. Abiding [in the womb] is sickness. Emerging [from the womb] is old age and death. Nanda, for this reason, what profit is there for the one lodged in the womb, craving life so deeply?”
Nobody decided for Nvidia to make proprietary drivers for their graphics cards, neither is the customer blameless: Nvidia got its start making gaming graphics card long before it muscled into machine learning. Those gamers funded its purses and every time they did empowered the machine to continue its filthy work.
"But I need to play these games or I'll die," they cry. Well now they've got the data scientists over a barrel and it won't ever stop unless we start saying no.
But it is just hypocrisy to no end. I’m fairly sure RMS do use a car/flied to the given university, etc. All of those use proprietary software.
Honestly, the whole question and set up seems like complete fiction.
What computer scientist is working on life saving image processing on medical imaging equipment where everything is open source except for some proprietary drivers. These kind of equipment are leased, not even owned.
If the so called "lecturers" were actually physicians they wouldn't care about software licensing as the hardware itself is dramatically expensive. And the entire thing is proprietary. And why would the lecturers get "increasingly irritated". Its not like RMS is actually preventing them from using equipment. He is just giving a talk. Folks typically ask one question and sit down. Or meet privately later.
I simply can't come up with any conceivable scenario where saving someone's life us critically dependent on some proprietary graphics driver. Its downright hilarious.
What medical equipment is using a 60 layer deep NN to save lives?! These images are scanned manually by qualified physicians. And the OP claims this happened 8 years ago! You dont actually need a graphics driver to analyze image files. CPUs are good enough. Graphics drivers were not even widely used for Deep NN inference 8 years ago.
I asked the OP for details about this "talk" and ge hasn't responded.
This is a cock n bull story OP constructed because he knows linux is forced to use nvidia blobs for its graphics driver. Completely insane story, however.
This tale is taller than Mt Everest.
What computer scientist is working on life saving image processing on medical imaging equipment where everything is open source except for some proprietary drivers. These kind of equipment are leased, not even owned.
If the so called "lecturers" were actually physicians they wouldn't care about software licensing as the hardware itself is dramatically expensive. And the entire thing is proprietary. And why would the lecturers get "increasingly irritated". Its not like RMS is actually preventing them from using equipment. He is just giving a talk. Folks typically ask one question and sit down. Or meet privately later.
I simply can't come up with any conceivable scenario where saving someone's life us critically dependent on some proprietary graphics driver. Its downright hilarious.
What medical equipment is using a 60 layer deep NN to save lives?! These images are scanned manually by qualified physicians. And the OP claims this happened 8 years ago! You dont actually need a graphics driver to analyze image files. CPUs are good enough. Graphics drivers were not even widely used for Deep NN inference 8 years ago.
I asked the OP for details about this "talk" and ge hasn't responded.
This is a cock n bull story OP constructed because he knows linux is forced to use nvidia blobs for its graphics driver. Completely insane story, however.
This tale is taller than Mt Everest.
Did he really say those specific words? It's common, on the internet, to use quotation marks to signify "here's what I think someone else is saying, it's not my own belief". (That is also an example of such a usage.)
I don’t necessarily question this exact usage, given we are talking about RMS.
He said those exact words and despite the responses I wasn't trying to remark on his words, only pass along a small moment many of us there found memorable and funny.
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.
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 powers and makes everyone believe it is useful and harmless to the free software ecosystem.
Let's break down this amazing license:
> 9. Acceptance Not Required for Having Copies. > > You are not required to accept this License in order to receive or run a copy of the Program.
So it's not an EULA. Cool. You can freely run the program as long as you don't modify it. Freedom Zero.
> Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.
But if you touch the code, you'd better comply with the License. Great. (These clauses are identical to the GPLv3).
Now the magic AGPL clause. Brace for it, and read it very carefully:
> 13. Remote Network Interaction; Use with the GNU General Public License.
> Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
Let's break it down:
> If you modify the Program
That is if you are a developer making changes to the source code (or binary, but let's ignore that option)
> your modified version
The modified source code you have created
> must prominently offer all users interacting with it remotely through a computer network
Must include the mandatory feature of offering all users interacting with it through a computer network (computer network is left undefined and subject to wide interpretation)
> an opportunity to receive the Corresponding Source of your version
A direct copy of the source code you have just modified
> from a network server
Directly from a server, without any human involved
(the rest of the statement is irrelevant).
Let's say I am Amazon, and I want to SaaS some AGPL software. How about this:
Step 1: Put it in an internal Git repo (No license implication yet, no changes made)
Step 2: Make that Git repo accessible externally with a specific URL or access key (so it is not guessable) (Clause 9 plus plain redistribution, no modifications, no problem)
Step 3: Modify the software to include a link to that Git repo including the secret key (invokes and is fully compliant with Clause 13) with every response
Step 4: Deploy that software on their internal network (Freedom Zero, invokes Clause 9 during deployment, no extra requirements)
Step 5: Stick a reverse proxy in front that deletes the source code offer (No license implication, does not modify the AGPL software in any way, see Clause 9)
Step 6: Profit
Turns out you have to pick one: either control what people do with your software (which makes your license into a non-free EULA), or don't (which means there is no way for you to control any interaction people have with the software). You can't have it both ways.
I know what you're saying: "But a judge would see right through this trick! Amazon is both modifying the code and setting up the reverse proxy!" Great, then just have different entities do each part. Each part, on its own, is unambiguously not in violation of the license; the developing party is only responsible for including the source code offer, and the running party has no responsibility that it actually reach users if they don't touch the code. Now your license defense relies on proving collusion. Good luck with that if the people involved were careful enough not to write down their evil plans anywhere. Heck, this situation could easily happen semi-organically - a reverse proxy doesn't have to be designed to explicitly remove the source code offer, it could merely be a protocol translator/wrapper that has no support for that specific message/tag, which is something that happens all the time.
Now let's say I am a regular developer of AGPL software and I want to work on it like any other open source project.
Step 1: Clone the GitHub repo
Step 2: Make a change to the code - oops, license violation! Clause 13! I need to change the source code offer first!
Step 1.5: Change the source code offer to point to your repo
Step 2: Make a change to the code and push it
Step 3: Open a pull request with your change
Your change includes the source code offer commit in the history, and cannot be auto-merged. Any AGPL project accepting pull requests from third parties (or even their own developers, if there is no copyright assignment and each developer retains their own copyright) is accepting that everyone is repeatedly violating the AGPL as part of the normal development process, if they're using the GitHub flow and the source code links were not updated in the branches to be merged.
Note that the license doesn't even say anything about Clause 13 being restricted to redistribution or execution or deployment to external users. Merely downloading some AGPL software and changing some code locally is an instant license violation, if you haven't previously made that version accessible and changed the source code offer. Somehow. I don't know. The whole thing is crazy. It's setting rules for mandatory features that must be implemented in the code. It's not a Freedom Zero violation, but it's a Freedom 1 violation instead: The freedom to study how the program works, and change it to make it do what you wish. AGPL Clause 13 restricts how you are allowed to change programs.
As far as I can tell, there is precisely one kind of open source project that could conceivably benefit from the AGPL without being an undue burden on developers and a danger to users: Web apps with nontrivial amounts of JS source code (which would be covered under the license), with the source code offer in that code (so it cannot be removed without invoking the license, even by an automated process, maybe, hopefully a judge would see it that way), and a source code offer mechanism that has the app read its own source code from the live copy, so that no updates to the URL need to happen for different forks.
Anything else, and it's just a terrible license. But the FSF will tell you it's amazing and fixes the SaaS loophole, because they've long since given up on actually being honest and just want to have their cake and eat it too, even when it just isn't possible.
Let's break down this amazing license:
> 9. Acceptance Not Required for Having Copies. > > You are not required to accept this License in order to receive or run a copy of the Program.
So it's not an EULA. Cool. You can freely run the program as long as you don't modify it. Freedom Zero.
> Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.
But if you touch the code, you'd better comply with the License. Great. (These clauses are identical to the GPLv3).
Now the magic AGPL clause. Brace for it, and read it very carefully:
> 13. Remote Network Interaction; Use with the GNU General Public License.
> Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
Let's break it down:
> If you modify the Program
That is if you are a developer making changes to the source code (or binary, but let's ignore that option)
> your modified version
The modified source code you have created
> must prominently offer all users interacting with it remotely through a computer network
Must include the mandatory feature of offering all users interacting with it through a computer network (computer network is left undefined and subject to wide interpretation)
> an opportunity to receive the Corresponding Source of your version
A direct copy of the source code you have just modified
> from a network server
Directly from a server, without any human involved
(the rest of the statement is irrelevant).
Let's say I am Amazon, and I want to SaaS some AGPL software. How about this:
Step 1: Put it in an internal Git repo (No license implication yet, no changes made)
Step 2: Make that Git repo accessible externally with a specific URL or access key (so it is not guessable) (Clause 9 plus plain redistribution, no modifications, no problem)
Step 3: Modify the software to include a link to that Git repo including the secret key (invokes and is fully compliant with Clause 13) with every response
Step 4: Deploy that software on their internal network (Freedom Zero, invokes Clause 9 during deployment, no extra requirements)
Step 5: Stick a reverse proxy in front that deletes the source code offer (No license implication, does not modify the AGPL software in any way, see Clause 9)
Step 6: Profit
Turns out you have to pick one: either control what people do with your software (which makes your license into a non-free EULA), or don't (which means there is no way for you to control any interaction people have with the software). You can't have it both ways.
I know what you're saying: "But a judge would see right through this trick! Amazon is both modifying the code and setting up the reverse proxy!" Great, then just have different entities do each part. Each part, on its own, is unambiguously not in violation of the license; the developing party is only responsible for including the source code offer, and the running party has no responsibility that it actually reach users if they don't touch the code. Now your license defense relies on proving collusion. Good luck with that if the people involved were careful enough not to write down their evil plans anywhere. Heck, this situation could easily happen semi-organically - a reverse proxy doesn't have to be designed to explicitly remove the source code offer, it could merely be a protocol translator/wrapper that has no support for that specific message/tag, which is something that happens all the time.
Now let's say I am a regular developer of AGPL software and I want to work on it like any other open source project.
Step 1: Clone the GitHub repo
Step 2: Make a change to the code - oops, license violation! Clause 13! I need to change the source code offer first!
Step 1.5: Change the source code offer to point to your repo
Step 2: Make a change to the code and push it
Step 3: Open a pull request with your change
Your change includes the source code offer commit in the history, and cannot be auto-merged. Any AGPL project accepting pull requests from third parties (or even their own developers, if there is no copyright assignment and each developer retains their own copyright) is accepting that everyone is repeatedly violating the AGPL as part of the normal development process, if they're using the GitHub flow and the source code links were not updated in the branches to be merged.
Note that the license doesn't even say anything about Clause 13 being restricted to redistribution or execution or deployment to external users. Merely downloading some AGPL software and changing some code locally is an instant license violation, if you haven't previously made that version accessible and changed the source code offer. Somehow. I don't know. The whole thing is crazy. It's setting rules for mandatory features that must be implemented in the code. It's not a Freedom Zero violation, but it's a Freedom 1 violation instead: The freedom to study how the program works, and change it to make it do what you wish. AGPL Clause 13 restricts how you are allowed to change programs.
As far as I can tell, there is precisely one kind of open source project that could conceivably benefit from the AGPL without being an undue burden on developers and a danger to users: Web apps with nontrivial amounts of JS source code (which would be covered under the license), with the source code offer in that code (so it cannot be removed without invoking the license, even by an automated process, maybe, hopefully a judge would see it that way), and a source code offer mechanism that has the app read its own source code from the live copy, so that no updates to the URL need to happen for different forks.
Anything else, and it's just a terrible license. But the FSF will tell you it's amazing and fixes the SaaS loophole, because they've long since given up on actually being honest and just want to have their cake and eat it too, even when it just isn't possible.
> 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.
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.
> 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.
The license is a copyright license and deals exclusively in modification and redistribution, not usage - that includes the source code. "Users" mean "potential users" in this context; whoever hypothetically uses the software in any given version, as it exists in source code form, regardless of whether such users come into existence or not. It doesn't matter whether the software is deployed or not; the license cannot and does not claim to control or have anything to do with that. If it did - if the violation only occurred at the point where the software is deployed and run - then again that would imply this is an EULA that controls usage and violates Freedom Zero.
Again, consider my "two parties" scenario. I make some changes to AGPL software, but never deploy it or offer it as a service. According to you, that is perfectly OK. I then send it to someone. According to you, again, that is perfectly okay, just like contributing to an AGPL project. Then that someone makes zero changes to the code - therefore not triggering clause 13, obviously - and deploys it without updating the source code offer. No problem. If the license worked as you claim, then it doesn't work to close the SaaS loophole at all.
It does not, and the entire hack the FSF came up with is precisely this, converting a usage restriction into a responsibility for the developer making modifications. Everyone defending the AGPL misunderstands this, because the FSF has been very careful to never bring up that this is what they did. They treat it like schrodinger's license: simultaneously claiming it can do things that require it to restrict usage (making it nonfree) and claiming it is a free software copyright license.
> I'd heavily recommend talking to someone with (FOSS) legal experience if you're involved in such distributions, no offense meant.
It's rather difficult to find someone who will consider entertaining the idea that the FSF is completely backwards in their license design, because nobody wants to open that can of worms. People are much happier to just pretend nothing is wrong and move on.
> 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.
Of course, because neither you nor your contributors actually parsed the AGPL properly nor are you aware of the violations occurring on a daily bases. That nobody knows there is a problem doesn't mean there isn't one :)
> Granted, some FANG company refused to use us
No surprise there. I have a hard time using AGPL software too; last time I discovered some on my system I was already in violation, because my distro had patched it without adding a source code offer, and since I use a source-based distro (Gentoo) that patch occurred on my machine, making me responsible for it. On top of that, I was running it as a network service behind a protocol-translating proxy, just because that is how it was meant to be used, so even if it did have a source code offer, it would have been invisible to external users. I was ticking all the boxes for AGPL abuse without even knowing it.
(What nefarious service was I running taking advantage of a poor AGPL project? My personal email server, which used dspam as a spam filter - although not directly exposed to the internet, it could easily be argued that everyone sending mail to me is a "user" of dspam since the data they sent is piped to it, quite directly, and the AGPL does not make any attempt to carefully define these terms)
Right now the only AGPLed software I (knowingly!) run is Nextcloud (with 2 other users besides myself) and (as of a recent license change, sigh) Grafana, but I once thought of making a little patch to a Nextcloud CSS file as a joke, and had to remind myself that that would've been an AGPL violation without packaging it up and distributing it and updating the source link in the footer. For Grafana I also had a tiny proxy-inserted patch (just because it was easier that way than rebuilding, this was before the AGPL change) just to add the ability to display image icons next to dashboard names (again for a little joke displaying character images for servers), but I'm going to get rid of that before the AGPL update on that box because I just don't want to deal with any of this. Not exactly a comfortable feeling knowing I can't even make a trivial change to "free software" running on my own system without breaking the license. And it gives me zero incentive to contribute to these projects. I don't want to support this kind of ecosystem.
(Web apps: for fuck's sake, if you insist on being AGPL, please implement self-serving source code so we don't have to deal with any of this nonsense, and then maybe you can take GitHub pull requests without everyone violating the license too.)
I once had a discussion with the authors of a DAW that used the AGPL license, and pointed out that MIDI is technically a network protocol - meaning their DAW would have to figure out a way to make source code offers over MIDI, to be presented to users on the other end, even though MIDI doesn't even have any standard mechanism for user-interface text. Never mind that MIDI can even be used over a unidirectional transport, so you couldn't even do that at all in some cases. The AGPL doesn't even begin to consider these problems; it was written assuming everything is a web server or something. I got crickets from the devs. Sigh. (Why is a DAW AGPLed to begin with even?)
Seriously, it's a completely broken license, written by some lawyer who though they were being clever and had magically solved the SaaS + free software issue, without bothering to consider the consequences of what they were creating. And now everyone's sweeping the problem under the rug and nobody wants to seriously talk about it. Because how could the FSF be wrong about free software licensing?
> but that's not something really hurting us in any way
I dunno, for what it's worth the AGPL definitely turns me off from contributing to projects, but maybe you aren't losing enough contributors to care ¯\_(ツ)_/¯
This is of course still predicated on you not caring that your contributors are all violating each other's license. Is that a problem? In practice, probably not, if nobody actually makes legal demands over it. But it's a fact, whether it's a problem or not. And I don't like relying on "people being nice and not enforcing license violations" to run my open source projects. We have licenses for a reason, ignoring them and encouraging certain violations just because the situation isn't a problem (or because nobody understands the license) invalidates the entire point of licenses.
> 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.
Too bad that, as I explained, if a company really wants to use AGPL software without contributing back, they still can.
Personally, everything I've written recently is MIT or dual licensed, but I understand the desire not to allow companies to deploy modified versions of open source software without giving back. The AGPL just doesn't fix that problem. At all. Fixing that problem is incompatible with the Free Software Definition. If you really, really want to fix that problem that badly, you have to accept that your license cannot be a Free Software license by the standards we use today. It's one or the other.
The license is a copyright license and deals exclusively in modification and redistribution, not usage - that includes the source code. "Users" mean "potential users" in this context; whoever hypothetically uses the software in any given version, as it exists in source code form, regardless of whether such users come into existence or not. It doesn't matter whether the software is deployed or not; the license cannot and does not claim to control or have anything to do with that. If it did - if the violation only occurred at the point where the software is deployed and run - then again that would imply this is an EULA that controls usage and violates Freedom Zero.
Again, consider my "two parties" scenario. I make some changes to AGPL software, but never deploy it or offer it as a service. According to you, that is perfectly OK. I then send it to someone. According to you, again, that is perfectly okay, just like contributing to an AGPL project. Then that someone makes zero changes to the code - therefore not triggering clause 13, obviously - and deploys it without updating the source code offer. No problem. If the license worked as you claim, then it doesn't work to close the SaaS loophole at all.
It does not, and the entire hack the FSF came up with is precisely this, converting a usage restriction into a responsibility for the developer making modifications. Everyone defending the AGPL misunderstands this, because the FSF has been very careful to never bring up that this is what they did. They treat it like schrodinger's license: simultaneously claiming it can do things that require it to restrict usage (making it nonfree) and claiming it is a free software copyright license.
> I'd heavily recommend talking to someone with (FOSS) legal experience if you're involved in such distributions, no offense meant.
It's rather difficult to find someone who will consider entertaining the idea that the FSF is completely backwards in their license design, because nobody wants to open that can of worms. People are much happier to just pretend nothing is wrong and move on.
> 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.
Of course, because neither you nor your contributors actually parsed the AGPL properly nor are you aware of the violations occurring on a daily bases. That nobody knows there is a problem doesn't mean there isn't one :)
> Granted, some FANG company refused to use us
No surprise there. I have a hard time using AGPL software too; last time I discovered some on my system I was already in violation, because my distro had patched it without adding a source code offer, and since I use a source-based distro (Gentoo) that patch occurred on my machine, making me responsible for it. On top of that, I was running it as a network service behind a protocol-translating proxy, just because that is how it was meant to be used, so even if it did have a source code offer, it would have been invisible to external users. I was ticking all the boxes for AGPL abuse without even knowing it.
(What nefarious service was I running taking advantage of a poor AGPL project? My personal email server, which used dspam as a spam filter - although not directly exposed to the internet, it could easily be argued that everyone sending mail to me is a "user" of dspam since the data they sent is piped to it, quite directly, and the AGPL does not make any attempt to carefully define these terms)
Right now the only AGPLed software I (knowingly!) run is Nextcloud (with 2 other users besides myself) and (as of a recent license change, sigh) Grafana, but I once thought of making a little patch to a Nextcloud CSS file as a joke, and had to remind myself that that would've been an AGPL violation without packaging it up and distributing it and updating the source link in the footer. For Grafana I also had a tiny proxy-inserted patch (just because it was easier that way than rebuilding, this was before the AGPL change) just to add the ability to display image icons next to dashboard names (again for a little joke displaying character images for servers), but I'm going to get rid of that before the AGPL update on that box because I just don't want to deal with any of this. Not exactly a comfortable feeling knowing I can't even make a trivial change to "free software" running on my own system without breaking the license. And it gives me zero incentive to contribute to these projects. I don't want to support this kind of ecosystem.
(Web apps: for fuck's sake, if you insist on being AGPL, please implement self-serving source code so we don't have to deal with any of this nonsense, and then maybe you can take GitHub pull requests without everyone violating the license too.)
I once had a discussion with the authors of a DAW that used the AGPL license, and pointed out that MIDI is technically a network protocol - meaning their DAW would have to figure out a way to make source code offers over MIDI, to be presented to users on the other end, even though MIDI doesn't even have any standard mechanism for user-interface text. Never mind that MIDI can even be used over a unidirectional transport, so you couldn't even do that at all in some cases. The AGPL doesn't even begin to consider these problems; it was written assuming everything is a web server or something. I got crickets from the devs. Sigh. (Why is a DAW AGPLed to begin with even?)
Seriously, it's a completely broken license, written by some lawyer who though they were being clever and had magically solved the SaaS + free software issue, without bothering to consider the consequences of what they were creating. And now everyone's sweeping the problem under the rug and nobody wants to seriously talk about it. Because how could the FSF be wrong about free software licensing?
> but that's not something really hurting us in any way
I dunno, for what it's worth the AGPL definitely turns me off from contributing to projects, but maybe you aren't losing enough contributors to care ¯\_(ツ)_/¯
This is of course still predicated on you not caring that your contributors are all violating each other's license. Is that a problem? In practice, probably not, if nobody actually makes legal demands over it. But it's a fact, whether it's a problem or not. And I don't like relying on "people being nice and not enforcing license violations" to run my open source projects. We have licenses for a reason, ignoring them and encouraging certain violations just because the situation isn't a problem (or because nobody understands the license) invalidates the entire point of licenses.
> 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.
Too bad that, as I explained, if a company really wants to use AGPL software without contributing back, they still can.
Personally, everything I've written recently is MIT or dual licensed, but I understand the desire not to allow companies to deploy modified versions of open source software without giving back. The AGPL just doesn't fix that problem. At all. Fixing that problem is incompatible with the Free Software Definition. If you really, really want to fix that problem that badly, you have to accept that your license cannot be a Free Software license by the standards we use today. It's one or the other.
A thought that's probably dumb: how many of these issues could you resolve by just adding the word "reasonable"? Ie:
> If you modify the Program, you must make a reasonable effort to offer all users interacting with the modified program remotely through a computer network [...] an opportunity to receive the Corresponding Source of your version
IANAL, but offering the source to users of a web app seems pretty reasonable. offering the source over MIDI does not.
This doesn't solve the problem of having two different parties, of course.
I'm sympathetic to the need for a license like the AGPL. But—perhaps it should be just be a EULA. Maybe freedom zero was a bad idea. It was written in a world where AWS didn't exist, and there's no shame in realizing that you need to change with the times.
> If you modify the Program, you must make a reasonable effort to offer all users interacting with the modified program remotely through a computer network [...] an opportunity to receive the Corresponding Source of your version
IANAL, but offering the source to users of a web app seems pretty reasonable. offering the source over MIDI does not.
This doesn't solve the problem of having two different parties, of course.
I'm sympathetic to the need for a license like the AGPL. But—perhaps it should be just be a EULA. Maybe freedom zero was a bad idea. It was written in a world where AWS didn't exist, and there's no shame in realizing that you need to change with the times.
[deleted]
Burden on devs and danger to users? Just give us the damn code. Take a look at the SSPL as well. Corporations will do all sorts of gymnastics to benefit off FOSS without releasing anything. I wish there was a "just give us the damn code" license, but there isn't. Calling the AGPL a EULA is just an insult.
Counterpoint: How many are dying because the software isn’t free? It’s possible that more could be saved if it was. Perhaps harm doesn’t rank highly for those seeking to make profits from medical equipment?
You think software companies get rich from the proprietary software in medical equipment sold in low quantities that cost a million dollar and is made from super strong magnets creating insane magnetic forces?
Answering your question: probably zero. Medical equipment is expensive due to the very high-tech technology it requires (the aforementioned magnets, but for ultrasound imaging one has to simultaneously output and receive sound waves in multiple dimensions) as well as the safety level being so high (you don’t want the given radiation amount overflow due to a bug).
Find blame in for-profit insurances instead.
Answering your question: probably zero. Medical equipment is expensive due to the very high-tech technology it requires (the aforementioned magnets, but for ultrasound imaging one has to simultaneously output and receive sound waves in multiple dimensions) as well as the safety level being so high (you don’t want the given radiation amount overflow due to a bug).
Find blame in for-profit insurances instead.
Yes, I do think that "software companies" are aiming to make money off of software (by definition). That aside, I do not understand what point you're trying to make. Sure, software development is likely not the most expensive part of medical devices (although I wouldn't be so sure that's generally true). Free software could still speed up R&D and therefore help save lives.
>"They should die for the cause."
In his stance, more like "proprietary driver vendors are holding hostage of patients."
In his stance, more like "proprietary driver vendors are holding hostage of patients."
I don't know how much to read into this anecdote, given a related one from around the same time...
In a discussion with RMS, after a little argument, he agreed that the immediate safety of certain underdogs who needed secure communications trumped libre software goals. (The question was something about the libre software solution at the moment being inferior for some threat model.)
In a discussion with RMS, after a little argument, he agreed that the immediate safety of certain underdogs who needed secure communications trumped libre software goals. (The question was something about the libre software solution at the moment being inferior for some threat model.)
That's interesting! He was definitely playing an antagonistic character ("I have a bad ear", "I can't hear you" whenever someone said something disagreeable; one person didn't get it and kept repeating their sentence more loudly to no change). I could imagine him having that more liberal private stance whilst keeping the public one consistently firm.
RMS seems absolutely uncompromising on his principles (whether publicly, or in smaller groups), but I think his principles aren't only about libre software.
Maybe the difference between the two anecdotes was details of what was being weighed against libre software. In his value system, maybe the success of an underdog's mission (maybe for a different kind of freedom) is more important than lives saved? Or maybe he was just feeling punchy in one of the meetings?
Maybe the difference between the two anecdotes was details of what was being weighed against libre software. In his value system, maybe the success of an underdog's mission (maybe for a different kind of freedom) is more important than lives saved? Or maybe he was just feeling punchy in one of the meetings?
why would life saving equipment be permitted to be proprietary in the first place.
how many people have died because they could not access it.
you speak as if proprietary causes no harm.
how many people have died because they could not access it.
you speak as if proprietary causes no harm.
how many people have died because they could not access it.
It's only in the last hundred years that one's health couldn't be discussed in a transactional quid pro quo. Both humankind (300,000 years) and evolving life (3.5B years) never held that stipulation.
It's only in the last hundred years that one's health couldn't be discussed in a transactional quid pro quo. Both humankind (300,000 years) and evolving life (3.5B years) never held that stipulation.
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.
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.
> doesn't mean there is no guilt if your actions effectively lead to the named peasants are killed.
but it's not a law of physics that the feudal lord kills a peasant - they did it by choice. This is what absolves the rebels from any guilt of the deaths. The rebels, a priori, believes that their rebellion is just, and therefore, by definition it cannot be morally wrong. It's not their fault if the feudal lord decides to do something morally wrong, based on any reason (including to extort the rebels).
This is different from a case where actions of the rebel directly lead to deaths of peasants - for example, bombing the residence of the feudal lord which causes collateral damage. In this case, the action must be judged individually.
but it's not a law of physics that the feudal lord kills a peasant - they did it by choice. This is what absolves the rebels from any guilt of the deaths. The rebels, a priori, believes that their rebellion is just, and therefore, by definition it cannot be morally wrong. It's not their fault if the feudal lord decides to do something morally wrong, based on any reason (including to extort the rebels).
This is different from a case where actions of the rebel directly lead to deaths of peasants - for example, bombing the residence of the feudal lord which causes collateral damage. In this case, the action must be judged individually.
Yes, if the right you're defending is as arcane and hard to explain as
libre software.
In the case of medical training, you're taught that you should assume an incapacitated person would like to receive care unless otherwise instructed. I think that pretty easily carries over to software licensing too; unless your patient refuses to receive treatment aided by proprietary software, you should assume that they're comfortable having their body fed to the proprietary meat-grinder.
Appeals to emotion are a fallacy
If that quote from RMS were to be taken seriously, then he should not even take a plane, or a car. Hopefully he'll never be in the position of choosing death vs free software.
The moral burden is on the firmware makers to release the sources. When do we stop pretending graphics stacks are some magical steampunk machinery? There is nothing unique to a few thousand lines of code, they should release it.
Properly isolated accessory non-free hardware is a good thing, and for a user whose threat model requires libre hardware, the security model of the PinePhone or Librem 5 where the LTE modem is isolated with a kill switch to interact via USB (rather than connected via PCIe, which would have direct memory access) is the right choice.
Is a Thinkpad T400 with a Core2Duo and SSD the right choice in 2022? What about a Pinebook Pro? Friends and acquaintances I know are using these computers as their primary devices today.
Is a Thinkpad T400 with a Core2Duo and SSD the right choice in 2022? What about a Pinebook Pro? Friends and acquaintances I know are using these computers as their primary devices today.
FYI, that ThinkPad T400 that the FSF certified has multiple microcontrollers running proprietary updatable blobs on the LPC bus with full access to DMA to all of system memory. I am literally more insulated from blobs with an Apple M1, which runs a dozen blobs none of which can take over my OS (thanks to pervasive IOMMU use), than with hardware that the FSF claims "respects my freedom".
Agree with you, but a quick clarification: PCIe IOMMUs exist now, a PCIe device doesn't get DMA access to main memory.
In terms of security and stability I think FSF view is correct
Although I think they could have a second tier, more relaxed for Debian, NixOS and others, that exclude nonfree software/firmware but allows you to enable it. But in general I think it is commendable that they have been able preserve their values and not dilute and disappear
When I buy my hardware I make sure it is compatible, stable and won't have many issues with Libre Linux, even thing like swapping the wireless card to a compatible one
And this has been the rule also for all Linux users. You want to make sure you have a smooth experience, you will have to check for hardware recommendations. Want fingerprint working? Better be sure before you buy
Regarding security most Libre people are not serving cloud services in their computers, and install only open source. So the microcode security mitigations like, spectre and meltdown, are mostly unnecessary. Also browsers and kernels have been patched for it anyway
When I configure a server I will probably majorally never upgrade it, because it will always cause problems, sometimes small, other times big headaches. I would sooner configure a new one and migrate things slowly
If one microcode update is enough to fix your system is also enough to break it: Intel to disable TSX by default on more CPUs with new microcode https://news.ycombinator.com/item?id=27664856
This recent security paranoia that you should be updating everything every day or else the hackers will get you! seems unnecessary and potentially harmful
Although I think they could have a second tier, more relaxed for Debian, NixOS and others, that exclude nonfree software/firmware but allows you to enable it. But in general I think it is commendable that they have been able preserve their values and not dilute and disappear
When I buy my hardware I make sure it is compatible, stable and won't have many issues with Libre Linux, even thing like swapping the wireless card to a compatible one
And this has been the rule also for all Linux users. You want to make sure you have a smooth experience, you will have to check for hardware recommendations. Want fingerprint working? Better be sure before you buy
Regarding security most Libre people are not serving cloud services in their computers, and install only open source. So the microcode security mitigations like, spectre and meltdown, are mostly unnecessary. Also browsers and kernels have been patched for it anyway
When I configure a server I will probably majorally never upgrade it, because it will always cause problems, sometimes small, other times big headaches. I would sooner configure a new one and migrate things slowly
If one microcode update is enough to fix your system is also enough to break it: Intel to disable TSX by default on more CPUs with new microcode https://news.ycombinator.com/item?id=27664856
This recent security paranoia that you should be updating everything every day or else the hackers will get you! seems unnecessary and potentially harmful
Anyone know if the mnt reform laptop is blob-less?
https://mntre.com/media/reform_md/2020-05-08-the-much-more-p...
https://mntre.com/media/reform_md/2020-05-08-the-much-more-p...
It has one tiny blob for ram initialization, people are looking into removing it. It may become RYF certified. Freedom wise, it is the best modern laptop.
Better than the pinebook pro?
Yes. Pinebook pro has one or more other blobs and they are for more significant functionality.
Hmmm... I like RK3399-based devices because they need very few blobs. Would you mind to list which blobs the pinebook pro needs?
https://forum.pine64.org/showthread.php?pid=97828
The above link contains the answers applicable to your question.
The above link contains the answers applicable to your question.
The imx.8 can't even initialize RAM without blobs. If it comes with a modern WiFi it will need blobs too. Don't know the details about the display, but I don't think it affects all RK3399 devices.
Not blob-free. Imx8 needs blobs to train RAM. There probably other blobs too.
A 2009 thinkpad is rather capable of being a daily driver for most people. Saying otherwise, you're only contributing to the growing problem of ewaste.
Even the T60 offers a decent performance if your usecase is browsing the web, mail and other simple tasks.
The FSF might be wrong in some aspects but there's no real alternative to Libreboot. The Framework laptop is not free software friendly. Even if it was corebooted, it would require many proprietary blobs and it's highly unlikely, if not impossible, that they will be ever able to remove the Intel ME.
There are other options that are nearer to be completely free (as in freedom) hardware, eg the Pinebook Pro. I'm unsure if there are any proprietary blobs required to boot it tho, but the lack of Intel ME makes it a much better candidate for a new generation of 'libre' hardware.
Even the T60 offers a decent performance if your usecase is browsing the web, mail and other simple tasks.
The FSF might be wrong in some aspects but there's no real alternative to Libreboot. The Framework laptop is not free software friendly. Even if it was corebooted, it would require many proprietary blobs and it's highly unlikely, if not impossible, that they will be ever able to remove the Intel ME.
There are other options that are nearer to be completely free (as in freedom) hardware, eg the Pinebook Pro. I'm unsure if there are any proprietary blobs required to boot it tho, but the lack of Intel ME makes it a much better candidate for a new generation of 'libre' hardware.
That 2009 ThinkPad that the FSF certified is running proprietary blobs in updatable microcontrollers connected to the LPC bus which have full access to RAM and to take over the OS. Blobs which you can't audit, modify, sandbox, nor verify are the correct intended version.
I'd rather buy an M1; sure, it runs a pile of blobs, but at least I know those blobs are there and they're all sandboxed behind IOMMUs and cannot take over or compromise my OS.
I'd rather buy an M1; sure, it runs a pile of blobs, but at least I know those blobs are there and they're all sandboxed behind IOMMUs and cannot take over or compromise my OS.
>Even the T60 offers a decent performance if your usecase is browsing the web,
I actually own a T60 and this is not true, for any reasonable definition of "decent".
The web is a horrid wasteland of poor performance JavaScript.
Forget running any Electron apps (a necessity it seems in this day of Zoom and MS Teams).
I actually own a T60 and this is not true, for any reasonable definition of "decent".
The web is a horrid wasteland of poor performance JavaScript.
Forget running any Electron apps (a necessity it seems in this day of Zoom and MS Teams).
That hardware is 13 years old now and laptops tend to start falling apart and spares become difficult to source.
I have a Dell E6410 laptop. Which is really easy to repair and built like a tank. Keyboard has started dying and there are no replacement keyboards on ebay that are UK. You are asking people to use things that are quite out of date and may not be easily repairable.
I've got desktop machines from 2007 that I've had to replace the motherboard (wasn't worth it really) because capacitors had started bulging (and it was a board from a well known manufacturer). It probably more capable than the machines you mention but it was unstable as the parts were literally disintegrating.
> Even the T60 offers a decent performance if your usecase is browsing the web, mail and other simple tasks.
I really get annoyed by this. "If your tasks are restricted to a very small subset of what I think a basic user actually might want to use your computer for this will be okay". What happens when someone needs to use more modern software (even for one off thing like a job interview over a video conference), or use a particular site for taxes or whatever that needs a more modern hardware. They are screwed.
I have an Amiga 1200 with an accelerator card and technically I can use the web, check mail, chat (IRC basically) and do 85% of what I do online. But for the other 15% it is a total non-option and that other 15% might be what pays my bills.
I have a Dell E6410 laptop. Which is really easy to repair and built like a tank. Keyboard has started dying and there are no replacement keyboards on ebay that are UK. You are asking people to use things that are quite out of date and may not be easily repairable.
I've got desktop machines from 2007 that I've had to replace the motherboard (wasn't worth it really) because capacitors had started bulging (and it was a board from a well known manufacturer). It probably more capable than the machines you mention but it was unstable as the parts were literally disintegrating.
> Even the T60 offers a decent performance if your usecase is browsing the web, mail and other simple tasks.
I really get annoyed by this. "If your tasks are restricted to a very small subset of what I think a basic user actually might want to use your computer for this will be okay". What happens when someone needs to use more modern software (even for one off thing like a job interview over a video conference), or use a particular site for taxes or whatever that needs a more modern hardware. They are screwed.
I have an Amiga 1200 with an accelerator card and technically I can use the web, check mail, chat (IRC basically) and do 85% of what I do online. But for the other 15% it is a total non-option and that other 15% might be what pays my bills.
The author seems to limit their analysis to laptops. As far as I know, desktop/server class hardware does have reasonable options like those from Raptor Engineering (such as Talos: https://www.raptorengineering.com/TALOS/talos_comparison.php), though I could be wrong. Could this more of an issue relating to how laptops/phones are built/marketed/sold compared with desktops/servers (and given those effects, building a free-software-based laptop/phone is practically impossible given the lack of possible components)?
Indeed, the Raptor systems are about as free as you can get for a desktop system, as far as I can tell. I was particularly impressed when they pointed me at the source code for their RAM training routine; that one has been a sticking point in many other systems.
They still aren't 100% free because that is impossible; there is no clear line to be drawn between hardware and software, and the hardware isn't free. But at least we can truthfully say they have no nonfree mutable blobs or large ROMs, and even some critical small ROM blobs are documented and open source, like the CPU boot ROM.
(We can't say there are no nonfree ROM blobs - I guarantee there's a small CPU running nonfree ROM code somewhere in an IC on the board and they just don't know about it, because manufacturers do that all the time - and besides, even if their systems somehow avoid that, your monitor, keyboard, and mouse will all have that problem).
They still aren't 100% free because that is impossible; there is no clear line to be drawn between hardware and software, and the hardware isn't free. But at least we can truthfully say they have no nonfree mutable blobs or large ROMs, and even some critical small ROM blobs are documented and open source, like the CPU boot ROM.
(We can't say there are no nonfree ROM blobs - I guarantee there's a small CPU running nonfree ROM code somewhere in an IC on the board and they just don't know about it, because manufacturers do that all the time - and besides, even if their systems somehow avoid that, your monitor, keyboard, and mouse will all have that problem).
This discussion all seems to boil down to the semantics of what's "firmware", what's "software" and what's "hardware". Considering how blurred the line really is between the three, the feud seems pedantic at best.
FSF should stick to software only, learn to see shades of grey and label hardware accordingly or reject anything that isn't open until silicon (silicon excluded). Current choice is half-baked.
FSF should stick to software only, learn to see shades of grey and label hardware accordingly or reject anything that isn't open until silicon (silicon excluded). Current choice is half-baked.
[deleted]
I had a discussion similar to this with RMS a while back and he seemed to think that the x86 and ARM architectures were completely hopeless for this because of the management engines etc. At that time there were credible attempts to build completely blob-free POWER9 systems, so Ifigured that was the thing to get once they got a bit more affordable. I don't think the Talos stuff ended up blob free, but it is way less blobby than x86 stuff. Maybe there is hope of blobless RISC-V systems some day.
The Talos II is blob-free. At launch, proprietary binary-only firmware was required for the network interface, but Raptor Computing Systems offered a bounty to reverse engineer and do a Free Software re-implementation of the firmware, and that effort succeeded and the bounty was paid. See:
https://wiki.raptorcs.com/wiki/Project_Ortega
https://github.com/meklort/bcm5719-fw
https://wiki.raptorcs.com/wiki/Project_Ortega
https://github.com/meklort/bcm5719-fw
Most processors with Arm cores do not have "management engines", in fact lots are almost blob-free. Some like Marvell Armada 7k/8k can run without any blobs.
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
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
Is RYF certification a significant market force among users who want more open devices? I don't really follow it closely enough to know, but I checked in on the Librem 5 project periodically and this is the first I heard about RYF certification for the project, or the implication that it would be a significant driver of customer behavior. Is my outsiders impression of this niche incorrect?
Personally, I'd love to have a certified device. I'd like to support the cause because I fear my devices can became as locked down as smartphones and video game consoles.
People may mock now, but the trend with regard to DRM, IME and others make me consider "the right to read" as not mere fiction
People may mock now, but the trend with regard to DRM, IME and others make me consider "the right to read" as not mere fiction
I think if a reasonable product actually got RYF certification it would attract a lot of people who have so far just accepted that an open device isn't happening and compromises need to be made.
Basically I don't check RYF certification before buying a product, but if I heard of one getting it I'd be interested in it.
Basically I don't check RYF certification before buying a product, but if I heard of one getting it I'd be interested in it.
I’m confused. Who’s the target audience of this post? Anyone strictly adhering to FSF recommendations is most likely not a for profit business, and therefore probably doesn’t give a care about spectre or meltdown, for example. I for one add mitigations=off to all my personal systems boot flags.
Although small, FLOSS supporters are severely underserved. I think it is possible to use the certification as a means to profit. Even if only for a few products or to get a good image among a faithful group. The sites listed selling ryf-certified devices are certainly benefitting commercially from that.
FLOSS supporters are severely underserved
I'd say the invisible hand is getting it right here. FLOSS advocates are the worst kind of customer -- both frugal and sententious.
I'd say the invisible hand is getting it right here. FLOSS advocates are the worst kind of customer -- both frugal and sententious.
FLOSS advocates are the best kind of customer -- both loyal and proud.
Some open firmware resources:
https://wiki.debian.org/Firmware/Open
https://wiki.debian.org/Firmware/Open
I've got the feeling the author has read my comment: https://news.ycombinator.com/item?id=30036588
What is said about librem5 is irrelevant: it is not certified.
What is said about gaming the certification is irrelevant: no currently certified devices does it.
There are modern certified devices: Talos motherboards.
There are no modern laptops certified? Blame the vendors. OK, this may not make them change their mind, but while we are not fully independent, I see no other way.
What is said about librem5 is irrelevant: it is not certified.
What is said about gaming the certification is irrelevant: no currently certified devices does it.
There are modern certified devices: Talos motherboards.
There are no modern laptops certified? Blame the vendors. OK, this may not make them change their mind, but while we are not fully independent, I see no other way.
There's a ton of expertise being bandied about here.
It's sad any of it is being directed towards sophistic, quasi-religious debate.
It's sad any of it is being directed towards sophistic, quasi-religious debate.
The central problem here, is that RYF, just like the FSF itself, is outdated and hasn’t been relevant for a decade or more.
It’s a dinosaur from another era with its hypocritical RAM vs ROM policies, or “secondary processor” loopholes.
It assumes that there’s one Central processor in charge, something that hasn’t been true for a very long time.
Which parts of an SOC is central? The CPU? Great. Modern CPUs are multicore chips, so which one are central and which one are secondary?
It’s a dinosaur from another era with its hypocritical RAM vs ROM policies, or “secondary processor” loopholes.
It assumes that there’s one Central processor in charge, something that hasn’t been true for a very long time.
Which parts of an SOC is central? The CPU? Great. Modern CPUs are multicore chips, so which one are central and which one are secondary?
No. The hardware industry's relationship with the user owning their own devices is harmful.
inshadows(1)
> 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 legal language that defines the FSF's "libre."
What I'm reading is that capable libre hardware does not exist, or at least has not existed for many years.
Why accuse the FSF of hypocrisy?
Later,
> At this point, total blob-free computing is a fool’s errand, so there are a lot of AMD Ryzen-based machines that will give you decent performance and GPU acceleration without the need for proprietary drivers.
Indeed, I don't use truly libre hardware either. I buy whatever The Man makes available. Libre hardware is still a worthy goal. There is no harm here on account of the FSF.