When organisations talk about software systems, cloud platforms and vendors, the conversation often sounds like we’re dealing with unique, heavy, physical things that are hard to build more of and even harder to move. People say “we’re a [vendor] shop” or “we’re locked in” as if the system were a nuclear power plant or a railway line: a one-off construction that can’t realistically be copied.

But software is not like that. Software has a unique property that most other products do not have: it is easy to create copies. Once a system exists, making another instance is basically a matter of copying bits. You can run the same software in more than one place, and you can move it from one environment to another.

Even the hardware that runs software, while physical, is very different from big physical constructions like nuclear power plants, oil platforms or train lines. Modern hardware and infrastructure are built on well-established standards for servers, storage, networks and so on. This makes it far easier to replicate than large, bespoke physical constructions.

From a technical perspective, this means there is no fundamental reason you must be dependent on someone else’s system. In principle, you could run your own copy, or an equivalent system, if you wanted to. Technically, the system is not unique and immovable.

So where does the dependency come from? In practice it comes from other factors: licenses and ownership, people and competence, and the surrounding organisation. Licenses and contracts can restrict your right to copy, modify or run the software yourself. Intellectual property rules can mean you are only renting access, not owning what you use.

On top of that, there is the human side. Operating complex systems requires personnel, skills and experience. Many organisations do not have the competence to run certain systems themselves, or they do not prioritise building that competence. This makes them more dependent on vendors, not because the software cannot be replicated, but because the people and organisation around it are not prepared to do so.

Organisational structures and processes also play a big role. Workflows are built around specific tools. Risk aversion, “we’ve always used this provider”, and lack of incentives to change all contribute to staying with a given vendor. None of this is about what software can or cannot do technically; it is about how humans and organisations choose to structure things.

Because software and much of the hardware are relatively easy to replicate, it should be entirely possible to achieve real digital sovereignty and ownership. That means owning your own data, having control over your own digital services, and not being completely dependent on a single external provider for critical functions.

Achieving this is mainly about addressing the legal, organisational and competence barriers. Technically, the path is open: systems can be copied, moved and reimplemented. If we stop thinking about software as a unique physical object and start seeing it as something that can be replicated, it becomes much easier to imagine and design for digital sovereignty and true ownership of the digital services we depend on.