Conceptually see OwnConcepts#RestrictionStack, the core idea being that a tech stack is not neutral. The abstraction describes the stack as hardware/software, then firmware, OS, user software, etc but in practice each component can be restrictive or not. An example of restriction can be a locked bootloader, a BIOS default setting prevention the installation of another OS, an OS with a default store and no alternative, a closed source application without any user scription capability.

The linchpin being that the components do stack on top of each other and thus restriction at one level of the stack will have implications, positive or negative, for the rest.

Stack itself

Restriction stack	Free stack	Theoretical stack
Account required and access monitored, e.g. Netflix, Disney+	No account required, e.g. Wikipedia, PeerTube instances, etc	Content distribution
DRM required and enforced, e.g Widevine, kernel level "anti-cheat", Denuvo	Ignored or at least entire optional and sandboxed, removed via e.g. DeCSS, DeDRM, libgourou	Content restriction
Banned or limited	Allowed or encouraged	User scripts and extensions of applications
Closed source, e.g. Zoom, OpenAI	Self-hosted, e.g. Jitsi Meet, Ollama (on AI more broadly see Self Hosting Artificial Intelligence)	Remote services
Closed source, e.g. Outlook	Open source and modifiable, e.g Firefox	Software
Proprietary stores, e.g App Store, Play Store	All stores possible yet optional, e.g F-Droid	Application distribution
Locked OS, no source available, e.g. Windows, MacOS, Android components by Google, iOS forcing browser engine	GNU/Linux distributions, /e/OS, GrapheneOS, BSD, handeld ones e.g MuOS or ArkOS	Operating system
TPM, bootloader locked	Open, e.g. LibreBoot, ANAVI TPM 2.0 module, LetsTrust-TPM(2Go)	Hardware booting
Closed source support required	Standards e.g. Bluetooth and open source support, e.g. GadgetBridge	Mobile peripherals requiring companion apps
Proprietary formats e.g. PDF	Open formats e.g. glTF, OpenDocument formats (e.g. `.odt .ods .odp .odg`)	File formats
Closed connectivity or proprietary protocols e.g. Microsoft or Logi dongles	Standards e.g. Bluetooth or ZigBee	Drivers for peripherals
Closed firmware that can not be modified e.g. Microsoft keyboards or Logi mouses	Open source e.g. ZMK or QMK	Firmware of peripherals
Closed codecs, e.g. MPEG	Open codecs, e.g. Opus	Compression codecs for video and other media
Closed sources, e.g. NVIDIA driver	Open, e.g. NVK	Drivers for internal hardware
Closed architecture relying on IP cores, e.g ARM, Intel CPU, NVIDIA GPU	RISC-V	Processors and DSP
Closed devices, e.g. Nintendo Switch	Open hardware, ideally devices compliant with OSHW	Devices integrating several layers of the stack
Closed e.g. Windows Mixed Reality, Meta Browser	Open e.g OpenHMD, OpenXR runtime e.g. Monado	Middlewares, runtimes, SDK, intermediary layers
DMCA, private/public research partnerships	Achieving interropability, Right to repair, OpenAccess and APIs, e.g OpenAlex	Law, politics and lobbying

Note that it must understood that a computer is not just a desktop, a computer is :

desktop or laptop
tablet
handled
networking element, e.g routeur
headphones
VR, AR, XR glasses
watch, rings and other wearables
e-reader
car or e-bike with a display and thus on-board computer
thermostats, e.g. No Longer Evil for Nest gen 1 or gen 2
keyboard, mouse, etc with a programmable firmware
robot, e.g. robotic vacuum cleaner but also single arm, humanoid, etc
security token
implants due to very real risks

It is fundamental not to be restrictive about the form-factor and capabilities.

Consequently different having non restricted hardware or software relying on other computers with a restricted stack risk restricting it too. For example using a GNU/Linux laptop behind a closed source routeur might force attempt at forcing it to use their DNS or monitor traffic on behalf of the ISP or 3rd parties.

Transition

Restriction stack	Free stack	Theoretical stack
Backup data (e.g. GDPR request)	Identify equivalent	Pick 1 item in 1 layer of the stack

General recommendations

start by considering what is already present for you for free, namely public infrastructure
- exemple of FIP https://mastodon.pirateparty.be/@utopiah/115451158468325979
keep the original, even if problematic, harware, software, or service until after the transition is done
do not try multiple things at once
take notes, trying and failing is OK as long as problems are logged and thus solvable later on
when a transition seems done, swap the new open version with the older closed on in its exact place
- leverge muscle memory
anything is better than inaction, even failing, even losing data
- the only inacceptable outcome is not learning
tread a well known path
- search for "Linux + hardware name" and see if there are lots of questions on how to make it work, comments on how it does not work, etc

Ship of Theseus illustration from Wikipedia

Imagine that each plank or other part of boat is a component of that stack, them must not all be changed at once.

Motivation

Motivated by PiratesInBrussels2025, specifically :

demonstration with actual hardware
- including legitimate alternatives, e.g.
  - Great : Precusor, PGB-1, NitroKey
  - OK-ish : SteamDeck, PinePhone (despite proprietary components), Lynx (same), PineTab 2, rooted PirateQuest Quests
  - Bad : Switch, iPhone, Android (Googled) phones or tablet, Meta Quest
process of going from Bad to OK-ish
- ...
tools helping going from OK-ish to Great
- ...

Swapping Parts Of The Restriction Stack {Content}

Stack itself

Transition

Motivation

See also