Five open source compliance do's and don'ts for Indian startups in 2026 — SBOMs, license mapping, copyleft isolation, and developer approval workflows.
Open source software powers the entire Indian startup stack, but a single careless dependency can derail a Series B diligence or expose you to copyright claims. With the Indian Patent Office and courts increasingly engaged with software IP disputes, and acquirers demanding clean Software Bills of Materials, open source compliance is now a board-level concern. Here are the five do's and don'ts every founder must internalise in 2026.
Do: Maintain a Live Software Bill of Materials
Generate an SBOM for every product release using tools like Syft, Trivy, or your CI's native scanner. The SBOM lists every component, version, and license. Investor and acquirer diligence in 2026 starts with this artefact, and without one you will struggle to answer basic questions in the data room.
Do: Map Each License to a Permitted Use
Permissive licenses such as MIT, Apache 2.0, and BSD are generally safe for commercial use. Copyleft licenses like GPL and AGPL impose obligations that can require you to release derivative source code. The risk depends on how you link and distribute — a static link to GPL code in a distributed binary is very different from a Docker container running AGPL software behind a SaaS.
Don't: Mix License Categories Without Legal Review
- Avoid embedding AGPL components inside a closed-source SaaS without isolation
- Never strip license notices or attribution files from third-party code
- Do not copy snippets from Stack Overflow or GitHub without checking the license
- Reject contributor pull requests that lack a clear license declaration
Don't: Treat Open Source as Free of Cost
Open source is free of license fee, not free of obligation. Compliance, security patching, and indemnity gaps cost real engineering hours. Build a budget line for license scanning tools, an internal review committee, and an external counsel review before any major release.
Do: Build an Internal Approval Workflow
Engineers should not introduce new dependencies unilaterally. A lightweight approval workflow — pull request templates that demand license confirmation, a curated list of pre-approved packages, and a fast escalation for grey-zone licenses — keeps speed without sacrificing safety.
Conclusion
Open source compliance is a discipline, not a one-time audit. Keep an SBOM, classify licenses, isolate copyleft components, and approve new dependencies through a documented workflow. Founders who treat it as core engineering hygiene preserve enterprise value and avoid surprise legal claims at the worst possible moment.
