Open-Source Licensing Compliance for Indian SaaS

Most Indian SaaS companies depend heavily on open-source software — and most have no idea what licences their dependencies impose. The licences range from genuinely permissive (MIT, BSD, Apache 2.0) to viral and copyleft (GPL-3, AGPL-3) to commercially restrictive (SSPL, Elastic v2). Each carries different obligations. Investor counsel runs licence-scanning tools during diligence; an AGPL component without proper isolation can stall a Series A.

This piece is the compliance playbook for Indian SaaS — what to scan, what each licence requires, and what to do when the scan finds something concerning.

Categorising open-source licences

For practical purposes, Indian SaaS engineering teams should categorise dependencies into four buckets:

1. Permissive — MIT, BSD, Apache 2.0, ISC. These permit use, modification and redistribution with minimal obligations (typically attribution and licence preservation).
2. Weak copyleft — LGPL, MPL 2.0, EPL. Copyleft applies only to the licensed code, not to combined works that use it through an API or library boundary.
3. Strong copyleft — GPL v2, GPL v3. Derivative works that include or link to GPL code must themselves be licensed under GPL — the ‘viral’ effect.
4. Network copyleft — AGPL v3. The strongest licence: if you use AGPL code as a service over a network (i.e., SaaS), you must make the source code of your modifications available to users.

The licence you did not read is the licence you owe.

The AGPL problem for SaaS

Permissive licences are usually fine for SaaS. GPL is usually fine for SaaS because GPL triggers obligations on distribution — and SaaS typically does not distribute the software (the user accesses it over a network). AGPL closes this gap. Section 13 of AGPL v3 expressly requires that if the licensed software is offered as a service over a network, the source code of any modifications must be made available to users.

For a SaaS company, this means: an AGPL component in the production stack can trigger an obligation to publish your modifications. Many investors treat this as a deal-altering issue.

How to audit your stack

Two approaches that work for Indian SaaS engineering teams:

1. Automated SCA tools

Software Composition Analysis tools scan a codebase and inventory every dependency along with its licence. Popular options: FOSSA, Snyk, Black Duck, OWASP Dependency-Check. Open-source alternatives include the OSS Review Toolkit and Scancode. Each produces a Software Bill of Materials (SBOM) that lists every component, its licence, and its known vulnerabilities.

2. Manual licence inventory

For smaller stacks, a manual inventory is workable: pull dependency files (package.json, requirements.txt, go.mod, pom.xml, Gemfile), look up each dependency’s licence, and tabulate. Time-consuming but produces full visibility for a small codebase.

What to do when the audit finds an AGPL or strong-copyleft component

1. Remove it — if there is a permissively licensed alternative that does the same job, swap it in. Usually the cleanest fix.
2. Isolate it — keep the AGPL component in a separate service that runs as an independent process or in a separate microservice. Communication via clean APIs reduces the legal coupling. (Whether this fully addresses AGPL obligations is jurisdictionally fact-specific; take advice.)
3. License commercially — many AGPL projects offer dual licensing. MongoDB Atlas, RethinkDB, Neo4j and several others sell commercial licences that lift the AGPL obligations.
4. Comply with the licence — publish your modifications. Workable for some open-source-aligned companies, less workable for proprietary SaaS.

Indian legal position on open-source

Open-source licences are enforceable contracts in India. The licence is the consideration for the use; breach of the licence terms gives rise to a contractual claim and, in some cases, copyright infringement under the Copyright Act, 1957. Indian courts have not yet decided a leading open-source enforcement matter, but the licensing framework is well-recognised and contracts are enforceable under the Indian Contract Act, 1872.

Maintaining ongoing compliance

The audit is a moment-in-time check. Ongoing compliance needs:

• An SCA tool integrated into CI to flag new dependencies and their licences
• An internal licence-allowlist (approved licences) and licence-blocklist (prohibited licences)
• Periodic re-scans (quarterly or per release)
• A clear process for engineering teams to request approval for non-allowlisted licences

The takeaway

Open-source compliance is not exotic. It is a hygiene practice that takes a tool, a policy and a process. For Indian SaaS companies preparing for diligence, it is also the line item most likely to surface during the data-room phase if not addressed early. Run the SBOM. Categorise the dependencies. Remove or isolate the AGPL and strong-copyleft components. The check during the early build phase costs hours. The remediation during diligence costs weeks. An IP audit bundled with an open-source compliance review is the standard pre-raise diligence preparation for Indian SaaS.