Open-Source Licence Audits for US Startups With Indian Developers

Most modern software is mostly other people’s code. A typical product pulls in hundreds of open-source packages, and each comes with a licence. Most licences are permissive and ask for little. A few, such as the GPL and the AGPL, can require a company that uses them in certain ways to publish its own source code. A US startup finds out which kind it has when an investor, an acquirer or a customer’s security team runs a scan.

Having an Indian development team doesn’t change the licences, but it does change the risk. Teams work fast, contractors may follow different habits, and developers copy snippets from repositories and increasingly from AI coding assistants. This guide explains how to run an open-source audit, how to deal with the Indian side of the team (contracts, policy and code provenance), what the legal risk looks like, and how to fix violations. It is written from the Indian-law perspective; US licence and litigation points belong to US counsel.

Why open-source audits matter in diligence

Open-source licence findings, particularly involving the GPL and AGPL, are described by US law firms as the most common intellectual property issue to surface in pre-launch legal reviews and acquisition diligence (Promise Legal). A buyer’s lawyers will audit your use of open source, and a finding discovered late can mean a price reduction, a special indemnity or a delay while code is rewritten.

Licences fall into groups. Permissive licences such as MIT, BSD and Apache 2.0 mainly require you to keep copyright notices and licence text. Weak copyleft licences such as the LGPL and MPL require changes to the licensed component itself to be shared, with fewer effects on the rest of your code. Strong copyleft licences such as the GPL can require the source of a combined work to be shared if you distribute it. The AGPL goes further: it extends the obligation to software offered as a network service, so a SaaS company that modifies an AGPL component and lets users interact with it may have to offer the source of its modified version, even if it never distributes a binary (Promise Legal; Daeryun).

Newer licences add complexity. Source-available licences, such as the Business Source License and the Server Side Public License, are not approved open-source licences and may limit competing commercial use. Some AI models and datasets carry their own licences with use restrictions. An audit shouldn’t stop at the standard open-source list.

How an audit works

The starting point is an inventory. A software bill of materials, usually called an SBOM, lists every open-source and third-party package in the code, with its version, its licence and its classification (Promise Legal; Black Duck). Tools such as Black Duck and FOSSA, and the open-source ScanCode toolkit, can generate this from the code and the build files. Don’t forget transitive dependencies, which are the packages your packages depend on, vendored copies of libraries, code snippets pasted into files, container images and, increasingly, model weights and datasets.

The second step is classification and analysis. For each component, decide which group it falls in, how you use it (linked, modified, distributed or only run as a service), and what the licence requires in that situation. The same library can be harmless in an internal tool and a problem in a product you ship to customers. Flag licences that are unknown, custom or inconsistent, and components with no licence at all, which means no permission to use.

The third step is remediation. For each problem, the options are to remove or replace the component, to isolate it behind a clear boundary, to comply by publishing the required source and notices, to obtain a commercial licence from the author, or to rewrite the functionality. Record what you decided and why. Sources suggest regenerating the SBOM about once a quarter and running a lighter process continuously, and a small team can often manage that in a few hours a quarter (Promise Legal). Repeat the full audit before a financing, a major launch or an acquisition.

Indian developer teams: contracts, policies and code provenance

Start with ownership. If your Indian developers are contractors, they own the copyright in the code they write unless they assign it in writing, and an Indian assignment should state the rights, duration and territory expressly, because Section 19 of the Copyright Act, 1957 otherwise defaults to five years and to India only. Without a clean assignment, you can’t be sure you hold the rights you will be asked to warrant to an investor. Make sure every developer, whether employed or contracted, has signed an assignment that covers all work done for the company.

Then set an open-source policy and make it routine. List the licences developers may use without approval, the ones that need review and the ones that are barred. Require approval for new dependencies, run licence scanning in your continuous integration pipeline so that a problem fails the build before it ships, and train the team on what “copying from a repository” means legally. Ask contractors and outsourcing vendors to follow the same policy, and flow your requirements down in their contracts with warranties about code provenance and an indemnity for third-party claims.

