> 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.
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.
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.
> 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
> 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?
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.
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
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.
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.
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.
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.
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.
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.
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.
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?
