everything wrong with free software
"obedience breeds foolishness"
=> an-entire-year-of-ewwfs.html an-entire-year-of-ewwfs
*originally posted:* jan 2022
readers will please let me know if i have accidentally used a legacy (binary) pronoun in this post (or future posts). i am happy to use those for myself and others who identify as male or female, but i am also a major fan of "singular they" (its just so useful) and ive made every effort to refer to leah with that pronoun at their general request.
i am a fan of the idea of ryf certification. the implementation has notable shortcomings, whether you feel it ought to be "more free" or "less free" (more strict or less so). i will try to give a fair assessment of leahs idea for osboot, and part of that fairness (or at least trying to avoid hypocrisy) will be to compare it to an idea i proposed to stallman more than a year ago.
of course the purist in me was sure to make a few hairs stand up at leahs idea, and its easy to reduce the whole thing to "this will be LESS free than the ryf requirements". in some ways thats very arguably and admittedly true. and im very cautious of anything that could turn into another bullshit open source compromise.
however, my attitude towards software freedom is at least a partially scientific one, and while i am VERY aware that open source has introduced countless and erosive compromises for the sake of compromise alone, i am aware that efforts toward purism (sorry leah, i think we have overlapping feelings about that name) as in the WORD (not the brand) at the fsf have led to some... strange compromises of their own.
since im an openbsd user, i think its also worth noting some different positions on "firmware" and blobs in general. my goal here is to properly represent these positions-- any failure to do so is due to an unfortunate misunderstanding on my part. it goes without saying that both leah and theo de raadt understand firmware on a more technical level than i do. before i get to their positions, perhaps i ought to start with my own:
i still consider "firmware", at least in the casual sense, to be any "software on a chip". this is not necessarily the best definition at all, but it goes back to the days when nand-flash was a technology i had predicted, rather than one in common consumer-grade products. the point being that firmware generally came on a rom chip which (being read-only) of course could not be altered. (my prediction of thumbdrives was based on thinking eeproms were really neat, and that floppies were both really fragile and awkward to carry in a pocket).
put a program on a chip, and its firmware-- put it on any other medium, and its software. but wait! what about a firmware image downloaded as a file? i dont know, this is why we need people like leah rowe and theo de raadt.
nonetheless, this generalisation is based (whether it should be or not) on industry terminology (or a misunderstanding of it) like the idea that your phones operating system is "firmware". isnt it just software when its on some general purpose device? this sort of thing is why im a "software person" who is a hardware person sympathiser, but do not consider myself a "hardware person". people like leah say (even in this policy):
> And actually focus on hardware, not just software!
for literally years now, ive been very passionate about this. as hardware (not just our software) becomes CLOSER to being able to give us more control of our COMPUTING, it becomes more important to advocate for this additional freedom. ryf seems to be less about that, and more about simply finding free-software-compatible hardware. this is one aspect of the ryf implementation that i find troubling, particularly in the long term. ive watched the fsf paint itself into a corner with the linux kernel, and ryf could prove to be a similar problem.
once theyve done something improperly, the fsf tends to get stuck with such errors. hardware is also starting to take on more aspects of software problems, such as the inclusion of malware in (brand new) laptops that doesnt go away when the operating system is removed and reinstalled. while i dont know of any examples of this that directly affect gnu/linux users, it should be a warning (on some level) to those watching for new threats.
im not confident the fsfs hyperfocus on licensing and software is sufficient to tackle these problems, or even give solutions their due. with their unfortunate bungling of free culture, this lack of due to DIRECTLY peripheral freedoms is a real issue to consider-- especially when the fsf starts making policies about said freedoms. though maybe they will step up later on.
these days however, even regarding software threats the fsf has been stuck on cruise control for a decade or so (since 2011) and even if these WERE purely software issues, the fsf seems unequipped.
leah is one of the few "former?" loyalists who seems to be working on serious plans to step up where others have stepped down (with no true successor) and this is why i respond to leahs ideas in a similar fashion as i would to ideas from stallman. i said more than a year ago in techrights, that "we need more stallmans". i meant people working based on similar motives and doing similar things, and NOT parrots who merely regurgitate things verbatim (something i loathe about trisquel). the latter means that anytime stallman fails to address something (or addresses it in a way that is truly unfair) the parrots will share most of these shortcomings. i will voice both misgivings and approval, where applicable. it is what honest (and perhaps scientific) advocates do.
so my definition of firmware is quite casual, perhaps even shitty and erroneous, but seems at least partly compatible with the "firmware" leah talks about (mea culpa if im indeed mistaken). lets talk about de raadts definition:
de raadts definition of firmware seems to ignore any binary blobs that dont run "on the cpu". leah may address this, but since im not a hardware person lets not muddy this conversation any more than i already have. de raadt (and openbsd in general) have a policy against blobs in the operating system that is fsf-like (i wont torture de raadt by comparing him to stallman here) in its strictness-- as someone who does not trust blobs, i strongly appreciate this.
openbsd seems to make an exception for "blobs" in "firmware" that runs exclusively on a "peripheral" (routers included? no?) that is based on the same sort of pragmatism that leahs "blob reduction" tolerates (while still trying to actively move away from) and (ive spent at least a year trying to understand this in a non-straw-man-like-fashion) seems to simply draw the line at "devices" because "lets be real, devices will never have free firmware".
and thats okay, because its not running on the cpu that openbsd is-- its running on a separate "device".
where this confuses me honestly, is that-- isnt a router actually a computer itself? didnt de raadt defend his policy regarding routers as well? because if hes talking about a "simple" peripheral like a mouse or keyboard or camera-- having a simplicity that minimisation sticks its fingers up at more and more (i believe your sdcard, which is as much of a storage medium as a device, has its own controller and firmware, which can be used for nefarious purposes amirite?) but i mean... a router is definitely a computer in its own right and can be used at one. maybe this makes sense for openbsd as an operating system, though perhaps leah would argue (most likely correctly) that its a shitty policy for hardware altogether!
"we arent here to make open source hardware, we are here to make an operating system" de raadt might reply. and i suppose thats the difference between openbsd and a movement to make all computing free-as-in-freedom. if its a question of reasonable project scope, maybe de raadt is not actually inconsistent. i believe someone giving an openbsd-related talk years ago said "WE DONT WANT [to maintain] FREE FIRMWARE". it would be outside the scope of the project, and openbsd has no ambitions to tell other projects what to do (at least until they implement shitty software that openbsd does better, but even in this regard any "proselytising" openbsd arguably does is limited in a number of ways).
im not trying to make anyone out to be the voice of reason on this matter-- though leahs position is the one i find the least confusing of the three. openbsd wants no blobs on an os, but a the router on your os is different, but stallman says NO FREAKING WAY (i actually support and encourage efforts to de-blob openbsd of these exceptions, but ONLY someone who identifies with "free software" would ever do that-- no bsd ever would unless maintained by free software people) and leahs policy says "lets get started, at least-- and do more when we are able".
a blob is (arguably) anything you dont have the source code to. out of pedantry i always wondered if this excluded machine code from the free software definition, but surely it allows small amounts of it for situations where nothing "higher level" has ever been written. in fact, stallman seems to have a position that roms are not non-free and that if you can blow a fuse on a programmable chip that makes it essentially a rom (it cant be rewritten again after being programmed and the fuse blown) this is also somehow okay.
this is where the de raadt vs. stallman debate (usually conducted on their behalf, based on things theyve said about it before) gets really interesting, and either position can seem pretty daft from the standpoint of sheer logic, but ive defended stallman and (sort of by extension) de raadt on this, because the problem is so interesting that both of their stances seem to have points that are defensible in whatever context they have them. id rather side with one or the other, but its tricky enough.
de raadt seems to bristle at the pairing of the term "blobs" with "firmware", based on what i perceive his definition of the latter to be. but neither of these people (whom i consider visionary) seem to make complete sense (nor talk complete nonsense) when they discuss this. once again, it could just be me.
### where blob reduction takes this
if i thought blob reduction was a simple open source copout, i would definitely say so. instead, the policy seems to:
1. AVOID selling itself short with a strong-enough-for-now-dont-worry-about-the-future policy like the one ryf seems to be amounting to, possibly for the fsf to get stuck with a lemon (and the fsf rarely turns back or even moves forward once it has a lemon of a policy about something). fsf lemons are basically carved in stone, and when the fsf hands you stone lemons its less than trivial to make stoneade. (michaelangelo also carved things in stone, but i think the fsf was a better sculptor when it wasnt trying to please everyone-- including those opposed to its actual mission).
2. ENCOURAGE strides towards freedom by MINIMISING firmware blobs, whenever some can be replaced by something more free. depending on how well it does this (this is the scientific part: RESULTS-- but we will have to wait to find out if it actually works so its good to know if weve been down this road before, or if there are initial promises with initial strides worth taking seriously) this could lead to actual progress-- or not. but since it is really the entire point of the policy, i want to consider the implications.
3. ALLOW further progress in the future, in the inverse sense of what ryf (and worse, open source) may discourage while the latter focus on promoting "good enough" at the expense of "better still".
there is enough of an argument here to consider this as being something sincere, rather than one a backwards-heading compromise.
i may or may not fully understand all of this, but i think it deserves further consideration.
### comparison to other solutions ive supported
im not trying to take any credit here, im only trying to be fair to an idea i think is worth further consideration.
first: whether or not de raadts take on firmware is reasonable, or the fsfs goal is desireable, even leahs concept of firmware freedom seems closer to the fsfs goals than openbsd is, or put another way would be "more free" than bsd on the matter of firmware. as an openbsd user (albeit one who waits eagerly for hyperbola to gain further traction) it seems a bit silly (even hypocritical) to overlook this fact.
second: this seems to provide a genuine path towards further progress. this point is the one i feel the least confident making, though its included for completeness and it would seem neglectful to not mention it.
third: so far, the ryf in practice seems to be a mixed bag anyway, possibly going nowhere (and with a defunct, dishonest and at this point even exploitative organisation at the helm of it).
im tempted to even go as far as saying "why not?" but this is a bit glib for what im trying to give serious consideration to.
when i was still using gnu/linux, to give myself more control over distributions that didnt give ibm increasing control over my computing, i worked on AUTOMATED REMASTERS that did far more than techrights understood (or claimed after i left) about them.
three of the things these automated remasters were capable of were restoring upstart as the init system in trisquel (if youre about to protest that systemd is more than an init system as claimed and this is insufficient, you should know that I AGREE with you on that-- this was only a demo of the remastering capabilities) and also restoring sysvinit as the init in debian live (same issue as the trisquel demo) and it could remove NON-FREE SOFTWARE from systemd-free distributions like puppy and devuan (ive done both) and this led to a concept i referred to as "distro-libre".
distro-libre, inspired (loosely) by linux-libre, removed "blobs" from already-mostly-free (but not entirely free) distributions-- the goal was to make it so that people who were already using partly-free distros (and who were already ENCOURAGED to use fully-free distributions) would have some way they could experience those distros with blobs automatically removed.
furthermore, the system was easy enough to learn and use (i could defend this very ambitions, some might insist ludicrous statement, by explaining who used it to produce actual isos for download and how, though its not the main point of mentioning any of this and i no longer promote using this system i created anyway-- its still an idea im fond of) that just one person could "maintain" a handful of "fully-free derivatives" or at least demos of the same. (they wouldnt meet fsdg requirements, and i did not care as those go beyond requirements for inclusion in the free software directory anyway)
it was possible (with this plan, which started with this software but it could have been made slightly more powerful) to make free-software-only versions of every active gnu/linux distro hypothetically, and certainly the most popular (including some niche) distros actually, because it mostly came down to scripting this or that file removal and maybe calling a few package management commands. (no, not every live distro has a package manager. no, the original design never required it to and the ability to chroot package management to do things like replace the init system using the distros native facilities for doing so WITHOUT BOOTING SAID DISTRO at all came after the fact, and was optional).
it was a kickarse plan to make all gnu/linux distros free. granted, it was real software with a RHETORICAL (even ideological) nod and a wink to it as well.
but ultimately, red hats steamrolling continued and (after remixing several distributions in a "write once, append the script often" fashion that even allowed distribution of the script IN LIEU of distributing the full iso! not that roy would get this when he opened his mouth about it) and so many distros (really almost everything that is systemd-free) continued to drift towards github, i finally said "fuck it" and managed to flee to bsd.
since moving to openbsd, a lot of the stunts i pulled off just to make things like devuan more free and TOLERABLE after all these years are no longer necessary, because openbsd is quite sane compared to what gnu/penguinshit is these days.
but i still think the ideas that went into distro-libre were cool, and could be at least hypothetically useful if i ever manage to get the openbsd livecd (its not maintained by the same people, its a different project but i am happy it exists) to do something i want it to.
behind distro-libre was the CULTURAL notion of: "lets create a tool so that ordinary people (with a bit of training in file and scripting and text-editing basics) could take command of existing distros enough to strip out non-free software".
if you get more people involved directly in removing blobs from distributions, maybe the culture will shift and the developers will consider moving more non-free stuff to a separate repo (of course in practice we know this doesnt always happen-- non-fully-free distros must come from somewhere!)
either way, i considered the distribution itself (even distros like trisquel, in a world that has things like systemd) an impediment to users controlling their computing. distro-libre was a concept for making "the distro itself" more free.
the fact that it started with non-fully-free distros, with the EXPRESS GOAL of removing non-free stuff (and enabling non-distro-maintainers, even some individuals with other things to do the possibility of doing this as well) means that when i look at leahs idea, i know it has potential.
on the one hand, i know open source is (since 1998) compromise for its own sake.
on the other, ive long lamented that the fsf is (just a bit) an ivory tower, where if you have an idea for making pretty much ANYTHING more free, youre up against so much fucking inertia that you might as well just throw money at them and HOPE for the best.
i hasten to add that most projects that escaped this dualism went and sold out anyway-- but they never HAD to if they really wanted to stand for freedom. no matter what we do, the user must still choose to be free.
this is why (maybe this is my favourite stallman saying, because i say it so often) one of the best things you can do to HELP free software, is to USE free software. open source was very eager to put an end to all that "communal bullshit" once and for all. but the truth is that using free software is the only way to show it can be done. the more people that use it, they set the example. without that, free software is JUST an idea. with the example, it becomes more of a reality.
### but maybe you dont agree
my goal here is not to support an idea purely for the sake of being supportive-- the goal is for people to have more control of their computing (and for all software to be free).
open source made a lot of now-broken promises towards that goal, and any proposed compromise deserves additional scrutiny for this and other reasons.
if someone knows a reason why this will (in practice) lead to less freedom, or if they know a similar effort that was tried before and failed, id like to take that into consideration as well. i am at least a little sceptical. my hope is that i am sceptical enough.
my desire to be fair is simple enough in intent: i want to be fair enough to give GOOD IDEAS that will help our mission to make users more free a proper (even scientific) chance at helping. i know that open source has pretty much always abused such an attitude, and i dont wish to give it that opportunity. but i still want to avoid dismissing a really good, actually helpful idea.
science is our friend in this. im not here as much to tell you what science is, but to say that having an attitude amenable to science will yield the answers we need about leahs idea. and the fsf is not driven by science, or even by freedom-- but by token support, image management and fundraising goals. it is not the fsf anymore. that doesnt mean we should stop trying to give users control of their computing, it just means it will take more for us to do so.
finally, its worth noting that the motivation for fully-free software (including with regards to drivers) was to boycott devices that didnt support free software because its the only real leverage we ever had.
openbsd rejects non-free drivers because they run inside the os, and they dont want the os hijacked by bullshit that could do anything if it wanted, or something bad even if it didnt want to.
we still have an obligation TO OURSELVES to run free software. i dont know how this boycott of non-free stuff is going in general, but i know that for the most part, its all we have as a way to push for what we want. im not eager to abandon it either. but in all honesty, im not running osboot or libreboot (or even coreboot) on most things. i really cant argue with leah that it would be a real step forward if i did-- at least for me. whatever the best rule of thumb is in general, for the bios at least i feel like we should consider what leah is saying. and then if theres really a point to it, maybe we should consider it further-- and so on. failing that, theres still libreboot.
another reason i feel its necessary to comment on this, is that im trying to figure out whether osboot should be in the more libre software directory or not. i know libreboot belongs there, i would imagine coreboot does not. osboot is nearly in a category all its own. since the mlsd is still at a point where new entries arent an urgent matter, that gives time to think about this.
my first instinct, actually, is that osboot does NOT belong in the mlsd, at least not YET. ive made clear my misgivings about firmware and i actually RECOMMEND openbsd to people until hyperbola is ready, and im honestly not sure how osboot is different than this. i suppose it can be tabled, but if we dont begin this discussion i may never be certain what to do with something like this. the good news is that im sure the discussion will begin (somewhere) anyway, but i am certainly eager for that to happen.