17 ms·

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

170 points by meithecatte 5y ago

simfree 5y ago
Properly isolated accessory non-free hardware is a good thing, and for a user whose threat model requires libre hardware, the security model of the PinePhone or Librem 5 where the LTE modem is isolated with a kill switch to interact via USB (rather than connected via PCIe, which would have direct memory access) is the right choice. Is a Thinkpad T400 with a Core2Duo and SSD the right choice in 2022? What about a Pinebook Pro? Friends and acquaintances I know are using these computers as their primary devices today.
- cjbprime 5y ago
  Agree with you, but a quick clarification: PCIe IOMMUs exist now, a PCIe device doesn't get DMA access to main memory.
- marcan_42 5y ago
  FYI, that ThinkPad T400 that the FSF certified has multiple microcontrollers running proprietary updatable blobs on the LPC bus with full access to DMA to all of system memory. I am literally more insulated from blobs with an Apple M1, which runs a dozen blobs none of which can take over my OS (thanks to pervasive IOMMU use), than with hardware that the FSF claims "respects my freedom".
MathMonkeyMan 5y ago
I'm well out of my realm of expertise here, but I had a gut reaction to: > Libreboot, being FSF-recommended, also has this policy of disallowing firmware blobs in the source tree, despite it being a source of nothing but problems. Later the author points out how there isn't any contemporary libre hardware that would satisfy users (vaguely but reasonably described), and so "free" solutions utilize loopholes in the 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.
- cmeacham98 5y ago
  > Why accuse the FSF of hypocrisy? I'm not sure I fully agree with the author, but I think their point is that the FSF makes exceptions for binary blobs in some places because of usability, but then denies similar exceptions elsewhere because they're not libre. The complaint is that the decision on what counts as being included in the loopholes appears largely arbitrary, at least from an outsider's perspective.
  - throwaway81523 5y ago
    Is that hypocrisy, or just an oversight / unintended consequence?
  - medo-bear 5y ago
    last time i looked at their guidelines i understood it that proprietry blobs will be tolerated as long as libre alternatives dont exist. for an organisation that values free software above all else (including security) i think this is a principled approach. i fail to see any hypocricy on the other hand whenever there is some GNU/FSF topic on hn there are always the same people taking the opportunity to throw mud at these organisations. think of this what you will
- giantrobot 5y ago
  > Why accuse the FSF of hypocrisy? If I ship some piece of hardware on a PC with its firmware burned into a ROM and do not provide the source (a binary blob), the FSF will happily say my hardware is RYF-certified. If I ship the exact same hardware with the exact same firmware as a binary blob but in Flash RAM or loaded at init by a driver they'll accuse me of not "respecting freedom". Same hardware. Same firmware. Same vendor. The FSF is hypocritical because their RYF certification allows me to get certified so long as I make my hardware impossible to update. I don't have to provide any source or actually respect anyone's freedom to get in their good graces, I just need to burn my binary blob into a ROM. If I save a dollar per unit by loading the same firmware blob through a driver into the device's RAM, I'm an evil freedom disrespecting jerk. Besides being hypocritical it also makes for extremely poor security practice and affects longevity and e-waste. If I can't update a device firmware it might have some security flaw that can't be patched and maintain the RYF certification. If I roll an updated firmware and have the driver push it to the device I lose my previous certification unless the new blob is open sourced. Devices that can't be updated are also more likely to be discarded. An updated OS might be incompatible with my old firmware in ROM so needs to be tossed when upgrading. Same if a security fix can't be pushed out. So the FSF doesn't seem to actually care about freedoms, just whether a vendor technically meets their requirements. They also engender a poor security posture with their policy. Libre hardware is a worthy goal but the FSF's policies and technicalities around certification don't really lead to that goal.
roenxi 5y ago
> ...In other words, you can’t microcode update a CPU to add or substantially change capabilities... > ... vulnerabilities such as Meltdown and Spectre, which were partially mitigated through a microcode update ... Of these two snippets, only one can be true. Either opaque microcode updates can substantially change how a system performs, or they can't. These mitigations are major changes to how the processor works. This post looks to me like a fairly typical "doesn't quite get what they mean by freedom" take, of which there are many (which is cool, freedom isn't everyone's cup of tea). The FSF has been quite consistent that if there is a choice to be made, the user should have a practical way of making that choice. If the manufacturer can change how a CPU works with a microcode update, the user should be able to as well. The FSF has a clear role here. Their job is to say "this software is free, this software is not". People constantly call on them to compromise on that role in the name of security/convenience/helpfulness/strategic adoption concerns/the impractical nature of their stance. The FSF should and does ignore those people. They are a (slightly quirky, yes) moral lighthouse more than an adoption friendly technical project. This microcode is not free software and someone should be pointing that out and complaining about it. If the FSF isn't taking a stand against non-free microcode, who will?
- garaetjjte 5y ago
  Yet they are fine with running microcode as long you don't update it. It doesn't make sense. Blobs don't disappear just because they are hidden in ROM.
  - DarylZero 5y ago
    Apparently it's OK because both the vendor and the user are prevented from updating it. Thus there's no power differential between them on that specific point.
  - TT-392 5y ago
    That one kinda makes sense, because, when you can't update it, there isn't really much of a practical difference between something implemented in hardware or firmware. So not allowing blobs in rom would almost be hypocritical if you don't also mandate that the actual silicon of the chip is completely free.
jeroenhd 5y ago
I think the ideology of the FSF is a perfectly fine one. It's the hardware vendors that insist on binary blobs that are the problem here. Nobody produces truly free consumer hardware and nobody has produced any for years now. Everything is hidden away because of fears of patent lawsuits and other people copying this One Neat Trick when initializing the devices. Intel would lose very little if it published the source code for the blobs loaded into their processors, because the signature requirements prevent anyone else from developing their own microcode, yet it still encrypts and obfuscates the compiled code. The same is true for most chip and UEFI suppliers. I hope riscv will soon take off in a way that foregoes all of these blobs, though I highly doubt it since modern hardware is encumbered by patents and secrets. It's a sad reality that free, libre computers do not exist and blaming the FSF for having high standards is the wrong approach.
- kryptiskt 5y ago
  > I think the ideology of the FSF is a perfectly fine one. It's the hardware vendors that insist on binary blobs that are the problem here. Their ideology has led them into preferring proprietary firmware that is inaccessible to the user like in the Purism example. I hate that, there is hope that a device that requires binary blobs from the main OS can be reverse engineered and free software developed for it. Making it inaccessible to tinkering is strictly worse for the user in all respects.
  - marcodiego 5y ago
    People are parroting "the purism example...". Just stop it! Librem-5 is NOT certified!
    - marcan_42 5y ago
      But they want to be certified, and the hilarious RAM initialization workaround was absolutely done as part of trying to get certified.
      - smitop 5y ago
deleted 5y ago
[deleted]
marcodiego 5y ago
I've got the feeling the author has read my comment: https://news.ycombinator.com/item?id=30036588 https://news.ycombinator.com/item?id=30036588 What is said about librem5 is irrelevant: it is not certified. What is said about gaming the certification is irrelevant: no currently certified devices does it. There are modern certified devices: Talos motherboards. There are no modern laptops certified? Blame the vendors. OK, this may not make them change their mind, but while we are not fully independent, I see no other way.
basilgohar 5y ago
Very few people or organizations willingly give up control. The whole reason of using copyright law to "enforce" freedom by preventing free software from becoming unfree was because of how much the current legal framework around imaginary property is stacked against a libre approach. So, it's a tough game to play, but FSF didn't achieve what it has thus far by being soft or compromising. Substantial change with hostile parties doesn't happen by constantly yielding.
- anjbe 5y ago
  Since hardware vendors by and large ignore RYF certification and the FSF’s opinions in general, it’s hardly “yielding” for the FSF to change its policies if the existing policies are harmful to the free software community. The people who are most vocal about FSF’s incorrect views on firmware are those who themselves are bringing free operating systems to new hardware, writing drivers, and reverse engineering hardware and firmware. They are not hostile parties—their contributions are among the most important to free software today, and their opinions should hold more weight.
