What types of contracts does AMLEGALS handle?

AMLEGALS provides comprehensive contract advisory across 43+ contract types including Technology contracts (SaaS, AI/ML, Cloud Services), Data Privacy agreements (DPAs, DPDPA compliance), Commercial contracts (MSAs, Supply, Distribution), IP & Licensing, Employment agreements, and International Trade contracts.

What is the TCL Framework for contracts?

The TCL Framework is AMLEGALS proprietary approach that examines every contract through three lenses: Technical (understanding the operational realities), Commercial (aligning business objectives), and Legal (ensuring compliance and risk mitigation). This integrated approach ensures contracts that work in practice, not just on paper.

Does AMLEGALS handle DPDPA-compliant contracts?

Yes, AMLEGALS specializes in DPDPA-compliant contracts including Data Processing Agreements, Cross-Border Transfer Mechanisms, Data Sharing Agreements, and Consent Management frameworks. Our Vibe Data Privacy™ framework ensures comprehensive compliance with the Digital Personal Data Protection Act, 2023.

Can AMLEGALS help with AI and technology contracts?

Yes, AMLEGALS has dedicated expertise in AI/ML Contracts, AI Governance agreements, AI Training Data Licensing, SaaS Agreements, Cloud Services agreements, and System Integration contracts. We address emerging issues like algorithmic accountability, model ownership, and AI liability allocation.

What is the difference between permissive and copyleft licenses?

Permissive licenses (MIT, BSD, Apache 2.0) allow almost any use including incorporation into proprietary software, requiring mainly attribution and license notice inclusion. Copyleft licenses (GPL, LGPL, AGPL) require that derivative works be released under the same license with source code availability. LGPL provides a "weaker" copyleft allowing proprietary linking. AGPL extends copyleft to network use. The practical difference: permissive components can be freely incorporated into proprietary products; copyleft components may require proprietary code disclosure.

What is a Software Bill of Materials (SBOM)?

An SBOM is a comprehensive inventory of software components including: component names, versions, licenses, and dependencies. SBOMs enable: compliance verification (knowing what licenses apply), vulnerability management (tracking affected components), supply chain transparency, and due diligence support. Formats include SPDX, CycloneDX, and SWID. Automated tools can generate and update SBOMs. Increasing regulatory and contractual requirements (e.g., US Executive Order on cybersecurity) mandate SBOM provision.

What is a Contributor License Agreement (CLA)?

CLAs are agreements signed by contributors granting project maintainers rights to contributed code. CLAs may grant: copyright license or assignment, patent license, representation of authority to contribute, and indemnification. CLAs enable: relicensing flexibility (changing project license), patent peace (avoiding contributor patent assertions), and legal clarity (clean IP provenance). Alternative: Developer Certificate of Origin (DCO) provides lightweight attestation without formal agreement. Major projects (Apache, Linux, Kubernetes) use various contribution agreement approaches.

How should open source be addressed in M&A due diligence?

Open source due diligence should: inventory all open source components (using SCA tools and SBOM review); identify all applicable licenses; assess compliance status (attribution, source availability, notice requirements); evaluate copyleft exposure (proprietary code disclosure risks); review contribution history (employee contributions, CLAs signed); and estimate remediation costs if issues exist. Material compliance failures can affect valuation, require representations and indemnities, or become conditions precedent to closing. Post-closing compliance remediation may be required.

Open Source Licensing | OSS Compliance India | GPL MIT Apache

Overview

Open source software has become foundational to modern software development. Most commercial applications contain significant open source components—libraries, frameworks, tools, and infrastructure. This reliance creates legal obligations that vary dramatically based on which open source licenses apply. The difference between permissive licenses (MIT, BSD) and copyleft licenses (GPL, AGPL) can determine whether proprietary modifications are permissible.

Open source compliance requires systematic processes: identifying open source components in codebases; understanding the obligations each license imposes; ensuring compliance with notice, attribution, and source code requirements; and documenting compliance for due diligence purposes. Failure to comply can result in forced disclosure of proprietary code, injunctive relief, and reputational damage.

