Open-Source Licence Compliance and Software Copyright in India

Introduction

Almost every piece of software built or deployed in India today relies, to some extent, on open-source software. Indian technology companies, from early-stage startups to large IT services businesses, use open-source components to accelerate development, reduce costs and avoid reinventing well-tested infrastructure.

Yet the legal framework around open-source software remains poorly understood by many businesses. Open-source licences are not “free” in the sense of being unconditional. They are copyright licences that grant permissions subject to specified conditions, and the Copyright Act, 1957 expressly recognises computer programmes as literary works. The Act therefore provides the underlying copyright framework within which software licensing operates.

When a company distributes software without complying with the applicable open-source licence conditions, it can lose the benefit of the permission granted by that licence and potentially face copyright and contractual consequences. The risk is particularly significant where a business uses copyleft-licensed components in proprietary products or fails to preserve required attribution and licence notices.

This article examines copyleft obligations under the GNU General Public License (GPL) family, the practical risks associated with combining open-source and proprietary software, attribution and notice obligations, the issues that typically surface during technology due diligence, and how open-source licences interact with India’s copyright framework.

Copyleft Obligations and the Risk of Licence Incompatibility

Open-source licences broadly include permissive licences, such as the MIT, BSD and Apache licences, and copyleft licences, such as the GPL family. The obligations differ significantly between licences and must be assessed by reference to the precise licence version and the manner in which the software is used and distributed.

Permissive licences generally allow software to be modified and incorporated into proprietary products, subject to conditions such as retaining copyright and licence notices and, in the case of the Apache License 2.0, complying with additional notice and modification requirements. The Apache License 2.0, for example, requires recipients to receive a copy of the licence, requires modified files to carry appropriate notices and requires specified copyright, patent and attribution notices to be retained.

Copyleft licences impose additional obligations when covered software is modified, combined or distributed. Under the GPL, the precise consequences depend on how the GPL-covered code and other code are combined and on the applicable version of the GPL. Where a GPL-covered program is distributed as part of a work covered by the GPL’s corresponding source-code and licensing requirements, the distributor may have to provide the relevant source code and preserve the rights granted by the GPL.

This is often described commercially as “licence contamination”, although the expression can be misleading because open-source licensing does not mean that every piece of code that merely interacts with an open-source component automatically becomes subject to the same licence. Whether proprietary code is affected depends on factors such as the licence involved, the nature of the combination, the manner of linking or integration, and whether the resulting work falls within the relevant licence’s definition of a covered or derivative work.

The distinction between static and dynamic linking should therefore not be treated as a universal legal test. For example, the Free Software Foundation’s GPL guidance states that both static and dynamic linking to a GPL-covered work can result in a combined work subject to the GPL’s terms. The analysis is more nuanced for LGPL-covered software.

The AGPL creates a separate consideration for software made available over a network. Its terms are designed to address certain forms of network interaction that would not necessarily trigger the corresponding source-availability obligations merely because software is provided as a hosted service under the ordinary GPL framework. For SaaS businesses, the applicable AGPL obligations should therefore be assessed before an AGPL-licensed component is incorporated into a product or service.

The commercial risk is particularly relevant for Indian software companies selling products and services into global markets. SaaS platforms, embedded systems, mobile applications and AI/ML tools may depend on dozens or hundreds of direct and transitive open-source dependencies. If the business does not maintain an accurate inventory of those dependencies and their applicable licences, compliance issues may remain undetected until a product release, customer audit, investment round or acquisition.

Open-Source Software Under Indian Copyright Law

The Copyright Act, 1957 provides an important statutory foundation for analysing open-source software in India. Section 2(o) expressly includes computer programmes within the definition of “literary work”, while Section 14 sets out the exclusive rights available to copyright owners in relation to computer programmes.

Section 30 permits the owner of copyright to grant an interest in the relevant copyright rights by licence. Section 51, in turn, provides that copyright may be infringed where a person acts without the requisite licence or in contravention of the conditions of a licence. This framework is important for open-source software because the licence is what gives the recipient permission to exercise rights that would otherwise be controlled by the copyright owner. If the recipient fails to comply with material conditions of the applicable licence, questions can arise as to whether the recipient continues to have the permission necessary for its particular use or distribution.

The legal analysis should nevertheless distinguish between copyright infringement and contractual enforcement. Not every dispute concerning an open-source licence will necessarily be characterised in the same way, and the precise licence language, the rights granted, the breach alleged and the applicable remedies will matter.

