At a glance
| Legal basis | Open source licences are copyright licences, enforceable under the Copyright Act, 1957 and contract law |
|---|---|
| High-risk licences | GPL, LGPL, AGPL, SSPL and other copyleft or source-available terms |
| Permissive licences | MIT, BSD and Apache 2.0, which still require notices and attribution |
| SBOM guidance | CERT-In Technical Guidelines on SBOM (2024), updated in July 2025 to cover AI, hardware and cryptographic BOMs |
| Standards | SPDX (ISO/IEC 5962) and CycloneDX formats; OpenChain ISO/IEC 5230 for programmes |
| When it matters most | Product launch, customer audits, funding rounds and M&A |
Our open source services
Codebase audit
Scan and manual review to identify components, licences, snippets and conflicts, with a risk-rated report.
SBOM
Generation and review of software bills of materials in SPDX or CycloneDX, aligned with CERT-In guidance.
Policy and governance
Open source policy, approval workflows, contribution rules and developer training.
Remediation
Practical fixes: replace a component, change the architecture, add notices or release source correctly.
M&A and investment diligence
Target audits, disclosure schedules and warranties for buyers, sellers and investors.
Customer and outbound licensing
Choosing a licence for your own projects and handling customer compliance questionnaires.
Common open source risks
- Distributing software that links to GPL code without offering corresponding source
- Running modified AGPL software as a network service without sharing the modifications
- Missing copyright notices, licence texts and NOTICE files in shipped products
- Licence incompatibility, such as combining GPLv2-only code with Apache 2.0 code
- Source-available licences that restrict commercial or competing use
- Unknown code snippets copied from public repositories without licence checks
How an audit works
Scope
Agree the products, repositories and distribution models in scope.
Scan
Automated detection of packages, dependencies and code snippets, including transitive dependencies.
Legal review
Each licence is analysed against how the component is used, linked, modified and distributed.
Report
A risk-ranked report with clear actions, not just a list of licences.
Remediate and maintain
Fixes, notice files, SBOM and an ongoing policy so compliance keeps pace with releases.
Frequently asked questions
Is open source software free to use commercially?
Usually yes, but free does not mean without conditions. Every licence carries obligations, from simple attribution under MIT to sharing source code under the GPL and AGPL. The obligations depend on how you use and distribute the software.
Does using GPL code force me to open source my product?
Not always. It depends on whether you distribute the software and how your code combines with the GPL component. Internal use and some forms of separation may not trigger the obligation. A legal review of the architecture is the only safe answer.
What is an SBOM and is it mandatory in India?
A software bill of materials lists every component in your software with its version, supplier and licence. CERT-In's guidelines recommend SBOMs, especially for software supplied to government and the public sector. Many enterprise customers now require them contractually.
Why do investors ask about open source?
Licence violations can force code disclosure, product changes or claims after closing. Investors and acquirers therefore ask for audits, warranties and disclosure schedules during due diligence.
How often should we audit?
At major releases, before funding or acquisition, and continuously through automated scanning in your build pipeline backed by a written policy.
Talk to Inovatree about open source compliance
Inovatree Consultants LLP works from Delhi NCR, Mumbai and Kolkata with clients across India. Learn more about the firm on inovatree.in:
Related services
Last reviewed 24 October 2026. This guide summarises the law in general terms. Every matter turns on its own facts, so take advice before acting.