someoneelse9 5y ago
A 2009 thinkpad is rather capable of being a daily driver for most people. Saying otherwise, you're only contributing to the growing problem of ewaste. Even the T60 offers a decent performance if your usecase is browsing the web, mail and other simple tasks. The FSF might be wrong in some aspects but there's no real alternative to Libreboot. The Framework laptop is not free software friendly. Even if it was corebooted, it would require many proprietary blobs and it's highly unlikely, if not impossible, that they will be ever able to remove the Intel ME. There are other options that are nearer to be completely free (as in freedom) hardware, eg the Pinebook Pro. I'm unsure if there are any proprietary blobs required to boot it tho, but the lack of Intel ME makes it a much better candidate for a new generation of 'libre' hardware.
- marcan_42 5y ago
  That 2009 ThinkPad that the FSF certified is running proprietary blobs in updatable microcontrollers connected to the LPC bus which have full access to RAM and to take over the OS. Blobs which you can't audit, modify, sandbox, nor verify are the correct intended version. I'd rather buy an M1; sure, it runs a pile of blobs, but at least I know those blobs are there and they're all sandboxed behind IOMMUs and cannot take over or compromise my OS.
- na85 5y ago
  >Even the T60 offers a decent performance if your usecase is browsing the web, I actually own a T60 and this is not true, for any reasonable definition of "decent". The web is a horrid wasteland of poor performance JavaScript. Forget running any Electron apps (a necessity it seems in this day of Zoom and MS Teams).
