What types of contracts does AMLEGALS handle?

AMLEGALS provides comprehensive contract advisory across 73+ 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

A fast growing SaaS company integrated a popular open source library into its core platform without reviewing the licence terms. Months later, a competitor identified the use of GPL code and raised the alarm with the company’s major enterprise customer, threatening not just a lawsuit but also reputational harm and the loss of a key contract. Many businesses mistakenly assume that open source software is free to use in any manner, or that basic attribution is enough. They overlook compliance obligations, reciprocal licensing, and the risks of inadvertently open sourcing their own proprietary code. This creates both IP exposure and commercial risk, especially when scaling or seeking investment. AMLEGALS TCL Framework ensures technical diligence by mapping dependencies, clarifies commercial impacts of open source compliance on product strategy, and delivers legal clarity on attribution, sublicensing, and mitigation of viral licence risks. Our approach preserves your IP value and secures commercial relationships from OSS pitfalls. Indian software companies face regulatory scrutiny under the Copyright Act 1957 and increasing audits by customers or partners. Failure to comply with open source terms can lead to injunctive relief, statutory damages, and termination of commercial agreements. Recent enforcement by global tech companies and the Indian courts has made OSS compliance a boardroom issue for SaaS and IT service providers alike.

Key Takeaways

These agreements clarify rights and obligations related to use modification and distribution of open source software.
They include compliance requirements to avoid license violations and potential legal risks.
They govern contribution processes and commercial exploitation of open source components.

Key Considerations

1

License Identification

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

2

License Categorization

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

3

Compliance Requirements

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

4

Contribution Policies

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

5

Commercial Integration

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

6

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.”

AM

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.

Every Open Source negotiation has a turning point.

The difference between a contract that protects and one that exposes often comes down to three or four clauses. Identifying those clauses requires experience across the technical, commercial, and legal dimensions.

Schedule a Discussion Explore All 73+ Contract Types

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 Contract Types

Technology Licensing Agreements

Intellectual Property

A single vague clause in a technology license can turn years of innovation into an open invitation for disputes and lost revenue.

Software Licensing Agreements

Intellectual Property

Unchecked software licenses can trigger compliance nightmares or lock businesses out of mission critical systems overnight.

Employment Agreements

Employment & HR

Every promise to an employee is a risk—especially the ones that seem harmless at first.

IP Assignment Agreements

Intellectual Property

Assigning intellectual property without precision can leave both sides exposed to future challenges and silent claims.

Related Practice Areas

Intellectual Property Technology & IT Corporate

Open Source Licensing Agreements

Overview

Key Takeaways

Key Considerations

License Identification

License Categorization

Compliance Requirements

Contribution Policies

Commercial Integration

Due Diligence

Applying the TCL Framework

Technical

Commercial

Legal

Common Pitfalls

Unknown Components

License Misunderstanding

Attribution Omissions

Contribution Confusion

M&A Surprises

Every Open Source negotiation has a turning point.

Open Source Legal Framework

Practical Guidance

Frequently Asked Questions

What is the difference between permissive and copyleft licenses?

What is a Software Bill of Materials (SBOM)?

What is a Contributor License Agreement (CLA)?

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

Related Practice Areas

Need Assistance with Open Source?