Open Source License Compliance in India — Complete Guide for Companies 2025

Modern software is built on open source — most companies use thousands of open source components. But "free" doesn't mean "no obligations." Open source licenses come with legal requirements that, if violated, can lead to serious consequences. This guide covers comprehensive open source compliance for Indian companies.

Open Source Overview

The Reality of Modern Software

• 90%+ of modern apps contain open source
• Average app has 100-1000+ open source components
• Most code in commercial products is open source
• Compliance is critical legal obligation

Why Compliance Matters

• Avoid lawsuits and damages
• Protect your proprietary code
• M&A due diligence requirement
• Investor expectations
• Customer enterprise contracts
• Reputation protection
• Community goodwill

Famous Compliance Cases

• BusyBox vs Westinghouse — GPL violation, source code shared
• Free Software Foundation actions — Multiple companies forced to comply
• Cisco/Linksys settlement — GPL component issues
• VMware vs SFC — Long Linux kernel litigation
• Indian companies — Increasingly facing scrutiny

Major Open Source License Types

Permissive Licenses (Most Business-Friendly)

MIT License

• Key requirement: Include copyright notice + license text
• Restrictions: Minimal
• Best for: Commercial use, modifications
• Examples: jQuery, Bootstrap, Express.js

Apache 2.0

• Key requirement: Notice + license + state changes + patent grant
• Restrictions: Patent termination clause
• Best for: Commercial use, patent protection
• Examples: Apache projects, Android, TensorFlow

BSD (2-Clause, 3-Clause)

• Key requirement: Copyright notice + license
• Restrictions: Don't use names of contributors
• Best for: Maximum flexibility
• Examples: FreeBSD, NumPy, Google projects

Copyleft Licenses (More Restrictive)

GPL v2/v3 (Strong Copyleft)

• Key requirement: Distributed derivatives must be GPL
• "Viral" effect: Modifications must be shared as GPL
• Best for: Open source projects, not proprietary
• Examples: Linux kernel, GIMP, MariaDB

LGPL (Lesser GPL)

• Key requirement: Modifications to LGPL code must be LGPL
• Linking allowed: Can link from proprietary code
• Best for: Libraries used by proprietary software
• Examples: GTK+, FFmpeg components

AGPL (Network Copyleft)

• Key requirement: Even SaaS deployment triggers source sharing
• Strong network effect: Users via network get GPL rights
• Best for: Avoiding in commercial SaaS
• Examples: MongoDB (until 2018), Mastodon

License Compatibility Matrix

GPL Compliance — Critical Issues

What GPL Requires

1. Source code availability — For binaries distributed
2. License notice — In source and documentation
3. License text included
4. Same license for derivatives
5. No additional restrictions
6. Patent grant (GPL v3)
7. Anti-tivoization (GPL v3)

What Triggers GPL Obligations

• Distribution of binary including GPL code
• Static linking with GPL library
• Modifications to GPL software
• Derivative works

What Generally Doesn't Trigger

• Internal use only (no distribution)
• SaaS deployment of GPL (but AGPL different!)
• Communication via clear separation
• Process-level interaction

"Mere Aggregation" vs "Derivative Work"

Mere Aggregation (No GPL Trigger)

• Different programs in same archive
• Programs running in separate processes
• No tight integration

Derivative Work (GPL Triggers)

• Statically linked code
• Dynamically linked with tight integration
• Code based on GPL code
• Significant code copying

Permissive License Compliance

MIT License Compliance

1. Include copyright notice in source
2. Include license text in distribution
3. Acknowledgment in documentation
4. That's it!

Apache 2.0 Compliance

1. Include NOTICE file (if present)
2. Include license text
3. Note any changes made
4. Patent grant (automatic)
5. No misleading attribution

BSD License Compliance

1. Copyright notice retention
2. License text in distribution
3. Don't use contributor names without permission (3-clause)

Building OSS Compliance Program

Step 1: Inventory

Track ALL Dependencies

• Direct dependencies in package.json/pom.xml/etc.
• Transitive dependencies (deps of deps)
• Both production and development
• Frontend and backend

Tools for Inventory

• npm: package-lock.json analysis
• Maven: dependency:tree
• SBOM tools (CycloneDX, SPDX)
• SCA (Software Composition Analysis) tools
• FOSSology, Black Duck, WhiteSource

Step 2: License Identification

• Identify license for each dependency
• Check for license combinations
• Watch for unusual licenses
• Flag license incompatibilities

Step 3: Risk Assessment

• Categorize by license restrictiveness
• Evaluate against your use case
• Identify GPL/AGPL components in proprietary product
• Flag unusual or unfamiliar licenses

Step 4: Remediation

• Replace problematic dependencies
• Add required notices
• Update documentation
• Make required source available

Step 5: Process & Training

• Approval process for new dependencies
• Developer training
• Regular audits
• Documentation maintenance

Step 6: Documentation

NOTICE File / OPEN_SOURCE_LICENSES File

• List all open source components
• Include their licenses
• Required notices
• Available with product

SBOM (Software Bill of Materials)

• Comprehensive component list
• Industry standard formats (SPDX, CycloneDX)
• Increasingly required by enterprise customers
• Enables vulnerability tracking

Common Mistakes

1. Not Tracking Transitive Dependencies

Direct deps are visible. But each dep has its own deps, and so on. Track ALL.

2. Mixing GPL with Proprietary

Common mistake — using GPL libraries in commercial products without compliance.

3. Missing Attribution

Most open source requires attribution. Skipping creates compliance violations.

4. Not Documenting Modifications

Apache 2.0 requires noting changes. Often overlooked.

5. AGPL in SaaS

Network use of AGPL triggers source sharing. Avoid in proprietary SaaS.

6. License Compatibility Issues

Some licenses don't combine well. GPL + permissive often workable, but specific combinations matter.

7. Ignoring Patent Grants

Apache 2.0 includes patent grants — acceptance has implications.

8. No Compliance Process

Ad-hoc compliance leads to gaps. Need formal process.

Compliance Tools

Indian Context

Indian Companies & OSS

• TCS, Infosys, Wipro — major contributors
• Indian startups heavy users
• Government using OSS (eSign, Digilocker)
• Increasing compliance scrutiny

Legal Landscape in India

• OSS licenses enforceable under Copyright Act
• No specific OSS legislation
• Courts treating OSS like other contracts
• Increasing case law

Conclusion

Open source license compliance isn't optional — it's a fundamental software development practice with real legal consequences. The combination of comprehensive inventory, license identification, risk assessment, and ongoing process management protects companies from costly violations. While the initial setup requires investment, ongoing compliance is much cheaper than non-compliance consequences. With increasing enterprise customer expectations and growing legal scrutiny, building strong OSS compliance is essential for any software-using company. Make compliance a core development practice, not an afterthought.

Frequently Asked Questions