opensource digitalsovereignty softwarearchitecture trust wso2 conference
Core idea
Digital sovereignty is a balance, not a choice to isolate. Srinath Perera argues that organizations need to work across systems while retaining meaningful control over data, technology, and continuity of service. Open source can support both trust and control, but it does not provide automatic independence: architecture, skills, community health, and the ability to move away from a technology all matter.
Video
1. Sovereignty and integration pull in different directions
Perera presents digital sovereignty as a response to a more complicated digital boundary. Data, companies, systems, and workers can cross national borders, so control is harder to define than in a physical territory.
He describes a tension:
- Integration enables countries and organizations to cooperate and build shared systems.
- Sovereignty protects identity, autonomy, and the ability to make independent decisions.
Too little integration can lead to isolation. Too little sovereignty can leave an organization dependent on others and unable to control critical choices. His point is to preserve both, rather than treating separation as the goal.
2. What digital sovereignty covers
The talk outlines four areas of concern:
- Data: Who collects, stores, uses, and retains it.
- Control of systems: Who operates the systems that provide a service.
- Technological independence: Whether an organization can act without a provider being able to cut off service or dictate its choices.
- Legal safeguards: The rules that support the first three areas.
Perera says these questions can be considered at country, organization, or individual level, and across physical infrastructure, software, and data. This talk focuses on the enterprise level.
3. Regulation helps, but does not solve the problem alone
Perera points to privacy laws and other legal measures as attempts to give data owners rights and reduce dependence. He describes data-location requirements, interoperability, open standards, and support for local capacity as parts of the policy response.
He also notes limits: regulation can lag behind technology, add cost, or slow innovation. Rules cannot create local solutions or skills where none exist. A long-term plan must build the capacity to operate and maintain alternatives.
The speaker warns against “sovereignty washing,” or treating a complex problem as if a simple label or checklist could solve it. Measures that increase independence should not destroy the cooperation that made shared progress possible.
4. Design for the option to move
Perera recommends a long-term architectural view because laws, market conditions, and trust can change even when the rules themselves do not. For software, he suggests:
- Give data owners control over how data is collected, stored, used, and retained.
- Keep data in the relevant region where required or appropriate.
- Consider customer-controlled encryption keys as one possible response to conflicting legal demands. The talk presents this as an approach, not a complete legal solution.
- Prefer open platforms at the software-platform layer, where he argues abstraction can be difficult.
- Use open standards, and open source where suitable, at higher layers.
- If neither is practical, put proprietary dependencies behind clean interfaces so they can be replaced.
A central test is: How hard would it be to move away from this technology? Perera cautions against exposing proprietary technology through interfaces that make later replacement difficult.
5. Open source supports control, but does not guarantee it
Open code can let others inspect a system and can allow an owner to modify, host, or fork it. This can support both trust and control. But Perera stresses several conditions:
- Open standards and mature open source projects may not exist for every need.
- An organization may lack the skills to operate or adapt a project.
- Taking responsibility for an open source project can also mean taking on maintenance and liability.
- Communities need sustained contributions. A project without active participation may not remain useful.
- An open-source label does not rule out lock-in, including in open-core business models.
Therefore, open source is a tool for independence, not a guarantee of it. The practical result depends on the license and product model, architecture, operational capability, and the health of the project.
Key takeaways
- Balance independence with cooperation. Digital sovereignty should not become isolation.
- Think beyond data location. Control also depends on systems, technology choices, law, and operational capability.
- Design for changing conditions. Ask how difficult it would be to replace a vendor or platform.
- Use open standards and open source with care. They can improve portability and inspectability, but they do not remove all lock-in or operational responsibility.
- Invest in long-term capacity. Laws and architecture need skills, resources, and viable alternatives behind them.
Related vault notes: Governance Compliance and Trust connects platform trust to operational controls; Intellectual Property (IP) and SOA Governance add legal and service-governance context.