- YEwSdObPQT 5y ago
  That hardware is 13 years old now and laptops tend to start falling apart and spares become difficult to source. I have a Dell E6410 laptop. Which is really easy to repair and built like a tank. Keyboard has started dying and there are no replacement keyboards on ebay that are UK. You are asking people to use things that are quite out of date and may not be easily repairable. I've got desktop machines from 2007 that I've had to replace the motherboard (wasn't worth it really) because capacitors had started bulging (and it was a board from a well known manufacturer). It probably more capable than the machines you mention but it was unstable as the parts were literally disintegrating. > Even the T60 offers a decent performance if your usecase is browsing the web, mail and other simple tasks. I really get annoyed by this. "If your tasks are restricted to a very small subset of what I think a basic user actually might want to use your computer for this will be okay". What happens when someone needs to use more modern software (even for one off thing like a job interview over a video conference), or use a particular site for taxes or whatever that needs a more modern hardware. They are screwed. I have an Amiga 1200 with an accelerator card and technically I can use the web, check mail, chat (IRC basically) and do 85% of what I do online. But for the other 15% it is a total non-option and that other 15% might be what pays my bills.
Avamander 5y ago
This discussion all seems to boil down to the semantics of what's "firmware", what's "software" and what's "hardware". Considering how blurred the line really is between the three, the feud seems pedantic at best. FSF should stick to software only, learn to see shades of grey and label hardware accordingly or reject anything that isn't open until silicon (silicon excluded). Current choice is half-baked.
inshadows 5y ago
- LeFantome 5y ago
irfwashere 5y ago
If you'll forgive my naivete here I've been thinking a lot about the FSF philosophy and wanted to ask HN: how big of a project would it be to create a fully libre (whatever you want to call you it) laptop? Like how feasible is it to use "free" components put together into a package and what kind of budget would be required? I think China has a few companies working on domestic processors. Let's say they are convinced by Stallman's charisma to make chips that are not cutting edge but decent, and libre. Whatever your thoughts are on China but I would suggest to the FSF to slowly move in that direction. Where all the component schematics are open and viewable. At least to go for auditability since no one trusts the Chinese. Like I said, forgive the naivete, but it feels like a noble yet lofty goal. And then proceed to go into every industry with right to repair issues. Deere tractor competitors, home appliances, and so on. In the name of component longevity and repairability. All of this to repudiate forced obsolescence and to promote end user freedoms. It's a stretch but I enjoy dreaming about it. Hoping a better world is possible.
- deleted 5y ago
  [deleted]
- marcan_42 5y ago
  That "libre" gives you auditability is a common myth believed by those pushing for libre hardware. The reality is you can't audit silicon, because it's a destructive process requiring extremely expensive analysis equipment. You always have to trust the chip manufacturer; doesn't matter how documented the chip design is, even if the masks are outright public. You can never know that your CPU is not backdoored. That's just a physical reality. There is one exception: FPGAs, under the premise that "generically" backdooring an FPGA is computationally infeasible. That's how Precursor gets to seriously claim trustability. https://www.crowdsupply.com/sutajio-kosagi/precursor 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.
  - DarylZero 5y ago
    You can still backdoor a FPGA in the style of Reflections on Trusting Trust... wait for known code to be installed into the FPGA and then patch it.
jancsika 5y ago
Anyone know if the mnt reform laptop is blob-less? https://mntre.com/media/reform_md/2020-05-08-the-much-more-personal-computer.html https://mntre.com/media/reform_md/2020-05-08-the-much-more-p...
- marcodiego 5y ago
  Not blob-free. Imx8 needs blobs to train RAM. There probably other blobs too.
- r283492 5y ago
  It has one tiny blob for ram initialization, people are looking into removing it. It may become RYF certified. Freedom wise, it is the best modern laptop.
  - marcodiego 5y ago
    Better than the pinebook pro?
    - r283492 5y ago
      Yes. Pinebook pro has one or more other blobs and they are for more significant functionality.
      - marcodiego 5y ago
        Hmmm... I like RK3399-based devices because they need very few blobs. Would you mind to list which blobs the pinebook pro needs?
        floatingatoll 5y ago
        https://forum.pine64.org/showthread.php?pid=97828 https://forum.pine64.org/showthread.php?pid=97828 The above link contains the answers applicable to your question.
pabs3 5y ago
Some open firmware resources: https://wiki.debian.org/Firmware/Open https://wiki.debian.org/Firmware/Open
r283492 5y ago
About the microcode: the argument is basically "It is good nonfree software, just give up and accept it." Sorry? This is FSF. And no, it is not always good: https://www.theregister.com/2018/08/21/intel_cpu_patch_licence/ https://www.theregister.com/2018/08/21/intel_cpu_patch_licen..., and when people don't accept it, https://www.theregister.com/2018/08/23/intel_microcode_license/ https://www.theregister.com/2018/08/23/intel_microcode_licen.... If a majority of intel's customers said: sorry, we'll find other solutions rather than accepting your nonfree license, intel would freely license it. > In other words, you can’t microcode update a CPU to add or substantially change capabilities. There is CCC security presentation floating around where someone reversed engineered microcode before it was signed, and designed a backdoor into it, a remote code execution triggered by going to a specific webpage. That is a substantial capability that exists in todays microcode.
- marcan_42 5y ago
  > It is good nonfree software, just give up and accept it. You already accepted it when you bought the CPU and it came with the base version. Your choices are to install a bugfix, or not. The FSF advocates for not installing the bugfix, or even informing users of the possibility of doing so. That is utterly illogical. There is no reason whatsoever to run broken proprietary software over fixed proprietary software.
  - r283492 5y ago
    > You already accepted it when you bought the CPU and it came with the base version. No, that is a version you can't physically modify. The other version is one you can't modify because of it's license and signature verification. You are simply ignoring important differences, like saying an elevator is no different than a flight of stairs, they both get you up, and anyone who avoids elevators must be an idiot.
    - marcan_42 5y ago
      ... but you can modify the base version. That's how microcode updates work, they patch it (via a patch register CAM). Are you trying to argue that the physical mechanism used for patching matters? That's an implementation detail, it has nothing to do with freedom. Your CPU comes with patchable proprietary software. Period.
ineedasername 5y ago
Is RYF certification a significant market force among users who want more open devices? I don't really follow it closely enough to know, but I checked in on the Librem 5 project periodically and this is the first I heard about RYF certification for the project, or the implication that it would be a significant driver of customer behavior. Is my outsiders impression of this niche incorrect?
- boomboomsubban 5y ago
  I think if a reasonable product actually got RYF certification it would attract a lot of people who have so far just accepted that an open device isn't happening and compromises need to be made. Basically I don't check RYF certification before buying a product, but if I heard of one getting it I'd be interested in it.
- marcodiego 5y ago
  Personally, I'd love to have a certified device. I'd like to support the cause because I fear my devices can became as locked down as smartphones and video game consoles. People may mock now, but the trend with regard to DRM, IME and others make me consider "the right to read" as not mere fiction
jeppesen-io 5y ago
FSF's hardline attitude has always rubbed me the wrong way. I respect and support their goals but at the end of the day software should respect the needs and desires of their users I saw this on the nonguix repo for all non free software for guix > Please do NOT promote this repository on any official Guix communication channels, such as their mailing lists or IRC channel, even in response to support requests! This is to show respect for the Guix project’s strict policy against recommending nonfree software, and to avoid any unnecessary hostility. To do my job and boot my laptop nonguix is required but not even allowed to talk about it with the OS it intends to support, is not something I can agree with I think the above is the type of side-effects seen with a hardline policy of the FSF. Obviously I'm not the target of this type of policy, but I still feel more good can be done in the long run with a little compromise to the realities of using a computer today
- marcodiego 5y ago
  I understand your position, but it would be better if the compromise was made by "the other side".
  - jeppesen-io 5y ago
    Oh, sure, that would be preferred but I can't see that happening anytime soon. I guess it all depends on whether you feel like the FSFs polices will bring improvement for open blobs etc
  - seanhunter 5y ago
    Everyone always thinks it would be better if the compromise was made by the other side, don't they? What you're describing is just a concession. A compromise is where neither side quite gets everything they want and both have to give a little.
    - YEwSdObPQT 5y ago
      The otherside in this case is selling you a thing and in some cases restricting you what you can and can't do with the hardware you bought. Which means you don't really own it. We have given them money. They should let us use our hardware as we see fit. In the case of nvidia literally detecting certain workloads and deliberately reducing the performance. Whether you think Crypto mining should be a thing or not, they purchased the hardware legally and should be able to use it as they see fit (as long as it is not illegal). With AMD GPUs it literally doesn't make anysense. They've released millions of lines of code to the Linux kernel so their GPUs work correctly with Linux and then I have to download a proprietary firmware for my card to initialise properly. Is the firmware really that secret? I doubt it.
BrS96bVxXBLzf5B 5y ago
Attending an RMS talk at a university ~8 years ago, some (increasingly irritated) lecturers questioned him on the use of proprietary graphics drivers in image processing for use in medical equipment and research. While RMS argued his absolute stance that proprietary drivers are never permissible, the lecturers argued that the drivers were literally saving lives and people would die without them. "They should die for the cause." Harm isn't very present on the FSF priority list.
- r283492 5y ago
  If you try to pin down someone on the fly who is publicly advocating for something on what exceptions are ok, expect them to be stubborn. But there is a lot of pragmatism at work. It's why we have the LGPL, GPL, and AGPL. https://www.gnu.org/philosophy/pragmatic.en.html https://www.gnu.org/philosophy/pragmatic.en.html
  - marcan_42 5y ago
    Ah yes, the AGPL. The license that wants to be an EULA (because that's the only way you can actually close the SaaS loophole), but can't, because being an EULA would be against the FSF's core values (Freeedom Zero), so instead it's a cute hack that is trivial to work around if you want to, while simultaneously being almost impossible to comply with for regular developers. And then the FSF plays it like it has EULA powers and makes everyone believe it is useful and harmless to the free software ecosystem. Let's break down this amazing license: > 9. Acceptance Not Required for Having Copies. > > You are not required to accept this License in order to receive or run a copy of the Program. So it's not an EULA. Cool. You can freely run the program as long as you don't modify it. Freedom Zero. > Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so. But if you touch the code, you'd better comply with the License. Great. (These clauses are identical to the GPLv3). Now the magic AGPL clause. Brace for it, and read it very carefully: > 13. Remote Network Interaction; Use with the GNU General Public License. > Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. Let's break it down: > If you modify the Program That is if you are a developer making changes to the source code (or binary, but let's ignore that option) > your modified version The modified source code you have created > must prominently offer all users interacting with it remotely through a computer network Must include the mandatory feature of offering all users interacting with it through a computer network (computer network is left undefined and subject to wide interpretation) > an opportunity to receive the Corresponding Source of your version A direct copy of the source code you have just modified > from a network server Directly from a server, without any human involved (the rest of the statement is irrelevant). Let's say I am Amazon, and I want to SaaS some AGPL software. How about this: Step 1: Put it in an internal Git repo (No license implication yet, no changes made) Step 2: Make that Git repo accessible externally with a specific URL or access key (so it is not guessable) (Clause 9 plus plain redistribution, no modifications, no problem) Step 3: Modify the software to include a link to that Git repo including the secret key (invokes and is fully compliant with Clause 13) with every response Step 4: Deploy that software on their internal network (Freedom Zero, invokes Clause 9 during deployment, no extra requirements) Step 5: Stick a reverse proxy in front that deletes the source code offer (No license implication, does not modify the AGPL software in any way, see Clause 9) Step 6: Profit Turns out you have to pick one: either control what people do with your software (which makes your license into a non-free EULA), or don't (which means there is no way for you to control any interaction people have with the software). You can't have it both ways. I know what you're saying: "But a judge would see right through this trick! Amazon is both modifying the code and setting up the reverse proxy!" Great, then just have different entities do each part. Each part, on its own, is unambiguously not in violation of the license; the developing party is only responsible for including the source code offer, and the running party has no responsibility that it actually reach users if they don't touch the code. Now your license defense relies on proving collusion. Good luck with that if the people involved were careful enough not to write down their evil plans anywhere. Heck, this situation could easily happen semi-organically - a reverse proxy doesn't have to be designed to explicitly remove the source code offer, it could merely be a protocol translator/wrapper that has no support for that specific message/tag, which is something that happens all the time. Now let's say I am a regular developer of AGPL software and I want to work on it like any other open source project. Step 1: Clone the GitHub repo Step 2: Make a change to the code - oops, license violation! Clause 13! I need to change the source code offer first! Step 1.5: Change the source code offer to point to your repo Step 2: Make a change to the code and push it Step 3: Open a pull request with your change Your change includes the source code offer commit in the history, and cannot be auto-merged. Any AGPL project accepting pull requests from third parties (or even their own developers, if there is no copyright assignment and each developer retains their own copyright) is accepting that everyone is repeatedly violating the AGPL as part of the normal development process, if they're using the GitHub flow and the source code links were not updated in the branches to be merged. Note that the license doesn't even say anything about Clause 13 being restricted to redistribution or execution or deployment to external users. Merely downloading some AGPL software and changing some code locally is an instant license violation, if you haven't previously made that version accessible and changed the source code offer. Somehow. I don't know. The whole thing is crazy. It's setting rules for mandatory features that must be implemented in the code. It's not a Freedom Zero violation, but it's a Freedom 1 violation instead: The freedom to study how the program works, and change it to make it do what you wish. AGPL Clause 13 restricts how you are allowed to change programs. As far as I can tell, there is precisely one kind of open source project that could conceivably benefit from the AGPL without being an undue burden on developers and a danger to users: Web apps with nontrivial amounts of JS source code (which would be covered under the license), with the source code offer in that code (so it cannot be removed without invoking the license, even by an automated process, maybe, hopefully a judge would see it that way), and a source code offer mechanism that has the app read its own source code from the live copy, so that no updates to the URL need to happen for different forks. Anything else, and it's just a terrible license. But the FSF will tell you it's amazing and fixes the SaaS loophole, because they've long since given up on actually being honest and just want to have their cake and eat it too, even when it just isn't possible.
koprulusector 5y ago
I’m confused. Who’s the target audience of this post? Anyone strictly adhering to FSF recommendations is most likely not a for profit business, and therefore probably doesn’t give a care about spectre or meltdown, for example. I for one add mitigations=off to all my personal systems boot flags.
- marcodiego 5y ago
  Although small, FLOSS supporters are severely underserved. I think it is possible to use the certification as a means to profit. Even if only for a few products or to get a good image among a faithful group. The sites listed selling ryf-certified devices are certainly benefitting commercially from that.
  - jimmyvalmer 5y ago
    FLOSS supporters are severely underserved I'd say the invisible hand is getting it right here. FLOSS advocates are the worst kind of customer -- both frugal and sententious.
    - marcodiego 5y ago
      FLOSS advocates are the best kind of customer -- both loyal and proud.
yellowapple 5y ago
Not only does the FSF object to the inclusion of nonfree firmware, but it also objects to even so much as making it available. Case study here would be OpenBSD, which is about as free of an operating system as it gets, and which does not ship with nonfree firmware by default. However, because of the existence of the `fw_update` command (which - by the explicit consent of the user/owner of the machine - fetches any nonfree firmware necessary for the hardware on one's system), OpenBSD doesn't qualify for the FSF's endorsement. The FSF's stance here also impacts the "ports" trees of various BSDs and (GNU/)Linuxen; if they so much as include instructions for compiling and installing nonfree software (regardless of whether they actually include nonfree software), the FSF considers the whole OS nonfree. Same deal with any (GNU/)Linux distro that maintains a nonfree repo - even if that repo is disabled by default. The rationale for these sorts of stances is that even so much as making nonfree software available for installation is an "endorsement" of that software. In spite of that rationale, the FSF maintains officially-sanctioned precompiled ports of software like GIMP for nonfree operating systems like Windows and macOS - because apparently it's okay to endorse those nonfree operating systems, because reasons.
- ziml77 5y ago
  They explicitly rationalize the Windows builds of Emacs, so I can only assume that's the same rationale as for any other GNU software > To improve the use of proprietary systems is a misguided goal. Our aim, rather, is to eliminate them. We include support for some proprietary systems in GNU Emacs in the hope that running Emacs on them will give users a taste of freedom and thus lead them to free themselves. Taken from https://www.gnu.org/software/emacs/download.html https://www.gnu.org/software/emacs/download.html
  - jimmyvalmer 5y ago
    We include support for some proprietary systems in GNU Emacs in the hope that running Emacs on them will give users a taste of freedom The weakness of this sauce is staggering. I understand GNU Emacs wanting to preserve forty years of hard work supporting Windows and MacOS, but justifying it via the "taste of freedom" sets off my hypocrisy alarm. It's also just patently false because emacs users stick with Windows precisely because emacs still works there.
aragilar 5y ago
The author seems to limit their analysis to laptops. As far as I know, desktop/server class hardware does have reasonable options like those from Raptor Engineering (such as Talos: https://www.raptorengineering.com/TALOS/talos_comparison.php https://www.raptorengineering.com/TALOS/talos_comparison.php), though I could be wrong. Could this more of an issue relating to how laptops/phones are built/marketed/sold compared with desktops/servers (and given those effects, building a free-software-based laptop/phone is practically impossible given the lack of possible components)?
- marcan_42 5y ago
  Indeed, the Raptor systems are about as free as you can get for a desktop system, as far as I can tell. I was particularly impressed when they pointed me at the source code for their RAM training routine; that one has been a sticking point in many other systems. They still aren't 100% free because that is impossible; there is no clear line to be drawn between hardware and software, and the hardware isn't free. But at least we can truthfully say they have no nonfree mutable blobs or large ROMs, and even some critical small ROM blobs are documented and open source, like the CPU boot ROM. (We can't say there are no nonfree ROM blobs - I guarantee there's a small CPU running nonfree ROM code somewhere in an IC on the board and they just don't know about it, because manufacturers do that all the time - and besides, even if their systems somehow avoid that, your monitor, keyboard, and mouse will all have that problem).
throwaway81523 5y ago
I had a discussion similar to this with RMS a while back and he seemed to think that the x86 and ARM architectures were completely hopeless for this because of the management engines etc. At that time there were credible attempts to build completely blob-free POWER9 systems, so Ifigured that was the thing to get once they got a bit more affordable. I don't think the Talos stuff ended up blob free, but it is way less blobby than x86 stuff. Maybe there is hope of blobless RISC-V systems some day.
- floatboth 5y ago
  Most processors with Arm cores do not have "management engines", in fact lots are almost blob-free. Some like Marvell Armada 7k/8k can run without any blobs.
- fitzsim 5y ago
  The Talos II is blob-free. At launch, proprietary binary-only firmware was required for the network interface, but Raptor Computing Systems offered a bounty to reverse engineer and do a Free Software re-implementation of the firmware, and that effort succeeded and the bounty was paid. See: https://wiki.raptorcs.com/wiki/Project_Ortega https://wiki.raptorcs.com/wiki/Project_Ortega https://github.com/meklort/bcm5719-fw https://github.com/meklort/bcm5719-fw
deknos 5y ago
people have opinions. more news at 11. sorry, but i think the FSF is totally justified. the ME engine and stuff like that showed that the industry does not have the best interest of customers (business and endusers alike) at heart and will fuck them over for more money. and then the whining here is great again and it's like "Stallman was right" and at the next turn "but ma feetures" complaints come around, because it costs more money or time which also would be the ethical thing to do often enough
guilhas 5y ago
In terms of security and stability I think FSF view is correct Although I think they could have a second tier, more relaxed for Debian, NixOS and others, that exclude nonfree software/firmware but allows you to enable it. But in general I think it is commendable that they have been able preserve their values and not dilute and disappear When I buy my hardware I make sure it is compatible, stable and won't have many issues with Libre Linux, even thing like swapping the wireless card to a compatible one And this has been the rule also for all Linux users. You want to make sure you have a smooth experience, you will have to check for hardware recommendations. Want fingerprint working? Better be sure before you buy Regarding security most Libre people are not serving cloud services in their computers, and install only open source. So the microcode security mitigations like, spectre and meltdown, are mostly unnecessary. Also browsers and kernels have been patched for it anyway When I configure a server I will probably majorally never upgrade it, because it will always cause problems, sometimes small, other times big headaches. I would sooner configure a new one and migrate things slowly If one microcode update is enough to fix your system is also enough to break it: Intel to disable TSX by default on more CPUs with new microcode https://news.ycombinator.com/item?id=27664856 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
spacexsucks 5y ago
No. The hardware industry's relationship with the user owning their own devices is harmful.
jimmyvalmer 5y ago
There's a ton of expertise being bandied about here. It's sad any of it is being directed towards sophistic, quasi-religious debate.
toolcombinator 5y ago
The central problem here, is that RYF, just like the FSF itself, is outdated and hasn’t been relevant for a decade or more. It’s a dinosaur from another era with its hypocritical RAM vs ROM policies, or “secondary processor” loopholes. It assumes that there’s one Central processor in charge, something that hasn’t been true for a very long time. Which parts of an SOC is central? The CPU? Great. Modern CPUs are multicore chips, so which one are central and which one are secondary?

170 points by meithecatte 5y ago

Properly isolated accessory non-free hardware is a good thing, and for a user whose threat model requires libre hardware, the security model of the PinePhone or Librem 5 where the LTE modem is isolated with a kill switch to interact via USB (rather than connected via PCIe, which would have direct memory access) is the right choice. Is a Thinkpad T400 with a Core2Duo and SSD the right choice in 2022? What about a Pinebook Pro? Friends and acquaintances I know are using these computers as their primary devices today.

cjbprime 5y ago
Agree with you, but a quick clarification: PCIe IOMMUs exist now, a PCIe device doesn't get DMA access to main memory.
marcan_42 5y ago
FYI, that ThinkPad T400 that the FSF certified has multiple microcontrollers running proprietary updatable blobs on the LPC bus with full access to DMA to all of system memory. I am literally more insulated from blobs with an Apple M1, which runs a dozen blobs none of which can take over my OS (thanks to pervasive IOMMU use), than with hardware that the FSF claims "respects my freedom".

MathMonkeyMan 5y ago

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

cmeacham98 5y ago
> Why accuse the FSF of hypocrisy? I'm not sure I fully agree with the author, but I think their point is that the FSF makes exceptions for binary blobs in some places because of usability, but then denies similar exceptions elsewhere because they're not libre. The complaint is that the decision on what counts as being included in the loopholes appears largely arbitrary, at least from an outsider's perspective.
- throwaway81523 5y ago
  Is that hypocrisy, or just an oversight / unintended consequence?
- medo-bear 5y ago
  last time i looked at their guidelines i understood it that proprietry blobs will be tolerated as long as libre alternatives dont exist. for an organisation that values free software above all else (including security) i think this is a principled approach. i fail to see any hypocricy on the other hand whenever there is some GNU/FSF topic on hn there are always the same people taking the opportunity to throw mud at these organisations. think of this what you will
giantrobot 5y ago
> Why accuse the FSF of hypocrisy? If I ship some piece of hardware on a PC with its firmware burned into a ROM and do not provide the source (a binary blob), the FSF will happily say my hardware is RYF-certified. If I ship the exact same hardware with the exact same firmware as a binary blob but in Flash RAM or loaded at init by a driver they'll accuse me of not "respecting freedom". Same hardware. Same firmware. Same vendor. The FSF is hypocritical because their RYF certification allows me to get certified so long as I make my hardware impossible to update. I don't have to provide any source or actually respect anyone's freedom to get in their good graces, I just need to burn my binary blob into a ROM. If I save a dollar per unit by loading the same firmware blob through a driver into the device's RAM, I'm an evil freedom disrespecting jerk. Besides being hypocritical it also makes for extremely poor security practice and affects longevity and e-waste. If I can't update a device firmware it might have some security flaw that can't be patched and maintain the RYF certification. If I roll an updated firmware and have the driver push it to the device I lose my previous certification unless the new blob is open sourced. Devices that can't be updated are also more likely to be discarded. An updated OS might be incompatible with my old firmware in ROM so needs to be tossed when upgrading. Same if a security fix can't be pushed out. So the FSF doesn't seem to actually care about freedoms, just whether a vendor technically meets their requirements. They also engender a poor security posture with their policy. Libre hardware is a worthy goal but the FSF's policies and technicalities around certification don't really lead to that goal.

roenxi 5y ago

> ...In other words, you can’t microcode update a CPU to add or substantially change capabilities... > ... vulnerabilities such as Meltdown and Spectre, which were partially mitigated through a microcode update ... Of these two snippets, only one can be true. Either opaque microcode updates can substantially change how a system performs, or they can't. These mitigations are major changes to how the processor works. This post looks to me like a fairly typical "doesn't quite get what they mean by freedom" take, of which there are many (which is cool, freedom isn't everyone's cup of tea). The FSF has been quite consistent that if there is a choice to be made, the user should have a practical way of making that choice. If the manufacturer can change how a CPU works with a microcode update, the user should be able to as well. The FSF has a clear role here. Their job is to say "this software is free, this software is not". People constantly call on them to compromise on that role in the name of security/convenience/helpfulness/strategic adoption concerns/the impractical nature of their stance. The FSF should and does ignore those people. They are a (slightly quirky, yes) moral lighthouse more than an adoption friendly technical project. This microcode is not free software and someone should be pointing that out and complaining about it. If the FSF isn't taking a stand against non-free microcode, who will?

garaetjjte 5y ago
Yet they are fine with running microcode as long you don't update it. It doesn't make sense. Blobs don't disappear just because they are hidden in ROM.
- DarylZero 5y ago
  Apparently it's OK because both the vendor and the user are prevented from updating it. Thus there's no power differential between them on that specific point.
- TT-392 5y ago
  That one kinda makes sense, because, when you can't update it, there isn't really much of a practical difference between something implemented in hardware or firmware. So not allowing blobs in rom would almost be hypocritical if you don't also mandate that the actual silicon of the chip is completely free.

jeroenhd 5y ago

I think the ideology of the FSF is a perfectly fine one. It's the hardware vendors that insist on binary blobs that are the problem here. Nobody produces truly free consumer hardware and nobody has produced any for years now. Everything is hidden away because of fears of patent lawsuits and other people copying this One Neat Trick when initializing the devices. Intel would lose very little if it published the source code for the blobs loaded into their processors, because the signature requirements prevent anyone else from developing their own microcode, yet it still encrypts and obfuscates the compiled code. The same is true for most chip and UEFI suppliers. I hope riscv will soon take off in a way that foregoes all of these blobs, though I highly doubt it since modern hardware is encumbered by patents and secrets. It's a sad reality that free, libre computers do not exist and blaming the FSF for having high standards is the wrong approach.

kryptiskt 5y ago
> I think the ideology of the FSF is a perfectly fine one. It's the hardware vendors that insist on binary blobs that are the problem here. Their ideology has led them into preferring proprietary firmware that is inaccessible to the user like in the Purism example. I hate that, there is hope that a device that requires binary blobs from the main OS can be reverse engineered and free software developed for it. Making it inaccessible to tinkering is strictly worse for the user in all respects.
- marcodiego 5y ago
  People are parroting "the purism example...". Just stop it! Librem-5 is NOT certified!
  - marcan_42 5y ago
    But they want to be certified, and the hilarious RAM initialization workaround was absolutely done as part of trying to get certified.
    - smitop 5y ago

deleted 5y ago

[deleted]

marcodiego 5y ago

I've got the feeling the author has read my comment: https://news.ycombinator.com/item?id=30036588 https://news.ycombinator.com/item?id=30036588 What is said about librem5 is irrelevant: it is not certified. What is said about gaming the certification is irrelevant: no currently certified devices does it. There are modern certified devices: Talos motherboards. There are no modern laptops certified? Blame the vendors. OK, this may not make them change their mind, but while we are not fully independent, I see no other way.

basilgohar 5y ago

Very few people or organizations willingly give up control. The whole reason of using copyright law to "enforce" freedom by preventing free software from becoming unfree was because of how much the current legal framework around imaginary property is stacked against a libre approach. So, it's a tough game to play, but FSF didn't achieve what it has thus far by being soft or compromising. Substantial change with hostile parties doesn't happen by constantly yielding.

anjbe 5y ago
Since hardware vendors by and large ignore RYF certification and the FSF’s opinions in general, it’s hardly “yielding” for the FSF to change its policies if the existing policies are harmful to the free software community. The people who are most vocal about FSF’s incorrect views on firmware are those who themselves are bringing free operating systems to new hardware, writing drivers, and reverse engineering hardware and firmware. They are not hostile parties—their contributions are among the most important to free software today, and their opinions should hold more weight.

someoneelse9 5y ago

A 2009 thinkpad is rather capable of being a daily driver for most people. Saying otherwise, you're only contributing to the growing problem of ewaste. Even the T60 offers a decent performance if your usecase is browsing the web, mail and other simple tasks. The FSF might be wrong in some aspects but there's no real alternative to Libreboot. The Framework laptop is not free software friendly. Even if it was corebooted, it would require many proprietary blobs and it's highly unlikely, if not impossible, that they will be ever able to remove the Intel ME. There are other options that are nearer to be completely free (as in freedom) hardware, eg the Pinebook Pro. I'm unsure if there are any proprietary blobs required to boot it tho, but the lack of Intel ME makes it a much better candidate for a new generation of 'libre' hardware.

marcan_42 5y ago
That 2009 ThinkPad that the FSF certified is running proprietary blobs in updatable microcontrollers connected to the LPC bus which have full access to RAM and to take over the OS. Blobs which you can't audit, modify, sandbox, nor verify are the correct intended version. I'd rather buy an M1; sure, it runs a pile of blobs, but at least I know those blobs are there and they're all sandboxed behind IOMMUs and cannot take over or compromise my OS.
na85 5y ago
>Even the T60 offers a decent performance if your usecase is browsing the web, I actually own a T60 and this is not true, for any reasonable definition of "decent". The web is a horrid wasteland of poor performance JavaScript. Forget running any Electron apps (a necessity it seems in this day of Zoom and MS Teams).
YEwSdObPQT 5y ago
That hardware is 13 years old now and laptops tend to start falling apart and spares become difficult to source. I have a Dell E6410 laptop. Which is really easy to repair and built like a tank. Keyboard has started dying and there are no replacement keyboards on ebay that are UK. You are asking people to use things that are quite out of date and may not be easily repairable. I've got desktop machines from 2007 that I've had to replace the motherboard (wasn't worth it really) because capacitors had started bulging (and it was a board from a well known manufacturer). It probably more capable than the machines you mention but it was unstable as the parts were literally disintegrating. > Even the T60 offers a decent performance if your usecase is browsing the web, mail and other simple tasks. I really get annoyed by this. "If your tasks are restricted to a very small subset of what I think a basic user actually might want to use your computer for this will be okay". What happens when someone needs to use more modern software (even for one off thing like a job interview over a video conference), or use a particular site for taxes or whatever that needs a more modern hardware. They are screwed. I have an Amiga 1200 with an accelerator card and technically I can use the web, check mail, chat (IRC basically) and do 85% of what I do online. But for the other 15% it is a total non-option and that other 15% might be what pays my bills.

Avamander 5y ago

This discussion all seems to boil down to the semantics of what's "firmware", what's "software" and what's "hardware". Considering how blurred the line really is between the three, the feud seems pedantic at best. FSF should stick to software only, learn to see shades of grey and label hardware accordingly or reject anything that isn't open until silicon (silicon excluded). Current choice is half-baked.

inshadows 5y ago

LeFantome 5y ago

irfwashere 5y ago

If you'll forgive my naivete here I've been thinking a lot about the FSF philosophy and wanted to ask HN: how big of a project would it be to create a fully libre (whatever you want to call you it) laptop? Like how feasible is it to use "free" components put together into a package and what kind of budget would be required? I think China has a few companies working on domestic processors. Let's say they are convinced by Stallman's charisma to make chips that are not cutting edge but decent, and libre. Whatever your thoughts are on China but I would suggest to the FSF to slowly move in that direction. Where all the component schematics are open and viewable. At least to go for auditability since no one trusts the Chinese. Like I said, forgive the naivete, but it feels like a noble yet lofty goal. And then proceed to go into every industry with right to repair issues. Deere tractor competitors, home appliances, and so on. In the name of component longevity and repairability. All of this to repudiate forced obsolescence and to promote end user freedoms. It's a stretch but I enjoy dreaming about it. Hoping a better world is possible.

deleted 5y ago
[deleted]
marcan_42 5y ago
That "libre" gives you auditability is a common myth believed by those pushing for libre hardware. The reality is you can't audit silicon, because it's a destructive process requiring extremely expensive analysis equipment. You always have to trust the chip manufacturer; doesn't matter how documented the chip design is, even if the masks are outright public. You can never know that your CPU is not backdoored. That's just a physical reality. There is one exception: FPGAs, under the premise that "generically" backdooring an FPGA is computationally infeasible. That's how Precursor gets to seriously claim trustability. https://www.crowdsupply.com/sutajio-kosagi/precursor 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.
- DarylZero 5y ago
  You can still backdoor a FPGA in the style of Reflections on Trusting Trust... wait for known code to be installed into the FPGA and then patch it.

jancsika 5y ago

Anyone know if the mnt reform laptop is blob-less? https://mntre.com/media/reform_md/2020-05-08-the-much-more-personal-computer.html https://mntre.com/media/reform_md/2020-05-08-the-much-more-p...

marcodiego 5y ago
Not blob-free. Imx8 needs blobs to train RAM. There probably other blobs too.
r283492 5y ago
It has one tiny blob for ram initialization, people are looking into removing it. It may become RYF certified. Freedom wise, it is the best modern laptop.
- marcodiego 5y ago
  Better than the pinebook pro?
  - r283492 5y ago
    Yes. Pinebook pro has one or more other blobs and they are for more significant functionality.
    - marcodiego 5y ago
      Hmmm... I like RK3399-based devices because they need very few blobs. Would you mind to list which blobs the pinebook pro needs?
      - floatingatoll 5y ago
        https://forum.pine64.org/showthread.php?pid=97828 https://forum.pine64.org/showthread.php?pid=97828 The above link contains the answers applicable to your question.

pabs3 5y ago

Some open firmware resources: https://wiki.debian.org/Firmware/Open https://wiki.debian.org/Firmware/Open

r283492 5y ago

About the microcode: the argument is basically "It is good nonfree software, just give up and accept it." Sorry? This is FSF. And no, it is not always good: https://www.theregister.com/2018/08/21/intel_cpu_patch_licence/ https://www.theregister.com/2018/08/21/intel_cpu_patch_licen..., and when people don't accept it, https://www.theregister.com/2018/08/23/intel_microcode_license/ https://www.theregister.com/2018/08/23/intel_microcode_licen.... If a majority of intel's customers said: sorry, we'll find other solutions rather than accepting your nonfree license, intel would freely license it. > In other words, you can’t microcode update a CPU to add or substantially change capabilities. There is CCC security presentation floating around where someone reversed engineered microcode before it was signed, and designed a backdoor into it, a remote code execution triggered by going to a specific webpage. That is a substantial capability that exists in todays microcode.

marcan_42 5y ago
> It is good nonfree software, just give up and accept it. You already accepted it when you bought the CPU and it came with the base version. Your choices are to install a bugfix, or not. The FSF advocates for not installing the bugfix, or even informing users of the possibility of doing so. That is utterly illogical. There is no reason whatsoever to run broken proprietary software over fixed proprietary software.
- r283492 5y ago
  > You already accepted it when you bought the CPU and it came with the base version. No, that is a version you can't physically modify. The other version is one you can't modify because of it's license and signature verification. You are simply ignoring important differences, like saying an elevator is no different than a flight of stairs, they both get you up, and anyone who avoids elevators must be an idiot.
  - marcan_42 5y ago
    ... but you can modify the base version. That's how microcode updates work, they patch it (via a patch register CAM). Are you trying to argue that the physical mechanism used for patching matters? That's an implementation detail, it has nothing to do with freedom. Your CPU comes with patchable proprietary software. Period.

ineedasername 5y ago

Is RYF certification a significant market force among users who want more open devices? I don't really follow it closely enough to know, but I checked in on the Librem 5 project periodically and this is the first I heard about RYF certification for the project, or the implication that it would be a significant driver of customer behavior. Is my outsiders impression of this niche incorrect?

boomboomsubban 5y ago
I think if a reasonable product actually got RYF certification it would attract a lot of people who have so far just accepted that an open device isn't happening and compromises need to be made. Basically I don't check RYF certification before buying a product, but if I heard of one getting it I'd be interested in it.
marcodiego 5y ago
Personally, I'd love to have a certified device. I'd like to support the cause because I fear my devices can became as locked down as smartphones and video game consoles. People may mock now, but the trend with regard to DRM, IME and others make me consider "the right to read" as not mere fiction

jeppesen-io 5y ago

FSF's hardline attitude has always rubbed me the wrong way. I respect and support their goals but at the end of the day software should respect the needs and desires of their users I saw this on the nonguix repo for all non free software for guix > Please do NOT promote this repository on any official Guix communication channels, such as their mailing lists or IRC channel, even in response to support requests! This is to show respect for the Guix project’s strict policy against recommending nonfree software, and to avoid any unnecessary hostility. To do my job and boot my laptop nonguix is required but not even allowed to talk about it with the OS it intends to support, is not something I can agree with I think the above is the type of side-effects seen with a hardline policy of the FSF. Obviously I'm not the target of this type of policy, but I still feel more good can be done in the long run with a little compromise to the realities of using a computer today

marcodiego 5y ago
I understand your position, but it would be better if the compromise was made by "the other side".
- jeppesen-io 5y ago
  Oh, sure, that would be preferred but I can't see that happening anytime soon. I guess it all depends on whether you feel like the FSFs polices will bring improvement for open blobs etc
- seanhunter 5y ago
  Everyone always thinks it would be better if the compromise was made by the other side, don't they? What you're describing is just a concession. A compromise is where neither side quite gets everything they want and both have to give a little.
  - YEwSdObPQT 5y ago
    The otherside in this case is selling you a thing and in some cases restricting you what you can and can't do with the hardware you bought. Which means you don't really own it. We have given them money. They should let us use our hardware as we see fit. In the case of nvidia literally detecting certain workloads and deliberately reducing the performance. Whether you think Crypto mining should be a thing or not, they purchased the hardware legally and should be able to use it as they see fit (as long as it is not illegal). With AMD GPUs it literally doesn't make anysense. They've released millions of lines of code to the Linux kernel so their GPUs work correctly with Linux and then I have to download a proprietary firmware for my card to initialise properly. Is the firmware really that secret? I doubt it.

BrS96bVxXBLzf5B 5y ago

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

r283492 5y ago
If you try to pin down someone on the fly who is publicly advocating for something on what exceptions are ok, expect them to be stubborn. But there is a lot of pragmatism at work. It's why we have the LGPL, GPL, and AGPL. https://www.gnu.org/philosophy/pragmatic.en.html https://www.gnu.org/philosophy/pragmatic.en.html
- marcan_42 5y ago
  Ah yes, the AGPL. The license that wants to be an EULA (because that's the only way you can actually close the SaaS loophole), but can't, because being an EULA would be against the FSF's core values (Freeedom Zero), so instead it's a cute hack that is trivial to work around if you want to, while simultaneously being almost impossible to comply with for regular developers. And then the FSF plays it like it has EULA powers and makes everyone believe it is useful and harmless to the free software ecosystem. Let's break down this amazing license: > 9. Acceptance Not Required for Having Copies. > > You are not required to accept this License in order to receive or run a copy of the Program. So it's not an EULA. Cool. You can freely run the program as long as you don't modify it. Freedom Zero. > Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so. But if you touch the code, you'd better comply with the License. Great. (These clauses are identical to the GPLv3). Now the magic AGPL clause. Brace for it, and read it very carefully: > 13. Remote Network Interaction; Use with the GNU General Public License. > Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. Let's break it down: > If you modify the Program That is if you are a developer making changes to the source code (or binary, but let's ignore that option) > your modified version The modified source code you have created > must prominently offer all users interacting with it remotely through a computer network Must include the mandatory feature of offering all users interacting with it through a computer network (computer network is left undefined and subject to wide interpretation) > an opportunity to receive the Corresponding Source of your version A direct copy of the source code you have just modified > from a network server Directly from a server, without any human involved (the rest of the statement is irrelevant). Let's say I am Amazon, and I want to SaaS some AGPL software. How about this: Step 1: Put it in an internal Git repo (No license implication yet, no changes made) Step 2: Make that Git repo accessible externally with a specific URL or access key (so it is not guessable) (Clause 9 plus plain redistribution, no modifications, no problem) Step 3: Modify the software to include a link to that Git repo including the secret key (invokes and is fully compliant with Clause 13) with every response Step 4: Deploy that software on their internal network (Freedom Zero, invokes Clause 9 during deployment, no extra requirements) Step 5: Stick a reverse proxy in front that deletes the source code offer (No license implication, does not modify the AGPL software in any way, see Clause 9) Step 6: Profit Turns out you have to pick one: either control what people do with your software (which makes your license into a non-free EULA), or don't (which means there is no way for you to control any interaction people have with the software). You can't have it both ways. I know what you're saying: "But a judge would see right through this trick! Amazon is both modifying the code and setting up the reverse proxy!" Great, then just have different entities do each part. Each part, on its own, is unambiguously not in violation of the license; the developing party is only responsible for including the source code offer, and the running party has no responsibility that it actually reach users if they don't touch the code. Now your license defense relies on proving collusion. Good luck with that if the people involved were careful enough not to write down their evil plans anywhere. Heck, this situation could easily happen semi-organically - a reverse proxy doesn't have to be designed to explicitly remove the source code offer, it could merely be a protocol translator/wrapper that has no support for that specific message/tag, which is something that happens all the time. Now let's say I am a regular developer of AGPL software and I want to work on it like any other open source project. Step 1: Clone the GitHub repo Step 2: Make a change to the code - oops, license violation! Clause 13! I need to change the source code offer first! Step 1.5: Change the source code offer to point to your repo Step 2: Make a change to the code and push it Step 3: Open a pull request with your change Your change includes the source code offer commit in the history, and cannot be auto-merged. Any AGPL project accepting pull requests from third parties (or even their own developers, if there is no copyright assignment and each developer retains their own copyright) is accepting that everyone is repeatedly violating the AGPL as part of the normal development process, if they're using the GitHub flow and the source code links were not updated in the branches to be merged. Note that the license doesn't even say anything about Clause 13 being restricted to redistribution or execution or deployment to external users. Merely downloading some AGPL software and changing some code locally is an instant license violation, if you haven't previously made that version accessible and changed the source code offer. Somehow. I don't know. The whole thing is crazy. It's setting rules for mandatory features that must be implemented in the code. It's not a Freedom Zero violation, but it's a Freedom 1 violation instead: The freedom to study how the program works, and change it to make it do what you wish. AGPL Clause 13 restricts how you are allowed to change programs. As far as I can tell, there is precisely one kind of open source project that could conceivably benefit from the AGPL without being an undue burden on developers and a danger to users: Web apps with nontrivial amounts of JS source code (which would be covered under the license), with the source code offer in that code (so it cannot be removed without invoking the license, even by an automated process, maybe, hopefully a judge would see it that way), and a source code offer mechanism that has the app read its own source code from the live copy, so that no updates to the URL need to happen for different forks. Anything else, and it's just a terrible license. But the FSF will tell you it's amazing and fixes the SaaS loophole, because they've long since given up on actually being honest and just want to have their cake and eat it too, even when it just isn't possible.

koprulusector 5y ago

I’m confused. Who’s the target audience of this post? Anyone strictly adhering to FSF recommendations is most likely not a for profit business, and therefore probably doesn’t give a care about spectre or meltdown, for example. I for one add mitigations=off to all my personal systems boot flags.

marcodiego 5y ago
Although small, FLOSS supporters are severely underserved. I think it is possible to use the certification as a means to profit. Even if only for a few products or to get a good image among a faithful group. The sites listed selling ryf-certified devices are certainly benefitting commercially from that.
- jimmyvalmer 5y ago
  FLOSS supporters are severely underserved I'd say the invisible hand is getting it right here. FLOSS advocates are the worst kind of customer -- both frugal and sententious.
  - marcodiego 5y ago
    FLOSS advocates are the best kind of customer -- both loyal and proud.

yellowapple 5y ago

Not only does the FSF object to the inclusion of nonfree firmware, but it also objects to even so much as making it available. Case study here would be OpenBSD, which is about as free of an operating system as it gets, and which does not ship with nonfree firmware by default. However, because of the existence of the `fw_update` command (which - by the explicit consent of the user/owner of the machine - fetches any nonfree firmware necessary for the hardware on one's system), OpenBSD doesn't qualify for the FSF's endorsement. The FSF's stance here also impacts the "ports" trees of various BSDs and (GNU/)Linuxen; if they so much as include instructions for compiling and installing nonfree software (regardless of whether they actually include nonfree software), the FSF considers the whole OS nonfree. Same deal with any (GNU/)Linux distro that maintains a nonfree repo - even if that repo is disabled by default. The rationale for these sorts of stances is that even so much as making nonfree software available for installation is an "endorsement" of that software. In spite of that rationale, the FSF maintains officially-sanctioned precompiled ports of software like GIMP for nonfree operating systems like Windows and macOS - because apparently it's okay to endorse those nonfree operating systems, because reasons.

ziml77 5y ago
They explicitly rationalize the Windows builds of Emacs, so I can only assume that's the same rationale as for any other GNU software > To improve the use of proprietary systems is a misguided goal. Our aim, rather, is to eliminate them. We include support for some proprietary systems in GNU Emacs in the hope that running Emacs on them will give users a taste of freedom and thus lead them to free themselves. Taken from https://www.gnu.org/software/emacs/download.html https://www.gnu.org/software/emacs/download.html
- jimmyvalmer 5y ago
  We include support for some proprietary systems in GNU Emacs in the hope that running Emacs on them will give users a taste of freedom The weakness of this sauce is staggering. I understand GNU Emacs wanting to preserve forty years of hard work supporting Windows and MacOS, but justifying it via the "taste of freedom" sets off my hypocrisy alarm. It's also just patently false because emacs users stick with Windows precisely because emacs still works there.

aragilar 5y ago

The author seems to limit their analysis to laptops. As far as I know, desktop/server class hardware does have reasonable options like those from Raptor Engineering (such as Talos: https://www.raptorengineering.com/TALOS/talos_comparison.php https://www.raptorengineering.com/TALOS/talos_comparison.php), though I could be wrong. Could this more of an issue relating to how laptops/phones are built/marketed/sold compared with desktops/servers (and given those effects, building a free-software-based laptop/phone is practically impossible given the lack of possible components)?

marcan_42 5y ago
Indeed, the Raptor systems are about as free as you can get for a desktop system, as far as I can tell. I was particularly impressed when they pointed me at the source code for their RAM training routine; that one has been a sticking point in many other systems. They still aren't 100% free because that is impossible; there is no clear line to be drawn between hardware and software, and the hardware isn't free. But at least we can truthfully say they have no nonfree mutable blobs or large ROMs, and even some critical small ROM blobs are documented and open source, like the CPU boot ROM. (We can't say there are no nonfree ROM blobs - I guarantee there's a small CPU running nonfree ROM code somewhere in an IC on the board and they just don't know about it, because manufacturers do that all the time - and besides, even if their systems somehow avoid that, your monitor, keyboard, and mouse will all have that problem).

throwaway81523 5y ago

I had a discussion similar to this with RMS a while back and he seemed to think that the x86 and ARM architectures were completely hopeless for this because of the management engines etc. At that time there were credible attempts to build completely blob-free POWER9 systems, so Ifigured that was the thing to get once they got a bit more affordable. I don't think the Talos stuff ended up blob free, but it is way less blobby than x86 stuff. Maybe there is hope of blobless RISC-V systems some day.

floatboth 5y ago
Most processors with Arm cores do not have "management engines", in fact lots are almost blob-free. Some like Marvell Armada 7k/8k can run without any blobs.
fitzsim 5y ago
The Talos II is blob-free. At launch, proprietary binary-only firmware was required for the network interface, but Raptor Computing Systems offered a bounty to reverse engineer and do a Free Software re-implementation of the firmware, and that effort succeeded and the bounty was paid. See: https://wiki.raptorcs.com/wiki/Project_Ortega https://wiki.raptorcs.com/wiki/Project_Ortega https://github.com/meklort/bcm5719-fw https://github.com/meklort/bcm5719-fw

deknos 5y ago

people have opinions. more news at 11. sorry, but i think the FSF is totally justified. the ME engine and stuff like that showed that the industry does not have the best interest of customers (business and endusers alike) at heart and will fuck them over for more money. and then the whining here is great again and it's like "Stallman was right" and at the next turn "but ma feetures" complaints come around, because it costs more money or time which also would be the ethical thing to do often enough

guilhas 5y ago

In terms of security and stability I think FSF view is correct Although I think they could have a second tier, more relaxed for Debian, NixOS and others, that exclude nonfree software/firmware but allows you to enable it. But in general I think it is commendable that they have been able preserve their values and not dilute and disappear When I buy my hardware I make sure it is compatible, stable and won't have many issues with Libre Linux, even thing like swapping the wireless card to a compatible one And this has been the rule also for all Linux users. You want to make sure you have a smooth experience, you will have to check for hardware recommendations. Want fingerprint working? Better be sure before you buy Regarding security most Libre people are not serving cloud services in their computers, and install only open source. So the microcode security mitigations like, spectre and meltdown, are mostly unnecessary. Also browsers and kernels have been patched for it anyway When I configure a server I will probably majorally never upgrade it, because it will always cause problems, sometimes small, other times big headaches. I would sooner configure a new one and migrate things slowly If one microcode update is enough to fix your system is also enough to break it: Intel to disable TSX by default on more CPUs with new microcode https://news.ycombinator.com/item?id=27664856 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

spacexsucks 5y ago

No. The hardware industry's relationship with the user owning their own devices is harmful.

jimmyvalmer 5y ago

There's a ton of expertise being bandied about here. It's sad any of it is being directed towards sophistic, quasi-religious debate.

toolcombinator 5y ago

The central problem here, is that RYF, just like the FSF itself, is outdated and hasn’t been relevant for a decade or more. It’s a dinosaur from another era with its hypocritical RAM vs ROM policies, or “secondary processor” loopholes. It assumes that there’s one Central processor in charge, something that hasn’t been true for a very long time. Which parts of an SOC is central? The CPU? Great. Modern CPUs are multicore chips, so which one are central and which one are secondary?