Open Source Licenses Explained: MIT vs GPL vs Apache

You find a neat little JavaScript library on GitHub, copy a few functions into your startup's codebase, ship the feature, and move on. Six months later, during due diligence for a funding round, a lawyer asks which license that code was under. If your answer is "I didn't check," you might have a problem — and it's a more common problem in Indian startups than most founders realize.

Open source licenses aren't just legal boilerplate at the bottom of a GitHub repo. They're rules about what you're allowed to do with someone else's code, and getting them wrong can mean anything from an awkward email to a forced rewrite of your product before launch.

What a license is actually deciding

When a developer publishes code publicly, that code is still protected by copyright by default — "publicly visible" doesn't mean "free to use however you like." A license is the document that grants you specific permissions on top of that copyright: to use the code, modify it, redistribute it, or sell products built on it. No license attached to a repo, technically, means no permission at all, even if the code sits in a public GitHub repository.

Licenses generally fall into two families:

• Permissive licenses — let you do almost anything, including using the code in closed-source, commercial products, as long as you keep the original credit notice.
• Copyleft licenses — let you use and modify the code, but require that anything you build on top of it, or distribute alongside it, also be released under the same open terms.

That second category is where most surprises happen, because copyleft terms can be "viral" — they spread to code that touches them, depending on how tightly it's linked.

MIT, Apache, and GPL — the three you'll actually run into

Almost every dependency you'll pull into a project falls under one of these three, or something modeled closely on them.

1. MIT License — the simplest and most permissive. Use it, modify it, sell it, keep your own code closed — just keep the original copyright notice somewhere in your project. It's the default choice for most JavaScript and Python packages on npm and PyPI.
2. Apache License 2.0 — similarly permissive, but adds an explicit patent grant, meaning contributors can't later sue users of the code for patent infringement over that same code. It also requires you to document any significant changes you made to the original files. Popular with larger corporate-backed projects like Kubernetes and Android's core components.
3. GNU General Public License (GPL) — copyleft. If you distribute software that incorporates GPL-licensed code, you generally have to release your own source code under the GPL too. There's also the LGPL (Lesser GPL), a softer variant that only forces this requirement if you modify the library itself, not just link to it.

A license doesn't ask whether you read it. It just governs what happens whether you did or not.

Why this matters more for Indian founders and developers right now

India's software industry has quietly become a major consumer and producer of open source. Government-backed digital infrastructure like the DIGIT platform (used for municipal governance in several states) and pieces of the Open Network for Digital Commerce (ONDC) stack are released as open source, and the Ministry of Electronics and IT (MeitY) has actively pushed open-source adoption in public sector software procurement for years. Startups building on top of India's Digital Public Infrastructure — UPI-adjacent tooling, DigiLocker integrations, account aggregator frameworks — routinely inherit open-source dependencies with licenses they never audited.

This isn't hypothetical risk. Venture investors doing diligence on an Indian SaaS or fintech startup will ask for a software composition report — a list of every open-source component in the product and its license. A GPL-licensed component sitting inside what's supposed to be proprietary, closed-source IP can genuinely slow down or complicate a funding round, because it raises questions about whether the company can legally protect that code as a trade secret.

For developers releasing their own tools — and Indian engineers contribute heavily to global open source, including through programs like Google Summer of Code — picking a license isn't just a formality either. MIT or Apache if you want maximum adoption with no strings attached; GPL if you want to make sure improvements flow back to the community and nobody builds a closed, paid product on top of your free work without contributing back.

A quick sanity check before you ship

You don't need a law degree to stay reasonably safe. A few habits go a long way:

• Run a dependency scanner (tools like FOSSA, Snyk, or even GitHub's own dependency graph) before a major release or fundraising round.
• Treat "no license file in the repo" as a red flag, not a green light — legally, it usually means no permission granted.
• If you're building a commercial, closed-source product, be deliberate about avoiding copyleft dependencies (GPL and its stricter network-facing cousin, AGPL) in code paths that get compiled or linked directly into your product.
• When you open source your own project, pick the license based on what you actually want to happen to your code next — not just whatever the first template GitHub suggests.

None of this is about avoiding open source — it's about using it the way it's meant to be used, with the terms respected instead of ignored. The code being free to read was never the same thing as it being free of rules.