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

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.

> No you don't, as that's not creating any users, the source code repo is the source code repo, not a distributed program you provide as service for anybody.

The license is a copyright license and deals exclusively in modification and redistribution, not usage - that includes the source code. "Users" mean "potential users" in this context; whoever hypothetically uses the software in any given version, as it exists in source code form, regardless of whether such users come into existence or not. It doesn't matter whether the software is deployed or not; the license cannot and does not claim to control or have anything to do with that. If it did - if the violation only occurred at the point where the software is deployed and run - then again that would imply this is an EULA that controls usage and violates Freedom Zero.

Again, consider my "two parties" scenario. I make some changes to AGPL software, but never deploy it or offer it as a service. According to you, that is perfectly OK. I then send it to someone. According to you, again, that is perfectly okay, just like contributing to an AGPL project. Then that someone makes zero changes to the code - therefore not triggering clause 13, obviously - and deploys it without updating the source code offer. No problem. If the license worked as you claim, then it doesn't work to close the SaaS loophole at all.

It does not, and the entire hack the FSF came up with is precisely this, converting a usage restriction into a responsibility for the developer making modifications. Everyone defending the AGPL misunderstands this, because the FSF has been very careful to never bring up that this is what they did. They treat it like schrodinger's license: simultaneously claiming it can do things that require it to restrict usage (making it nonfree) and claiming it is a free software copyright license.

> I'd heavily recommend talking to someone with (FOSS) legal experience if you're involved in such distributions, no offense meant.

It's rather difficult to find someone who will consider entertaining the idea that the FSF is completely backwards in their license design, because nobody wants to open that can of worms. People are much happier to just pretend nothing is wrong and move on.

> We're providing most of our code base under the AGPLv3 and have never faced any such issue either for people contributing to our projects or us contributing to other AGPLv3 projects.

Of course, because neither you nor your contributors actually parsed the AGPL properly nor are you aware of the violations occurring on a daily bases. That nobody knows there is a problem doesn't mean there isn't one :)

> Granted, some FANG company refused to use us

No surprise there. I have a hard time using AGPL software too; last time I discovered some on my system I was already in violation, because my distro had patched it without adding a source code offer, and since I use a source-based distro (Gentoo) that patch occurred on my machine, making me responsible for it. On top of that, I was running it as a network service behind a protocol-translating proxy, just because that is how it was meant to be used, so even if it did have a source code offer, it would have been invisible to external users. I was ticking all the boxes for AGPL abuse without even knowing it.

(What nefarious service was I running taking advantage of a poor AGPL project? My personal email server, which used dspam as a spam filter - although not directly exposed to the internet, it could easily be argued that everyone sending mail to me is a "user" of dspam since the data they sent is piped to it, quite directly, and the AGPL does not make any attempt to carefully define these terms)

Right now the only AGPLed software I (knowingly!) run is Nextcloud (with 2 other users besides myself) and (as of a recent license change, sigh) Grafana, but I once thought of making a little patch to a Nextcloud CSS file as a joke, and had to remind myself that that would've been an AGPL violation without packaging it up and distributing it and updating the source link in the footer. For Grafana I also had a tiny proxy-inserted patch (just because it was easier that way than rebuilding, this was before the AGPL change) just to add the ability to display image icons next to dashboard names (again for a little joke displaying character images for servers), but I'm going to get rid of that before the AGPL update on that box because I just don't want to deal with any of this. Not exactly a comfortable feeling knowing I can't even make a trivial change to "free software" running on my own system without breaking the license. And it gives me zero incentive to contribute to these projects. I don't want to support this kind of ecosystem.

(Web apps: for fuck's sake, if you insist on being AGPL, please implement self-serving source code so we don't have to deal with any of this nonsense, and then maybe you can take GitHub pull requests without everyone violating the license too.)