Beyond compliance, open source presents strategic opportunities. Contributing to open source projects can build reputation, influence standards, and access community innovation. Releasing software as open source can accelerate adoption and create ecosystem effects. Commercial open source business models—open core, dual licensing, support and services—can generate revenue while maintaining community engagement. Strategic open source decisions require integrating legal, technical, and business perspectives.

Key Considerations

License Identification

Systematic processes to identify all open source components and their applicable licenses.

License Categorization

Understanding permissive vs. copyleft licenses and their different obligation profiles.

Compliance Requirements

Attribution notices, source code availability, and modification disclosure obligations.

Contribution Policies

Employee contribution guidelines, CLAs/DCOs, and IP assignment for contributions.

Commercial Integration

Strategies for combining open source with proprietary software while maintaining compliance.

Due Diligence

Open source audits for M&A and investment transactions.

Applying the TCL Framework

Technical

Open source compliance begins with technical identification. Software composition analysis (SCA) tools scan codebases to identify open source components and their licenses. Understanding how components are linked—static vs. dynamic, library vs. service—affects license obligation analysis. Technical architecture decisions (modularization, API boundaries) can enable proprietary development while using copyleft components. Build and deployment processes must support compliance (license notices, source code archives).

Commercial

Open source creates commercial value while imposing obligations. Commercial decisions include: Which open source components provide more value than their compliance costs? How should proprietary products be structured to enable open source use? Should products be released as open source to accelerate adoption? What business models (support, enterprise features, hosting) can monetize open source? Commercial open source strategies require balancing community engagement against revenue generation.

Legal

Open source licenses are copyright licenses granting permission to use, modify, and distribute software subject to conditions. Permissive licenses (MIT, BSD, Apache 2.0) require mainly attribution. Copyleft licenses (GPL, LGPL, AGPL) require source code availability for derivative works or, for AGPL, network use. License compatibility affects combining differently licensed code. Contribution agreements (CLAs, DCOs) govern contributions to projects. Indian contract and copyright law applies to open source in India, though licenses are typically drafted under US/international frameworks.

“

"Open source is not free beer—it is free speech. The freedom comes with responsibilities. Organizations that treat open source as merely "free stuff" eventually discover that the obligations they ignored have consequences."

Anandaday Misshra

Managing Partner, AMLEGALS

Common Pitfalls

Unknown Components

Not knowing what open source is in the codebase makes compliance impossible. Automated scanning is essential.

License Misunderstanding

Treating GPL like MIT or assuming "free" means "no obligations" leads to compliance failures.

Attribution Omissions

Failing to include required notices, copyright statements, and license texts.

Contribution Confusion

Employees contributing to projects without clear IP assignment or employer authorization.

M&A Surprises

Discovering significant compliance issues during due diligence when remediation is costly or impossible.

Open Source Legal Framework

Open source licensing operates primarily through copyright law—licenses grant permissions that would otherwise require copyright holder consent. In India, the Copyright Act, 1957 provides the underlying framework. Open source licenses are contracts granting rights subject to conditions; Indian Contract Act principles apply to interpretation and enforcement. Key licenses include: MIT/BSD (permissive, minimal obligations), Apache 2.0 (permissive with patent grant), GPL family (copyleft requiring source availability), and AGPL (copyleft including network use). License proliferation has created compatibility challenges—OSI maintains the approved license list. The Open Source Definition provides principles underlying license approval. Courts globally have enforced GPL and other licenses through copyright claims.

Practical Guidance

Implement software composition analysis to identify all open source components.
Create a license policy categorizing licenses as approved, restricted, or prohibited.
Establish review processes for introducing new open source dependencies.
Maintain compliance documentation (SBOM, attribution files, source archives).
Define contribution policies addressing employee open source activity.
Conduct open source audits before significant transactions.

Frequently Asked Questions

Related Practice Areas

Intellectual Property Technology & IT Corporate

Need Assistance with Open Source?

Our team brings deep expertise in intellectual property matters.

Contact Our Team