In the previous two parts, I laid a groundwork for FOSS – the first unpacked the functionality of FOSS and the second examined the murky terrain of software patentability and the challenges it brings. This part will zoom out and address how control over software models a nation’s technological autonomy.
Picture this – one fine morning, government personnel log in to their digital workspaces – only to find their cloud accounts deactivated, bringing the everyday digital workflow to a halt. To find the reason, one need not stretch their imagination to a cyberattack, but instead, it could easily be the withdrawal of software services by a private (foreign or domestic) provider – a scenario which has previously occurred on multiple occasions (here, here, and here).
It is for this reason that, in the era of ever-changing geopolitics, the concept of “technological sovereignty” becomes a pressing issue for discussion. Building on this, Part II of the blogpost will explore this concept and its relevance in today’s day and age. The post then examines how far FOSS could take us to this goal and what has been India’s journey so far.
FOSS – A Byte Worth Biting?
For ages, the digital services landscape has been dominated by a few countries, specifically the United States, now joined by China. Such concentration deepens power asymmetries in the digital ecosystem, and allows such dominant actors to exercise strategic leverage over others (see here). The asymmetries create what is described as a ‘dependency trap’, where the dominating states could weaponize the dependence by dictating the terms on which the pool of software providers are made available to the dependent states.
The US’ threat to suspend Ukraine’s access to satellite internet during critical minerals-related negotiations illustrates how this coercive power is exercised (or infrastructural power). India is not immune to such vulnerabilities either. In recent years, Indian companies have faced suspension of services – as in the case of Nayara Energy where Microsoft withdrew its software services to the company due to its Russian backing.
(Pranesh’s tweet was in response to the report that the US would not extend to India the same economic advantages it offered China. In light of it, he underscores how pertinent it is for India to achieve digital independence.)
Even though the present circumstances do not yet mirror the severity faced by the EU, the episode underscores the inherent risks of dependence. Following the age old adage of precaution being better than cure, India needs to equip for much aggravated technological coercions.
It is in this setting, as a response to vulnerabilities, that the idea of technological sovereignty has gained relevance. As defined by Grant, “[t]echnological sovereignty is the ability and freedom to choose to create or acquire, as well as apply, develop and use for commercial purposes, technologies necessary for industrial innovation.” In the context of software and digital services, there are two specific strands which require further deliberation – first, whether FOSS, given its transparent nature, is secured to be adopted at scale, and second, whether FOSS is to be preferred over closed software, even though the latter is indigenously developed .
Transparency and Security Interlink
As discussed in Part I of the blogpost, the borderless software, beyond an innovative effect, provides greater autonomy to the user, here country, in shaping their digital ecosystem and its governance without facing the risk of vendor lock-in.
For security-specific purposes, the debate cuts both ways – while proprietary software, due to its design, is more prone to malware since there are fewer eyes scrutinizing the code. Yet its very opacity does not allow hackers to easily get their hands on the code. On the other hand, FOSS, being transparent, is a victim of its own success as potential hackers have access to the source code and can exploit its vulnerabilities (see here and here). At the same time, community-driven auditing and patching fixes vulnerabilities in FOSS programs at a much faster pace. However, the actual challenge lies in scale – the sheer volume of open source code lines makes thorough examination difficult. Even though FOSS is considered to be better in terms of security, than closed software, the 2014 Heartbleed and Log4Shell vulnerabilities have deservedly raised several eyebrows over the systemic risks it involves (see here).
The layered nature of software development further compounds these risks. At times, the final software product(s) depend on upstream open-source libraries maintained by external communities – this concentrates security risk onto a widely used component, making the built ecosystem susceptible to vulnerabilities to single points of failure (best depicted through this visual).
Lastly, FOSS-based systems require continuous maintenance which could be quite cumbersome. Applications built using open source components do not automatically inherit security fixes or updates released upstream. Instead, each update needs to be manually assessed and then integrated, thus requiring constant maintenance.
It cannot be conclusively held which software is more secure, but it goes without saying that for FOSS, risks can easily be mitigated. What makes the difference is governance – the need is to develop stricter FOSS usage policies which ensure regulate audits, maintain active community involvement, and importantly, install a zero-trust model that enforces strict access control and continuous verification to reduce potential vulnerabilities within FOSS environments. For this, the state might need to cultivate a pool of skilled programmers constantly updating and maintaining the open-sourced software.
Why FOSS over Indigenous Closed Solutions?
Moving to the second strand, an indigenous proprietary alternative to gain autonomy is a short-sighted solution because it merely addresses a part of the problem. Shifting from a foreign to a local vendor relocates control within national borders. It reduces exposure to foreign data regulations which might control where and how data is stored and processed such as regulations requiring workloads to be hosted locally or be subject to the extraterritorial reach of the surveillance laws, like of the US. Also, it may insulate states from volatile market changes or geopolitical shocks (like economic sanctions), that forces dependent countries to be at the mercy of the foreign service provider. In this sense, local proprietary software does advance a degree of digital autonomy.
But, this does not solve the deeper problem of dependency. The inner workings of a closed-source system, whether foreign or domestic, remain inaccessible to users, eventually restricting audits and state’s ability to determine design of its critical digital systems. The private vendor controls technical knowledge and maintenance capabilities within their firm, which ends up launching the country into another dependency trap – private domestic production.
Technological sovereignty is not about growth or localisation in isolation but rather gaining autonomy in an interconnected digital world. Without transparency and distributed control, at the end, local closed solutions risk weakening a state’s autonomy – just as foreign dependence would.
From Lock-In to Open Doors…
In 2024, Nigeria spent USD 400 million on foreign software licenses and services which amounts to two-fold concerns – first is the enormous fiscal burden in deploying such digital services and second is the national security concern given that sensitive information relies on such software. The situation is hardly unique to Nigeria and is echoed across the globe (see here and here).
For this very reason, to avoid creating a fragile ecosystem, several countries are pivoting to open source (here). Not long ago, it was the US reigning the global landscape, but in recent times, it has been joined by China as a major player due to its open-source based development model. FOSS is a central part of China’s technology roadmap under the 14th Five-Year Plan (2021-2025). The present situation of China is a product of its early and continuous efforts. It developed its own code hosting hub, Gitee, and established the OpenAtom Foundation, and these efforts were backed by companies, including Alibaba.
Even the European Union has begun to take cognizance of the enormity of the situation (to sideline the US dominance). It would not be an exaggeration to say that the EU is rigorously pushing the FOSS movement to break the existing hegemony in the digital landscape, following the “public money, public code” approach (see here, here, and here). The phenomenon is emerging across the world (here and here), and the foremost alternative driving the shift is FOSS
What about Homegrown FOSS?
The question arises – where does India stand amidst this as of today? It is somewhat disheartening to see that, despite taking early steps, there has been little visible progress in the area.
In 2001, Kerala had extended official support for FOSS through its State IT Policy, joined by Assam in 2009. By the mid-2010s, the FOSS movement appeared to be gaining momentum with several states pushing government departments to shift to OSS alternatives. A Policy on Adoption of Open Source Software was released in 2014 (see here), compliance with which was mandatory in nature (pg 3), aimed at advancing the FOSS movement in India. In 2015, the government further released ‘Framework for Adoption of Open Source Software in e-Governance Systems’ to supplement the 2014 policy. Annexure-VII of the framework outlined numerous initiatives taken around that time at both the centre and state levels to advance towards pan-India scale OSS adoption.
Though it cannot be said that action on this front has been entirely absent in recent years, the ambition with which it was once paired, is fading into oblivion, with much of the potential being unrealized. It was reported in 2025 that 12 lakh Central government email IDs have been shifted from the NIC based system to a Zoho-developed platform. The Ministry of Education, in the name of promoting swadeshi movement, asked officials to use Zoho Office Suite.
These developments bring the discussion back to the 2014 policy, which mandated the government to prefer FOSS over closed software. The goal is not even about choosing FOSS over indigenous solutions, but instead the attempt should be to kill two birds with one stone – fostering homegrown OSS! It will end up being a long-dreamt aspiration if no tangible actions are taken to actualise it.
I would like to thank Swaraj, Praharsh, Bharathwaj, and Ambika for their valuable comments.