Introduction
Open source software has become the foundational infrastructure of the global technology industry. Estimates from multiple industry surveys consistently indicate that more than 90% of modern enterprise software applications contain open source components, and that the average enterprise application incorporates several hundred open source packages and libraries. For Indian technology companies, which supply software services, products, and platforms to clients worldwide, the legal obligations arising from these open source components are both substantial and frequently underappreciated.
The central legal issue is that open source software is not free of legal obligation merely because it is available at no financial cost. Every open source component is distributed under a software licence that imposes conditions on its use, modification, and redistribution. Failure to comply with these licence conditions constitutes copyright infringement under the applicable copyright law of the jurisdiction where the software is used or distributed, including the Indian Copyright Act 1957. The consequences of non-compliance range from legal action by the copyright holders (who may be software foundations, companies, or individual developers) to the forced open-sourcing of proprietary code, public reputational damage, and loss of client contracts that require open source compliance certification.
Despite the scale of the Indian IT sector’s exposure to these risks, open source compliance has received inadequate attention in Indian legal scholarship and limited institutionalisation in Indian technology companies. This article examines the principal open source licence types, analyses their compliance obligations and the specific risks of dependency chain neglect, reviews relevant international enforcement actions with lessons for Indian companies, and proposes institutional and regulatory reforms that would bring Indian IT sector open source compliance into alignment with international best practices.
Legal Framework
Open Source Licences: A Legal Taxonomy
Open source licences are contractual instruments that operate as copyright licences: the copyright owner grants to any recipient of the software a licence to use, modify, and distribute the software, subject to specified conditions. The legal foundation for the enforceability of these licences is the copyright in the underlying software, which in India is protected under the Copyright Act 1957 as a “literary work” (Section 13(1)(a), read with the definition of “computer programme” in Section 2(ffc) and the inclusion of computer programmes in the definition of literary works under Section 2(o)).
Open source licences fall into two broad categories: copyleft licences and permissive licences.
The GNU General Public License (GPL), in its versions 2 and 3, is the paradigmatic copyleft licence. The GPL’s core obligation, often called the “copyleft” or “viral” condition, requires that any software distributed as a “derivative work” or a “combined work” incorporating GPL-licensed code must itself be distributed under the GPL, with source code made available. This obligation is commercially significant because it means that a proprietary software product that incorporates GPL code must, if distributed, be released under the GPL with its source code, eliminating proprietary protection.
The GNU Lesser General Public License (LGPL) provides a “weaker” copyleft: software that dynamically links to an LGPL-licensed library does not need to be licensed under the LGPL, but modifications to the LGPL library itself must be released under the LGPL. The practical effect is that LGPL libraries can be incorporated into proprietary software through dynamic linking without triggering the copyleft obligation, making LGPL libraries more commercially compatible than GPL libraries.
The Apache License 2.0 is a permissive licence: it allows use, modification, and redistribution in both open source and proprietary software, subject only to a notice requirement (preservation of copyright and licence notices) and a patent grant. The Apache License also contains an express patent licence from each contributor, granting downstream users a licence to any patents the contributor holds that are necessarily infringed by the software.
The MIT License is the most permissive commonly used licence: it requires only preservation of the copyright notice and licence text when the software is redistributed, and imposes no conditions on the type of licence under which derivative works are distributed.
Copyright Act 1957 Application to Open Source Breach
When an open source licence condition is breached, the breach terminates the licence granted by the condition, and the party in breach is left without any authorisation to use, modify, or distribute the software. Their use, modification, or distribution then constitutes copyright infringement under Section 51 of the Copyright Act 1957, which defines infringement as doing any act restricted by the copyright without authorisation. The remedies available are the full range of copyright infringement remedies under the Act, including injunctions (Section 55), damages (Section 55(1)), account of profits (Section 55(1)), delivery up (Section 58), and criminal penalties under Section 63 (imprisonment up to three years and fine).
The enforceability of open source licence conditions as copyright licences, rather than merely as contractual obligations, has been confirmed in multiple international jurisdictions. The US Court of Appeals for the Federal Circuit held in Jacobsen v. Katzer (2008) that open source licence conditions are enforceable as copyright licences, such that breach of a condition (not merely a covenant) gives rise to copyright infringement. German courts (notably the Hamburg Regional Court and the Munich Regional Court in a series of GPL enforcement actions brought by Harald Welte through the gpl-violations.org project) have similarly treated GPL conditions as copyright licences whose breach gives rise to copyright claims. Indian courts have not yet addressed this question directly, but the doctrinal framework of the Copyright Act clearly supports the same analysis.
Judicial Developments
The Artifex v. Hancom Decision
The most instructive international decision for Indian open source compliance purposes is Artifex Software Inc. v. HancomInc. (N.D. Cal., 2017). Artifex, the developer of the Ghostscript PDF rendering library, distributes Ghostscript under a dual licence: a commercial licence for companies that do not wish to comply with the GPL, and a GPL licence for companies willing to open-source their derivative works. Hancom, a Korean software company, incorporated Ghostscript into its Hancom Office product suite, a commercial product, without purchasing a commercial licence. Artifex’s suit, alleging both breach of contract (failure to pay the commercial licence fee) and copyright infringement (use of GPL-licensed software without complying with GPL conditions), was allowed to proceed. The court held that the GPL’s conditions are enforceable as copyright licence conditions and that breach constitutes infringement, not merely breach of contract.
The Artifex case illustrates the specific risk for companies that use GPL-licensed software in commercial products without understanding that they must either comply with the GPL or purchase a commercial licence. Several major open source projects use this dual licensing model, including MySQL (now Oracle), Qt (from The Qt Company), and various cryptographic libraries.
Software Freedom Conservancy Enforcement Actions
The Software Freedom Conservancy (SFC), a US non-profit that holds copyright in GPL-licensed software projects including BusyBox, Samba, and the Linux kernel’s BusyBox component, has pursued GPL enforcement actions against electronics manufacturers whose products include GPL-licensed code without the required source code disclosures. These actions have resulted in settlements requiring companies to distribute source code, often with payment of legal fees and damages.
The SFC’s enforcement model, which focuses on manufacturing companies whose products are distributed in the US and Europe, represents the practical enforcement reality for Indian technology companies that supply software components to global electronics manufacturers. If an Indian software company supplies a firmware component that incorporates GPL code without complying with the GPL conditions, and the end-product manufacturer distributes the product in jurisdictions where the SFC or other GPL enforcers are active, the Indian company’s non-compliance creates legal risk for the entire supply chain.
Contemporary Issues and Analysis
The Dependency Chain Problem
Modern software development relies heavily on package management systems that automatically incorporate third-party libraries as dependencies. Node.js projects managed through npm may incorporate hundreds of packages; Java projects managed through Maven may incorporate thousands of transitive dependencies; Python projects managed through pip combine packages from multiple sources. Each of these packages has its own licence, and the aggregate licensing profile of a complex software project may include dozens of different open source licences, each with different compliance obligations.
The “dependency chain” compliance problem arises when a developer incorporates a package without reviewing its licence, that package in turn depends on other packages with their own licences, and the aggregate dependency tree includes GPL or LGPL code that triggers copyleft obligations affecting the developer’s proprietary code. This is not a hypothetical risk: multiple high-profile compliance failures have arisen precisely because a developer added a convenient utility package without realising that the package incorporated GPL-licensed code.
For Indian IT service companies that develop custom software for clients, the dependency chain problem creates a specific liability structure: the client’s product may incorporate GPL-licensed dependencies introduced by the Indian development team, exposing the client to enforcement action and creating contractual liability for the Indian company under the software development agreement’s representations and warranties clauses. Many international software development contracts now include specific warranties that the deliverables do not contain open source components that would impose copyleft obligations on the client’s proprietary code without disclosure.
NASSCOM’s Open Source Framework and Industry Practice
NASSCOM, the industry association for India’s IT sector, has published guidelines on open source software use that encourage member companies to develop open source policies. However, the level of formal open source compliance programme adoption among Indian IT companies is low compared to European and North American counterparts.
Major Indian IT companies, including Infosys, TCS, and Wipro, have published open source software policies and have established internal open source programme offices (OSPOs). Infosys’s Open Source Office maintains approved and prohibited open source component lists and requires legal review for any GPL-licensed component proposed for use in client deliverables. TCS has published its approach to open source governance through its participation in the Linux Foundation and OpenChain community. These practices at the largest companies, however, have not necessarily diffused through the broader IT sector, where smaller and mid-sized companies operate with less formal governance.
The OpenChain Standard
ISO/IEC 5230:2020, the OpenChain Specification, defines the key requirements for a quality open source compliance programme in a supply chain context. The standard covers: a documented open source policy; the training of relevant personnel; the identification of all open source components and their licences in each software release; the performance of compliance tasks including licence text inclusion and source code distribution; and the maintenance of compliance records for each release. Companies that certify to ISO/IEC 5230:2020 demonstrate to their supply chain partners that they have institutionalised open source compliance and can be relied upon not to introduce compliance liabilities into delivered software.
The OpenChain standard is rapidly becoming a commercial requirement in automotive, telecommunications, and consumer electronics supply chains. Toyota, Sony, and Qualcomm are among the major companies that have required or encouraged their software supply chain partners to achieve OpenChain certification. Indian IT companies that supply software to these industries need OpenChain compliance to maintain and win contracts in these sectors.
Comparative and International Perspective
Germany is the most active jurisdiction for GPL enforcement, reflecting both the German courts’ receptive approach to GPL conditions as copyright licence conditions and the presence of active enforcement organisations such as gpl-violations.org and the SFC’s European operations. The German courts’ willingness to issue preliminary injunctions against GPL violators has made Germany the preferred enforcement forum for many open source rights holders.
The US enforcement landscape is shaped by the SFC, the Free Software Foundation, and private attorneys who specialise in GPL enforcement. The US Copyright Act’s provision for statutory damages up to $150,000 per work infringed makes US enforcement actions potentially very expensive for defendants.
The UK IPO’s guidance on open source licensing is instructive in its emphasis on the distinction between licence conditions and covenants, which determines whether breach gives rise to copyright infringement or merely breach of contract. The UK approach aligns with the US Jacobsen v. Katzer analysis.
Practical and Policy Implications
For Indian IT companies, the immediate practical priority is establishing an open source programme office or equivalent governance function responsible for maintaining a policy on open source use, approving components for use in client deliverables, scanning projects for open source dependencies and their licences, and managing compliance obligations for each release. This function can be scaled to the size of the company: a small startup may manage compliance through a designated engineer using free scanning tools, while a large enterprise requires a dedicated team and commercial licence management software.
For Indian IT clients and global companies receiving software from Indian vendors, standard due diligence on software deliverables should include a software composition analysis (SCA) report identifying all open source components and their licences. Most commercial SCA tools (Black Duck, FOSSA, Snyk) can produce this report automatically, and requiring such a report as part of software delivery acceptance is now standard practice in technology-intensive industries.
Suggestions and Reforms
NASSCOM should develop a mandatory open source compliance standard for its member companies, modelled on ISO/IEC 5230:2020, with graduated requirements based on company size and the risk profile of their software deliverables. Adoption of this standard should be a condition of NASSCOM membership for companies above a specified revenue threshold. This industry-led approach is preferable to direct regulation because it allows the standard to be updated in response to evolving open source licensing practice without requiring statutory amendments.
The government should consider mandating open source compliance policies for companies that receive government contracts for software development, consistent with the government’s stated commitment to open source software under the Digital India initiative. This mandate would create incentives for compliance programme development across the mid-market IT sector where compliance practices are currently least developed.
The Copyright Act 1957 should be amended to explicitly address software licence conditions, confirming that breach of a condition (not merely a covenant) in a software licence gives rise to copyright infringement rather than breach of contract only. This amendment would resolve the doctrinal ambiguity in Indian law regarding the GPL enforcement model and would align India with the international consensus established by Jacobsen v. Katzer and the German case law.
Conclusion
Open source licensing compliance is not a niche legal speciality relevant only to technology lawyers and software engineers. It is a mainstream commercial risk for every company that develops or distributes software, including every Indian IT company operating in the global marketplace. The consequences of non-compliance, copyright infringement claims, forced source code disclosure, contract termination, and reputational damage, are commercially significant and in some cases existential.
India’s IT sector’s global competitiveness depends on maintaining the trust of international clients and supply chain partners that Indian companies will deliver software that is legally clean, including with respect to open source obligations. The institutional reforms proposed in this article, mandatory NASSCOM compliance standards, government procurement requirements, and Copyright Act clarification, would provide the framework for systematically improving open source compliance across the Indian IT sector, protecting both individual companies from enforcement risk and the sector’s collective reputation in global technology markets.
