In the first part of the post, I explained the emergence of FOSS and its effect on innovation – often accelerating it but with its own bumps along the road. This part will wheel the discussion to another thorny issue: patentability of software and the many new questions it raises, both generally and in the India context.
When Code Slips through Copyright
A pertinent question to be considered, before detailing the Indian standpoint, is – how does IPR enter the picture? First comes the copyright, whose protection enters as soon as a code is written – this protects the code, as a literary work, from copying without the permission of the author. The problem here is that copyright enforcement comes into force only when the source codes are compared with one another. In practice, re-writing the code – to achieve the same functional output only to avoid being categorized as literal copies – seems trivial (see here).
The limitation is more pronounced because software is not just expressive but fundamentally functional. Copyright fails to provide protection to many of software’s non-literal or functional elements such as program architecture and sequence of operations. In the US specifically, through SSO (Structure, Sequence, Organization) or AFC (Abstraction, Filtration, Comparison) tests, courts have treated these elements as ideas or functional necessities instead of protectable expression (for more, see here). The underlying rationale is that copyright protects expression of an idea, but not the idea itself whereas patent safeguards the functional methods or processes implemented by the code, irrespective of the manner in which they are written, giving the owner a broader right (see here and here). As a result, copyright offers a wafer-thin protection.
However, it is not to suggest that stronger IP is required to replace copyright. Even at the time when patents were not strong, the software industry still expanded steadily. This is so because unlike industries, as pharmaceuticals, where the development costs are extremely high, the software industry has a minimal cost of replication. The latter derives advantage from the speed of innovation rather than the exclusivity, thereby drawing the question of why a software patent is required.
Patentability of software in itself is a debated issue since the argument arises that software comprises mathematical algorithms which are merely abstract ideas and thus, not patentable. However, the Patents Act, 1970 under Section 3(k) treats “computer programme per se” differently from mathematical method and algorithms, rendering the argument untenable.
The “Patent” Roadblock in India
But if allowed, what problem does a software patent even pose? As it turns out, plenty! To put a few out, first is the almost impossible task of avoiding infringement and its effect on technological development. Equating software to symphony, Richard Stallman gives an example that just as a symphony is a composition of small elements, so is a software. No one writes it from scratch, and innovation thrives on remixing and improvising existing building blocks. Algorithms, being mathematical at their core, can be rewritten in countless ways, allowing it to be patented over and over. Developers may unknowingly use a method that has already been patented. As a result, the pace of innovation stalls when these very foundational blocks are locked behind patents.
The next hurdle is administrative examination of these software patents. Most of the software patents cover abstract ideas. As software-related patents increase year-by-year, circling down the patent which applies to one’s application in a sea of countless vaguely scoped and ambiguously named patents is indeed a tedious task. While large-scale litigation of software patents has not yet materialized in India, experience from comparative jurisdictions like the US suggests similar challenges might spring.
Adding to it, all relevant patents cannot be verified in the first place given the confidentiality of pending applications and delays faced in publication of patents. The LZW compression saga behind GIF format is a fitting example where developers worldwide used it before realizing that the method was patented. Although the US-based case is dated, the recent RX Prism v Canva case drives home the message that the problem continues to persist. Moreover, unlike other fields, software has no clear blueprint to determine infringement.
Granting patent software has its own costs and consequences as it also allows non-producing entities and patent trolls to exploit others. Patent trolls first, acquire software patents by buying existing patents from struggling companies or small firms and weaponize them to engage in predatory patent enforcement. With the goal to turn these patents into a steady stream of income, they sue other companies which eventually choose to settle to avoid astronomical costs of litigation (as the Forgent CEO puts it, patent trolling merely maximizes value). This directly hinders innovation and progress as resources are diverted to such non-productive avenues. The USA presents a cautionary example of being at the receiving end of patent trolls for long where vague and overly broad software patents enabled trolls to flourish (see here and here).
The Indian Patent Act under Section 3(k) excludes “computer programs” per se and algorithms from patentability. At first glance, one might consider that the statute itself excludes computer programs, including software, but the reality is far from it. Behind the words “per se”, there has been a long tumultuous journey to consider what all it includes, leaving behind a trail of messy decisions with still no answer in sight (see here and here).
One group undertakes a functional approach. Herein, the court focuses on the question whether the invention produces a “technical effect” and if it does, then even software or algorithms are allowed to be patented. This opens another Pandora box – what exactly counts as “technical”? To answer it, the courts have adopted multiple tests (to name a few, technical contribution test and technical advancement test) which has left the jurisprudence even more fragmented. Further, this confusion worsens when courts (as in Ferid Allani) conflate one test for the other.
The second approach is of absolute exclusion where courts held that subject matter fundamentally excluded under Section 3(k) – a business method or algorithm – cannot become patentable regardless of its technical implementation (as in OpenTV Inc and Oneempower Pte Ltd).
The 2025 Guidelines is another addition to this convoluted terrain – it cherrypicks a few tests over the rest for the definition of “technical” without any rationale for it (see here). In a 2023 report, SFLC.in documented irregular patents granted by the Patent Office from 2014 to 2022 in violation of Section 3(k). The report highlighted the increasing trend in awarding patents to software over the years, out of which a disproportionate number is devoted to foreign entities (pg 15). Given that the situation has not changed since then (in terms of providing a concrete test), there lies no sight of improvement.
The discussion becomes relevant for FOSS – considering that open source relies on building over existing code, a broad patent could potentially risk running FOSS projects into legal bottlenecks. The impending threat, even though not in direct line of sight, should not result in complacency but makes a call for proactive measures to clear the air around the criteria for software patentability – not merely for open-source development but innovation as well.
For further reading on FOSS, I would suggest Eric Raymond’s essay ‘The Cathedral and the Bazaar’, which contrasts the cathedral (closed source) to the bazaar (open source), and Christopher Kelty’s ‘Two Bits’, which provides an academic-oriented portrayal of the early history of FOSS.
I would like to thank Swaraj, Praharsh, Bharathwaj, and Ambika for their comments on the draft
