> 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.
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.
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...
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.
(Bravo.)
> 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'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...
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'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.
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
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.
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.
> 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.
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.
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.
> ... 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?
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 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.
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.
"They should die for the cause."
Harm isn't very present on the FSF priority list.
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.
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
https://mntre.com/media/reform_md/2020-05-08-the-much-more-p...
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.
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).
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.
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
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
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'd say the invisible hand is getting it right here. FLOSS advocates are the worst kind of customer -- both frugal and sententious.
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.
It's sad any of it is being directed towards sophistic, quasi-religious debate.
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?
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.
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.
> 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.
cooperated with by your carrier.
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).
The M4 core was already there in the SoC sitting unused, it's not like it was added just for firmware loading ;)
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!”
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.
Your CPU comes with patchable proprietary software. Period.
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.
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 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.
https://www.reddit.com/r/libreboot/comments/pqs0g0/technoeth...
https://www.reddit.com/r/linux/comments/4hy9hf/ordered_a_lib...
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.
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.
"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.
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).
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.
> 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.
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.
I've been for the last year shouting myself hoarse on emacs forums regarding this hypocrisy.
> 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.
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
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".
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.
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....
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
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.
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
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.
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.
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 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.
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.
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?
> 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.
So, yes it is possible to have a modern and affordable ryf-certified system.
https://forrestheller.com/Apollo-11-Computer-vs-USB-C-charge...
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.
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.
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.
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.
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.
In his stance, more like "proprietary driver vendors are holding hostage of patients."
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.)
how many people have died because they could not access it.
you speak as if proprietary causes no harm.
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.
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'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 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 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.
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.
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.
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.
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?
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.
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.
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'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.
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.
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.
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"?
“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.
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.
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.
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.
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.
> 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.
Now I want to hear what FSF has to say about this...
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 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.
> 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.
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.
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.
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.
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.
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.
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.
The above link contains the answers applicable to your question.
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).
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.