I once had a discussion with the authors of a DAW that used the AGPL license, and pointed out that MIDI is technically a network protocol - meaning their DAW would have to figure out a way to make source code offers over MIDI, to be presented to users on the other end, even though MIDI doesn't even have any standard mechanism for user-interface text. Never mind that MIDI can even be used over a unidirectional transport, so you couldn't even do that at all in some cases. The AGPL doesn't even begin to consider these problems; it was written assuming everything is a web server or something. I got crickets from the devs. Sigh. (Why is a DAW AGPLed to begin with even?)

Seriously, it's a completely broken license, written by some lawyer who though they were being clever and had magically solved the SaaS + free software issue, without bothering to consider the consequences of what they were creating. And now everyone's sweeping the problem under the rug and nobody wants to seriously talk about it. Because how could the FSF be wrong about free software licensing?

> but that's not something really hurting us in any way

I dunno, for what it's worth the AGPL definitely turns me off from contributing to projects, but maybe you aren't losing enough contributors to care ¯\_(ツ)_/¯

This is of course still predicated on you not caring that your contributors are all violating each other's license. Is that a problem? In practice, probably not, if nobody actually makes legal demands over it. But it's a fact, whether it's a problem or not. And I don't like relying on "people being nice and not enforcing license violations" to run my open source projects. We have licenses for a reason, ignoring them and encouraging certain violations just because the situation isn't a problem (or because nobody understands the license) invalidates the entire point of licenses.

> and definitively better than getting stabbed in the back like some other projects got from some SaaS companies due to having a permissive license that allowed them to deploy changes without giving them back anymore.

Too bad that, as I explained, if a company really wants to use AGPL software without contributing back, they still can.

Personally, everything I've written recently is MIT or dual licensed, but I understand the desire not to allow companies to deploy modified versions of open source software without giving back. The AGPL just doesn't fix that problem. At all. Fixing that problem is incompatible with the Free Software Definition. If you really, really want to fix that problem that badly, you have to accept that your license cannot be a Free Software license by the standards we use today. It's one or the other.

> that users of the Librem 5 phone are objectively harmed in three ways

That's not true though.

First: things that were done in order to move the blobs out of PureOS weren't hidden in any way, to the contrary - they were loudly announced as "steps towards RYF certification", describing exactly how that's supposed to work in public blog posts[0]. I can't see how that counts as "[users] unaware of the existence of the blobs".

Second: the blobs are perfectly accessible to anyone who wants to study them - not only you can download them from repositories online, but you can even access the flash where they're stored on your device; you can also read and modify the code that loads them. What's more - you can even bypass that loading mechanism and load them directly by yourself from the main CPU if you don't care about keeping the blobs out of your rootfs (and some alternative OSes do that already). Which gets us to...

Third: users do have the ability to replace the blobs. Not only can they run an OS that loads the blobs directly - they can even reflash the storage where the blobs are being stored. And no, no disassembling, special tools or weird hardware tricks are necessary - you can just lift the read-only lock purely in software (it's a one-line change to the device tree), which is there mostly to prevent you from accidentally shooting yourself in the foot than anything else.

You may disagree whether the additional effort that went into creating these solutions was worth it - and that's a valid opinion to have, but nothing's artificially locked out from the user, so nobody is "objectively harmed" by it. That part is just false.

Disclaimer: I work for Purism on the Librem 5.

[0] https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...

I don’t necessarily question this exact usage, given we are talking about RMS.

FWIW, nothing stops Librem 5 users from just throwing away all that nonsense code they wrote to load the firmware from a dedicated flash, and just flash standard U-Boot (which already includes a mechanism to embed the blob, which is the normal way to do it), at which point you can of course modify it or replace it.

Basically, it's a whole bunch of wasted engineering effort, but it in no way accomplishes actually turning the blob into "hardware" or making it immutable. It's just rules-lawyering. Which makes it even more pointless and nonsensical. The sticking point seems to have actually been not having the main CPU touch the physical bits of the blob (not execute; touch); avoiding that magically made it RYF-certifiable. This is why they moved the loading process to a secondary core (that still runs open source code, which then loads the blob into a third core that runs it).