Reclaiming Freedom: Who Holds Veto Over Your Data Stack
What Stallman understood about control that data tools hope you never ask.
Freedom Has Always Been the Point
Richard Stallman, who built GNU (GNU Not Unix - a recursive acronym), came up with GNU to solve a more cultural problem (that later became a huge technical debt). His problem wasn’t with the software but the lock: the mechanism that let someone else decide who could use it, modify it, or build on it.
This is the first principle worth holding: control over a tool is control over everyone who depends on that tool. It doesn’t matter how good the tool is. Goodness and freedom are orthogonal. A gilded cage is still a cage.
Unix makes a great analogy for enterprise data platforms today. They work. Genuinely. That’s precisely what makes the control so dangerous. The better they are, the deeper the dependency, and the deeper the dependency, the less theoretical the risk becomes.
Stallman understood that software freedom isn’t about ideology, but more about who has veto power over your work. When a vendor can change pricing, deprecate an API, or simply cease to exist, that veto lives with them. You are building on borrowed ground.
The question was never “does this platform perform well?” The question is: when their interests and yours diverge, and they always eventually do, who wins?
The Argument for Freedom: How Linux Happened. Ergo, Road to the High-Power Operating Systems
If you can’t see the code, you can’t trust the system. If you can’t change it, you’re not free.
AT&T’s Unix was genuinely powerful. But by the 1980s, AT&T locked it down. Stallman’s response was not to build something better than Unix. It was to rebuild Unix’s freedoms on top of Unix’s own architecture: three layers, from scratch, so no one could lock the door again:
Utilities: the everyday tools and commands
Shell: the interface between human and machine
Kernel: the core that talks to hardware and manages memory
There is no one company that could have imagined all the different cases where computers are used these days, and Linux, thanks to its adaptability where everyone can just tweak it in little ways to make it fit their use case, now covers all the use cases. ~ Karsten Nohl | Hacker, Security Research Labs
Linux spread not because it was marketed, but because adaptability without permission is an irresistible force for builders.
The public sector, in particular, adopted Linux precisely for this reason:
You can assume that Linux is pretty much used in anything of high-security need... because usually there’s secrecy involved in building, let’s say, a new weapon system… You don’t want to involve more people than absolutely necessary. ~ Karsten Nohl (Source)
Sovereignty. Mouldability. No vendor in the room where the iron is cast.
The Data Stack Holds a Mirror to the Unix Pattern
Today’s public sector data teams run on powerful platforms which are capable systems. The problem was not always the capability or the technology, as we saw with Unix. This problem is the same one Stallman walked away from in 1980.
History repeats itself, more so in structures randomly dispersed across the world, even in fields that seem probabilistically unrelated.
Data models are locked inside vendor schemas
Pipelines are built on proprietary orchestration that doesn’t leave with you
Governance rules are configured inside platforms you don’t control
Exit means rewriting everything
Stallman, in his own words, wondering if he’d fit into the new structure of vendor-controlled environments,
I realized that that way I could have fun coding and I could make money. But at the end, I’d have to look back at my career and say, “I have spent my life building walls to divide people and I would’ve been ashamed of my life.”
The walls in the data world are called vendor lock-in.
An Operating System for Data is the “Not Unix” revolution for the Data Layer
You don’t need to replace the foundation. You need to free what’s built on top of it.
GNU didn’t replace hardware, and Linux didn’t replace computing. They freed the operating layer, the layer that sits between raw infrastructure and human use, from proprietary control. Data systems MUST learn from software struggles. Inherit the best, skip some of the struggles.
An Operating System for data does the same thing for data teams: freeing the data operating layer by rebuilding its equivalent layers from the ground up: Kernel, Shell, Utility Apps

A data operating system gives data teams the ability to build and run their own data operating environment.
The new freedoms include (but not limited to):
Define own data products, owned by org/team
Govern data with own policies, not vendor defaults
Swap underlying infrastructure without rebuilding from zero
Share data across departments without surrendering control to a platform intermediary
This is a projection of Stallman’s four freedoms (run, study, change, share) applied to the data layer.
The XZ Problem: Protecting the Freedom Won
Winning freedom is not the same as securing it.
GNU/Linux solved the Unix problem. But the XZ Utils backdoor reveals what open systems can inherit if left ungoverned:
The entire operating system rested on a single part, maintained by a single person, and by compromising that one part, they could infect almost any server on the internet. (Source)
Lasse Collin maintained XZ for 20 years, unpaid, burning out. Jia Tan, likely a nation-state actor, weaponised that exhaustion through a two-and-a-half-year social engineering campaign. The attack surface wasn’t the code. It was the human dependency underneath it.

Anything from spying, to ransom, to taking down entire countries: you could have done it with this backdoor. ~ Karsten Nohl
For domains such as the public sector and defence, this scenario is not hypothetical. It is the primary threat model.
…I’m worried that we didn’t find other backdoors. There are state-sponsored parts of either governments, militaries, or even private contractors working for states that are all preparing for the next cyber escalation. ~Nohl
A Data Operating System doesn’t go back toward closed source, but builds freedom warily with structural guardrails that make single-point human dependency architecturally impossible:
No single maintainer holds unguarded keys to core modules
Contribution pipelines have accountability structures, not just open commit access
The system is hybrid: open enough to be moulded, governed enough to prevent fatalities
The operating system needs to support the people: the data teams building on top of it, by ensuring that the platform itself is not one exhausted volunteer away from compromise.
Why High-Trust Operators Come First to Such Discussions
Sovereign institutions (governments, defence agencies, public health bodies) do not have customers. They have citizens. That distinction changes everything about how they must treat data. Every decision is subject to oversight.
This is how most high-trust operators chose Linux over Windows and proprietary Unix for reasons that are structural, not just technical:
Citizens and oversight bodies must be able to interrogate decisions → requires auditability
Agencies share data across jurisdictions without surrendering control → requires interoperability
Policy changes require system changes without vendor negotiation → requires mouldability
The data layer has become the new operating layer, where the real decisions about who sees what, who controls what, and who can change what are made. Locking that layer inside a vendor is the 2026 equivalent of the 1980s in software.
What is desired and absolutely necessary for data teams is a foundation they actually own, with the ability to mould it without asking permission. And now, with the guardrails to protect it from the threats that come with that openness.

MD101 Connect ☎️
If you have any queries about the piece, feel free to connect with the author(s). Or connect with the MD101 team directly at community@moderndata101.com 🧡
Author Connect 💬
Connect with Animesh on LinkedIn 💬
Connect with Travis on LinkedIn 💬
From MD101 team 🧡
🌎 Global Modern Data Report 2026
The Modern Data Report 2026 is a first-principles examination of why AI adoption stalls inside otherwise data-rich enterprises. Grounded in direct signals from practitioners and leaders, it exposes the structural gaps between data availability and decision activation.
With hundreds of datapoints from 500+ data leaders and experts from across 64 countries, this report reframes AI readiness away from models and tooling, and toward the conditions required and/or desired for reliable action.















