Open Source Licenses: Common Legal Misconceptions

Open source software is foundational to modern technology products. From early‑stage startups to scaled platforms, most technology stacks rely on multiple open source components – for example, Node.js for web and mobile applications, or MySQL for database infrastructure.

Despite this widespread adoption, in our experience advising technology businesses in India, open source licensing is still frequently misunderstood. Most Indian startup founders have a vague sense that open source software comes with some conditions. What is less understood is, which license triggers what conditions, and when such conditions kick in.

Open source licensing is one the main areas of interest during fundraising, acquisitions, and commercial partnerships. Investors, acquirers, and large enterprise customers scrutinise open source usage as part of their due diligence processes, and licence non‑compliance is viewed as a red flag, if the core business relies on the underlying software.  

This note addresses some of the common misconceptions relating to legal aspects of open source software licences.

Misconception 1: Open Source Means No Copyright

Open source is commonly equated with public domain and misunderstood as work in which copyright does not subsist. This is not the case.

Copyright exists in open source software. Open sourcing is not relinquishing of copyright, rather, it is the copyright owner granting permission or license for the use of the underlying code, subject to abiding by the terms and conditions that enable the continued use of the work by others.  

Misconception 2: Open Source Means Free to Use Without Restrictions

Open source software is often described as “free”, which leads to the assumption that it can be used without conditions. This is not fully correct.

Open source software may be available to use without a fee (even that need not necessarily be true). However, such use is subject to the terms of the relevant license under which it is made available, which may impose conditions on attribution, distribution, modification, or the manner in which the software is combined with proprietary code. For example, the Massachusetts Institute of Technology (MIT) license requires preservation of copyright notices and license text. The “free” part refers to not having to enter into a specific commercial use license.

Misconception 3: Copyleft Licences Automatically Require Open Sourcing the Entire Product

Copyleft licences are frequently viewed with broad suspicion, based on the belief that they require all proprietary code combined with them to to be made public. This is an oversimplification. Copyleft obligations vary by licence, and depend on factors such as the nature of integration, distribution models, and whether the software is modified or merely used as a dependency. For instance, Section 5 of of the GNU General Public License version 3(GPLv3), provides that any work based on a program covered under GPLv3 must also be licensed, as a whole, under GPLv3.

However, GPLv3 clarifies that a mere compilation of a covered work with other separate and independent works, without combining the works, does not extend GPLv3 terms to beyond the covered work. Further, GPLv3 clarifies that for the terms to apply, the covered work needs to “conveyed” in a manner that enables others to make or receive its copies, and that “mere interaction with a user through a computer network, with no transfer of a copy, is not conveying”. This is an important clarification. It means that running a GPLv3-covered code on a server and letting users interact with it over the web (like a website or a SaaS tool) is not considered to be “conveying” the work. In such cases, the source code does not need to be made public. Practically, the requirement to share source code arises when GPLv3-covered code is shared as a .exe file or a web or mobile application and delivered to another computer.

The situation changes if the GNU Affero General Public License (AGPL) is used. AGPL provides that if a work covered under the license is modified, the modified version must be prominently offered  “to all users interacting with it remotely through a computer network”. This is broad enough to cover website or SaaS tools as well, if a covered work has been modified. Unmodified AGPL use does not trigger this requirement. AGPL requires both modification and network distribution.

Therefore, assessment would need to be made on the terms of each license, to determine how a covered work can be used. A blanket avoidance of copyleft licences often results in suboptimal technical decisions.

Misconception 4: Code on Public Repositories Is Open Source

Another common assumption is that software hosted on platforms such as GitHub is open source and can be freely used in commercial products. However, hosting platforms are not substitutes for copyright licences. The right to use, modify, or distribute software depends entirely on the applicable licence terms. If a GitHub repository does not have a license file, no legal right to use, modify, or distribute that code, is being provided.

From a diligence perspective, unclear or missing licensing for code from a public repository is often flagged as a risk, particularly where the code forms a core part of the product offering.

Key Takeaways

Early‑stage companies often deprioritise licensing compliance on the assumption that it can be addressed later. However, licence issues may require urgent remediation involving code refactoring, replacement of dependencies, or substantial changes to distribution models. Addressing open source obligations at the development stage is significantly easier and less disruptive than attempting to resolve them retrospectively. This is no reason to avoid open source software. Rather, it is a call to use it with a clear understanding of the conditions applicable to such use.

.

Founders and developers of early stage businesses should consider running regular audits of their  open source dependencies, to identify applicable licenses, and determine whether there are specific conditions on combining, modifying or distributing the covered code. The audit must answer whether the business' use of the code results in the distribution of copies, modification, or remote network interaction with third parties. Understanding these triggers can help ensure that innovation remains legally secure, investor-ready, and strategically sound.