There is also currently limited Indian judicial authority directly addressing enforcement of major open-source licences such as the GPL. Accordingly, businesses should be cautious about presenting foreign GPL decisions or enforcement actions as settled Indian law. International enforcement experience can be persuasive and commercially relevant, but the Indian legal position ultimately depends on the Copyright Act, the licence terms, contractual principles and the facts of the particular dispute.

Attribution, Notice Duties and What Surfaces in Technology Due Diligence

Even permissive licences are not obligation-free. The MIT and BSD families generally contain obligations concerning preservation of copyright and licence notices. The Apache License 2.0 contains more detailed requirements concerning the licence, modifications and attribution notices, including circumstances in which a NOTICE file must be preserved.

These obligations can easily be lost when source code is repackaged, minified or incorporated into a larger build. A development team may know that a particular package is open source while the final product may no longer contain the licence or attribution information required for compliant distribution.

These issues matter disproportionately in technology due diligence. When an Indian technology company is acquired, raises institutional funding or enters into a significant strategic transaction, investors and acquirers may conduct open-source software reviews as part of their technical and legal due diligence. Typical findings can include:

• GPL or AGPL components incorporated into proprietary products without a clear record of the applicable obligations;
• missing licence and attribution notices in distributed software;
• incomplete or inaccurate records of direct and transitive dependencies;
• uncertainty regarding whether third-party contractors or development teams have properly assigned or licensed the relevant intellectual property;
• incompatible open-source licences within the same product; and
• inadequate internal processes for approving new open-source dependencies.

These issues do not necessarily make a transaction impossible. They can, however, affect intellectual-property representations and warranties, indemnities, escrow arrangements, remediation obligations and, in some cases, valuation.

A buyer may also request an open-source bill of materials (BOM) or software composition analysis report to understand what third-party code is incorporated into the target’s products and what obligations attach to that code. The practical lesson is straightforward: open-source compliance should be addressed before a transaction begins, rather than treated as a due-diligence exercise that starts after the term sheet is signed.

Building an Effective Open-Source Compliance Framework

For technology businesses, effective open-source compliance is less about avoiding open-source software altogether and more about knowing what the business is using and understanding the obligations attached to it.

First, maintain a software bill of materials (SBOM): The business should maintain an up-to-date record of open-source components, including their versions, sources and applicable licences. Direct and relevant transitive dependencies should be captured as part of the process.

Second, adopt a written open-source software policy: Developers should know which licences require legal review before a component is introduced into a proprietary product. Strong copyleft licences should generally receive particular attention because of the potential consequences of distribution and combination.

Third, preserve licence and attribution information through the build process: Compliance should not depend on an individual developer remembering to copy a licence file into a release package. Build and release processes should be designed to preserve the notices required by the relevant licences.

Fourth, review licence compatibility: The fact that two components are individually “open source” does not mean that their licences are automatically compatible. A business should assess how different components are combined and distributed before incorporating them into a commercial product.

Fifth, address ownership and provenance: Open-source compliance is only one part of software IP hygiene. Businesses should also maintain appropriate agreements with employees, consultants and third-party developers to establish ownership or appropriate licensing of proprietary code contributed to the product.

Sixth, conduct periodic audits: An open-source inventory can become outdated quickly as developers add, remove and update dependencies. Periodic software composition analysis and legal review can identify issues before they become transaction or customer-contract problems.

Conclusion

Open-source software is not a legal grey zone in India. Computer programmes fall within the statutory copyright framework, and open-source licences operate by granting users permissions that are subject to the conditions of the applicable licence. For Indian technology businesses, the principal risk is not necessarily a dramatic infringement claim. It is the gradual accumulation of undocumented dependencies, missing attribution notices, incompatible licences and unrecognised copyleft obligations within increasingly complex software supply chains.

These issues often surface at the point of an acquisition, funding round, major customer audit or internal IP review when remediation can be considerably more expensive and disruptive.

The sensible response is therefore practical rather than prohibitive: maintain an accurate software bill of materials, adopt a written open-source usage policy, preserve required licence and attribution notices through the build pipeline, review copyleft and licence-compatibility issues before distribution, and treat open-source compliance as a continuing part of software IP management.

For Indian technology companies, open-source software can remain a powerful development and commercial tool. The key is to use it with the same degree of IP discipline applied to the company’s own proprietary code.

Last Updated on 18 September, 2026