Five open source compliance do's and don'ts for Indian startups in 2026 — SBOMs, license mapping, copyleft isolation, and developer approval workflows.
5 Critical Open Source Compliance Do's and Don'ts (Avoid Legal Blunders)
Open source software powers over 90% of production systems at Indian startups, yet the licensing obligations attached to it are frequently misunderstood and almost never documented. Violating a GPL or AGPL license does not attract a government penalty — it exposes you to copyright infringement claims under the Copyright Act 1957, forces emergency source-code disclosures, and can collapse a fundraise or acquisition mid-process. This guide gives you five actionable compliance rules, the exact tools to implement them, and hard Rs. numbers that show what non-compliance actually costs.
Why Open Source Compliance Is Now a Board-Level Concern in India
Three structural shifts have brought open source compliance out of the engineering basement and into the boardroom.
Cross-border acquisitions demand clean SBOMs. US and EU strategic buyers routinely run a full intellectual property (IP) diligence pass before signing a term sheet. The EU Cyber Resilience Act (CRA), which came into force in September 2024 and applies to products with digital elements sold in EU markets, requires a machine-readable Software Bill of Materials (SBOM) for regulatory compliance. Indian SaaS companies with EU customers are directly in scope. An Indian acquiree that cannot produce a current SBOM cannot close a deal — period.
Indian courts are IP-literate now. The Delhi High Court's Commercial Division has handled increasingly sophisticated copyright and software licence disputes over the past five years. The Indian Patent Office has tightened its examination of software-related claims. If a licensor brings an infringement action in India for GPL violation, the Copyright Act 1957 (Section 51 read with Section 55) provides for injunctions, damages, and accounts of profits.
Investors are asking. Since FY 2025-26, institutional investors at Series A and above — particularly those with US or EU LP bases — have added OSS licence risk to their standard diligence scorecards, alongside data privacy (DPDP Act 2023) and cybersecurity. Failing the OSS check can trigger a valuation haircut or a condition precedent that must be satisfied before the first tranche lands in your bank.
DO 1: Maintain a Live Software Bill of Materials
An SBOM is a machine-readable inventory that lists every software component in your product — name, version, licence, and origin. Think of it as the ingredients list on a food package, except for your codebase.
What an SBOM must contain
A complete SBOM, in either SPDX or CycloneDX format (both are OASIS standards), records:
- Component name and version (e.g.,
log4j-core 2.20.0) - Licence identifier using SPDX expression (e.g.,
Apache-2.0,GPL-3.0-only) - Package URL (PURL) — a canonical identifier usable across package ecosystems
- Supplier and origin — where the component came from (npm, PyPI, Maven, GitHub)
- Known CVEs — critical for security diligence, often bundled with licence data
How to generate one today — at zero cost
You do not need a paid tool to start. The following free tools cover the most common stacks:
- Syft (Anchore, Apache 2.0 licence):
syft <image>:<tag> -o cyclonedx-json > sbom.json. Covers container images, file systems, source directories. Supports Go, Java, Python, Node, Ruby, .NET. - Trivy (Aqua Security, Apache 2.0):
trivy fs . --format cyclonedx --output sbom.json. Integrates natively with GitHub Actions and GitLab CI. - cdxgen: Generates CycloneDX SBOMs directly from
package.json,pom.xml,requirements.txt, and similar manifest files.
Run one of these tools as a gate in your CI/CD pipeline on every release branch merge. Store the SBOM as a release artefact — alongside your Docker image digest — in your artefact registry. In a data room, you can then produce a dated, version-matched SBOM in under two minutes.
Paid options (worth evaluating at Series A+): FOSSA, Snyk, and Black Duck offer richer policy enforcement, automatic licence obligation summaries, and legal-grade reports. Pricing for a startup starts around Rs. 42,000–84,000 per month (approximately $500–$1,000). That is a fraction of one week of external counsel time.
The diligence conversation without an SBOM
Without an SBOM, a diligence question like "Does your product contain any AGPL-licensed code?" forces your engineers to reconstruct the answer manually — trawling through package-lock.json, go.sum, and Dockerfile layers under time pressure. Expect two to four weeks of engineering time instead of two minutes. That delay costs you deal momentum and investor confidence.
DO 2: Map Every Dependency to Its Licence Tier
Licence risk is not binary. It sits on a spectrum from "use freely in any commercial product" to "publish your entire source code or face injunction." You need a three-tier mental model before you write a single line of code that touches an external package.
Tier 1 — Permissive (generally safe for closed-source commercial use)
- MIT: Use, modify, distribute, sublicense. Only obligation: retain the licence notice and copyright statement in the distributed product.
- Apache 2.0: Same as MIT, plus an explicit patent grant. The patent grant is significant — it protects you against patent claims from contributors. Preferred for enterprise-grade dependencies.
- BSD 2-Clause / BSD 3-Clause: Effectively equivalent to MIT. The 3-Clause version adds a non-endorsement restriction.
Practical rule: Tier 1 components can go straight onto your approved list. Your SBOM generator flags them; your policy auto-approves them.
Tier 2 — Weak copyleft (link carefully)
- LGPL (GNU Lesser GPL): You can link against an LGPL library from proprietary code without triggering disclosure obligations if the link is dynamic and the user can relink with a modified version of the library. Static linking triggers stronger obligations.
- MPL 2.0 (Mozilla Public Licence): File-level copyleft. You must publish modifications to MPL-licensed files, but can keep your own files proprietary.
Practical rule: Flag all Tier 2 dependencies for legal review before shipping. Confirm the linking model. Do not statically bundle LGPL code without advice.
Tier 3 — Strong copyleft (highest risk for a closed SaaS)
- GPL 2.0 / GPL 3.0: If you distribute a compiled binary that statically or dynamically links GPL code, you must release the complete corresponding source code of the combined work under GPL. "Distribute" means shipping a binary to a customer — it includes mobile apps and on-premise deployments.
- AGPL 3.0: Extends GPL's obligation to network use. If you run AGPL-licensed software on a server and users interact with it over a network (i.e., your SaaS product), you must publish the complete source code. This is the most dangerous licence category for Indian SaaS startups. Tools like Elasticsearch (before the licence switch) and early MongoDB were AGPL.
Practical rule: No Tier 3 component enters your product without a written legal opinion, a commercial licence alternative, or confirmed architectural isolation (see DON'T 1 below).
DO 3: Build a Lightweight Developer Approval Workflow
Engineers make dependency decisions dozens of times a week. Without a documented workflow, a well-meaning developer can introduce an AGPL component on a Thursday afternoon, and it ships to production on Friday. By Monday, your network-use disclosure obligation is live.
A lightweight approval workflow does not mean slowing down engineering. It means adding a structured gate that takes one to two minutes for Tier 1 packages and a clear escalation path for everything else.
Step-by-step: Implementing an OSS approval workflow
- Create a curated allowlist. Maintain a
APPROVED_LICENSES.mdor a policy file in your dependency manager. Tools like FOSSA and Snyk allow you to define a policy that auto-approves Tier 1 identifiers (MIT,Apache-2.0,BSD-2-Clause,BSD-3-Clause,ISC) and fails the build on anything outside the list.
- Add a PR template field. In your
.github/PULL_REQUEST_TEMPLATE.md, add a mandatory checkbox: "I have confirmed all new dependencies are on the approved licence list or have been escalated for legal review." This creates a paper trail and shifts the obligation to the developer who introduces the dependency.
- Define a fast-track escalation. For Tier 2 and Tier 3 packages, the developer opens an issue tagged
oss-review. The engineering lead reviews within 48 hours using the unknown node summary plus your internal counsel's input. Decision is documented in the issue and closed — no committee, no delay beyond two business days for most cases.
- Run licence checks in CI. Configure
license-checker(Node),pip-licenses(Python),go-licenses(Go), or equivalent as a mandatory CI step. Build fails on unapproved licences. This catches transitive dependencies — the packages your packages depend on — which are the most common source of surprise violations.
- Review the allowlist quarterly. Licences change. ElasticSearch switched from Apache 2.0 to a proprietary SSPL in January 2021. Terraform moved to BUSL in August 2023. What was approved last year may not be approved today. A calendar reminder for a 30-minute quarterly review is sufficient.
DON'T 1: Mix Copyleft and Proprietary Code Without Isolation
The most common and most expensive compliance mistake is architectural: embedding a Tier 3 component directly into a closed-source codebase. Here is how the risk manifests in practice.
The AGPL SaaS trap
Suppose your engineering team uses a popular AGPL-licensed graph database library to power a network analysis feature in your B2B SaaS product. The library is linked into your application server, which users access via a REST API. Under AGPL Section 13, you are required to offer users the source code of the complete corresponding application — including your proprietary business logic — when they interact with it over the network. The obligation is triggered by the interaction, not by distribution of a binary.
What isolation looks like: Run the AGPL component as a separate, standalone microservice behind an API boundary. Your proprietary code calls it over HTTP or gRPC. The AGPL disclosure obligation is satisfied by publishing only the microservice's source code — not your core application. This architectural separation must be genuine and documented. A single-process monolith with the AGPL library statically compiled in does not qualify.
What you must never do
- Strip licence notices. Every open source licence requires that the copyright notice and licence text be preserved in any redistribution. Removing them is both a licence violation and an infringement under Section 51 of the Copyright Act 1957. Carry the
NOTICESorTHIRD_PARTY_LICENSESfile in every distribution. - Copy Stack Overflow code without checking. Stack Overflow content published before 1 February 2016 is under CC BY-SA 2.5; content after that date is under CC BY-SA 4.0. Both are copyleft. Before pasting more than a trivial snippet into production code, confirm the contributor held the copyright to contribute and understand the licence implications.
- Accept contributor pull requests without a licence declaration. If a contributor submits code under no stated licence, the default position under Indian and international copyright law is that they retain all rights and grant you nothing. Use a Contributor Licence Agreement (CLA) or the Developer Certificate of Origin (DCO) process for all external contributions.
DON'T 2: Treat Open Source as Free of Financial Obligation
Open source is free of licence fee, not free of obligation or cost. Founders who conflate the two consistently underinvest in compliance until a crisis forces them to spend far more than proactive hygiene would have cost.
The real cost budget
A realistic annual compliance budget for a 20-50 engineer Indian startup in FY 2026-27:
| Item | Annual cost (approx.) |
|---|---|
| Licence scanner (Syft/Trivy, self-hosted) | Rs. 0 |
| CI/CD integration engineering time (one-time setup) | Rs. 80,000–1,20,000 |
| Policy-grade SCA tool (FOSSA/Snyk, if needed) | Rs. 5,00,000–10,00,000 |
| External counsel — annual OSS policy review | Rs. 1,50,000–2,50,000 |
| Quarterly internal review committee time (4 hrs × 4) | Rs. 80,000–1,50,000 |
| Total proactive budget | Rs. 7,10,000–15,20,000 |
Compare that to the reactive cost: three senior engineers spending six weeks on remediation before a Series B close costs approximately Rs. 9,00,000 in loaded salaries alone (3 engineers × 6 weeks × Rs. 1,50,000 per engineer per month), plus Rs. 3,50,000 or more in external counsel fees for a remediation opinion. If the deal delays by eight weeks, the opportunity cost in bridge financing or missed market timing adds further.
Security patching is not optional either. When a CVE hits a library you embed (Log4Shell in December 2021 is the canonical example), the cost of emergency patching across a disorganised codebase — without an SBOM to tell you exactly which services are affected — dwarfs the cost of maintaining one.
Common Mistakes That Surface in Due Diligence
These are the issues that routinely surface in OSS legal reviews before a fundraise or M&A transaction. Each one is avoidable.
- No SBOM at all. The diligence team asks for it; the engineering team spends two weeks producing a manual inventory that is still incomplete. Deal timeline slips.
- Transitive dependency blindness. The founder says, "We only use MIT packages." The scanner finds an AGPL package three levels deep in the dependency tree — a package their package depends on. They had never looked.
- Licence version confusion. GPL 2.0 and GPL 3.0 are not compatible. Mixing them creates an unlicensed combined work. Always pin the exact version in your SBOM:
GPL-2.0-onlyversusGPL-2.0-or-later. - Dual-licence package misunderstanding. Many commercial OSS projects (MongoDB, Elasticsearch SSPL, MariaDB Business Source Licence) offer open source for non-commercial use and a paid commercial licence for production SaaS use. Using the open source edition in a revenue-generating product without a commercial licence is a violation. If you are generating revenue, you are almost certainly in the commercial-use category.
- Employee-generated code during moonlighting. If a developer contributes to your codebase while employed elsewhere, their employer's IP assignment agreement may claim ownership of that code. Founders should obtain written IP assignment confirmations from all founders and early employees, and include a representation in employment agreements that the employee is not under a conflicting obligation.
- GitHub Copilot and AI-generated code. Code suggestions from AI models trained on open source repositories raise unresolved licence contamination questions. Until case law and policy mature, maintain a log of material AI-generated snippets and have them reviewed before production use.
Worked Example: The Cost of an AGPL Violation at Series B
Scenario: A B2B analytics SaaS with 40 employees is closing a Series B round of Rs. 80 crore led by a Singapore-based VC with US LP commitments. Standard diligence is underway.
What the diligence team finds: The core query engine — the proprietary heart of the product — is built around an AGPL 3.0-licensed columnar storage library. The library is statically compiled into the main application binary. Every customer who calls the product's API over the network has, in theory, a right under AGPL Section 13 to receive the complete source code of the combined application — including the founders' proprietary algorithms.
Immediate consequences:
- The lead investor's legal counsel issues a "material IP risk" finding.
- Close is conditioned on remediation before the second tranche (Rs. 40 crore) is released.
- The company must either: (a) migrate to an Apache-licensed alternative query engine, (b) negotiate a commercial licence with the AGPL library's maintainer, or (c) restructure the architecture to isolate the AGPL component behind a microservice boundary.
Remediation cost:
| Item | Cost |
|---|---|
| 3 senior engineers × 8 weeks × Rs. 1,50,000/month | Rs. 9,00,000 |
| QA and regression testing | Rs. 2,00,000 |
| External counsel — remediation legal opinion | Rs. 3,50,000 |
| Commercial licence negotiation (if chosen) | Rs. 8,00,000–25,00,000/year |
| Deal delay — bridge financing interest (8 weeks @ 15% p.a. on Rs. 10 crore drawdown) | Rs. 2,30,000 |
| Total minimum remediation cost | Rs. 16,80,000+ |
The proactive cost of a proper OSS policy — an SBOM at every release plus a CI licence check — would have caught the AGPL dependency on day one. Total proactive cost: Rs. 0 in tool spend (using Syft) and approximately four hours of engineering setup time.
Key Takeaways
- Generate an SBOM at every release. Use Syft or Trivy in your CI pipeline. Store it as a versioned release artefact. This single habit resolves 80% of diligence friction.
- Classify every dependency before it enters the codebase. MIT/Apache 2.0 is Tier 1 (auto-approve). LGPL/MPL is Tier 2 (review linking model). GPL/AGPL is Tier 3 (legal opinion or architectural isolation required).
- AGPL is the highest-risk licence for a SaaS business. Network use triggers the disclosure obligation. Isolation behind a genuine API microservice boundary is the standard mitigation.
- Build a PR-level approval gate for new dependencies. A template checkbox, a CI licence scan, and a 48-hour escalation path is all you need. No committees, no bureaucracy.
- Budget for OSS compliance like you budget for cloud infrastructure. Rs. 7–15 lakh per year in proactive spend prevents Rs. 17+ lakh in reactive remediation — and that excludes the valuation impact of a failed diligence finding.
- Preserve every licence notice and attribution file. Stripping them is a Copyright Act 1957 violation, not just a licence breach. Maintain a
THIRD_PARTY_LICENSESfile in every distributed build. - Audit transitive dependencies, not just direct ones. Your SBOM tool does this automatically. Your manual review never will.