Be explicit about AI coding assistants. Suggestions from an assistant can resemble open-source code under restrictive licences, and developers rarely know the origin of a suggestion. Decide which tools are approved, whether the tools’ filters for matching public code are switched on, and whether developers must flag substantial generated blocks for review. Also deal with developers’ own open-source activity: contributions to public repositories made on company time may involve company code, so require approval before publishing anything.

Enforcement and legal risk

Open-source licences are copyright licences with conditions. In the United States, a federal appeals court held in Jacobsen v. Katzer in 2008 that conditions in an open-source licence can be enforced through copyright law, which is why a breach can lead to an injunction as well as damages. US counsel should advise on the current US position and on any pending litigation over the GPL.

Under Indian law, the Copyright Act, 1957 lets a copyright owner grant licences subject to conditions, and use outside the licence’s terms can be infringement, so the same logic should apply to code licensed under the GPL or similar terms. We have not found a landmark Indian court decision enforcing the GPL, which means the Indian position is based on the statute and general principles and has not been tested in the same way. A US startup should assume that a rights holder in either country could pursue an injunction, damages or an order to disclose source code, and that Indian courts are used to granting interim relief in copyright cases.

In practice, most open-source problems are not litigated. They are found in diligence and resolved by replacing the component, by a commercial licence or by a price adjustment. Be aware of how the risk travels through an acquisition: representations and warranties will ask whether any open-source licence requires disclosure of your source code, and a wrong answer creates liability for the founders. If your Indian contractors wrote code that included unlicensed material, the company that ships the product is the one exposed to third-party claims, even if the contract with the contractor gives you an indemnity.

Fixing problems, remedies and quick answers

When an audit finds a problem, deal with it in order of risk. First, stop the exposure: if a strong-copyleft or network-copyleft component is in a product that you distribute or run as a service, decide whether to remove it, isolate it or comply, and do that before the next release. Next, check the licence’s own cure provisions. The GPL version 3, for example, provides a route to reinstate rights for a violator who stops and fixes the problem promptly, so a quick fix can preserve your position. Third, document the fix and update the SBOM. If a rights holder has written to you, don’t ignore it or answer informally: take legal advice, preserve records and consider whether a prompt, documented remedy and a short settlement will cost less than a dispute. Keep contractors accountable by requiring them to remediate at their cost where they breached your policy. And build the audit into your calendar so that the next investor scan finds a clean record.

Related reading: who owns your code: IP assignment for US startups with Indian developers, hiring contractors in India from the US, legal due diligence on Indian startups: a checklist for US investors, who owns the AI model, weights and datasets, trade secrets in India: protecting source code and algorithms and using AI tools at work: confidentiality and leaks; also software copyright protection in India; also trade secret remedies when former employees take code.

Quick answers

Does using AGPL code in a SaaS product trigger a source disclosure obligation?

It can. If you modify an AGPL component and users interact with it over a network, the licence requires you to offer the source of your modified version to those users.

What is an SBOM?

A software bill of materials: a list of every open-source and third-party component in your code, with its version and licence.

Who is responsible for open-source compliance when an Indian contractor wrote the code?

The company that ships the product. You can shift the cost to the contractor through warranties and an indemnity, but you remain exposed to claims from rights holders.

How often should we regenerate the SBOM?

Sources suggest about once a quarter, with licence scanning running continuously in your build pipeline. Repeat a full audit before a financing, a major launch or an acquisition.

What does the AGPL require for a SaaS company?

If you modify AGPL-licensed software and users interact with it over a network, the licence requires you to offer those users the source of your modified version, even if you never distribute a binary.

Final word

Halverton & Co. is an Indian law firm advising US companies, founders, investors and law firms on Indian law, including IP assignment, technology contracts and open-source policy for companies working with Indian development teams. We practise in Jharkhand, Maharashtra and before the Supreme Court of India, and work alongside US counsel, who advise on US law. Halverton & Co.: Where tech needs law! If you have a question about Indian law, write to us at office@halvertonandco.com, or get in touch.

This article reflects developments reported up to late October 2026. It is for general information only, is not legal advice, and does not create an attorney-client relationship. Halverton & Co. is an Indian law firm and does not advise on US law; US-law points should be confirmed with US counsel.