Complete Guide to Open Source Licenses (MIT, GPL, Apache)

Imagine spending months building a revolutionary library, pushing it to GitHub, and waking up to find a tech giant using your code in a closed‑source product without giving you a dime or a credit line. Frustrating? That’s exactly why open source licenses exist — they are the silent guardians of your work.

Whether you’re a solo developer releasing your first npm package or a startup CTO architecting the next unicorn, understanding the difference between MIT, GPL, and Apache licenses isn't just legal jargon—it's a strategic business decision. In this complete guide, we’ll cut through the complexity with plain English explanations, real‑world scenarios, and a simple framework to pick the perfect license for your next project.

🔍What Are Open Source Licenses?

An open source license is a legal contract between the creator of software and the end‑user. It grants permission to use, modify, and share the code—but the specific permissions and restrictions vary wildly depending on the license you choose.

Think of it like a “Terms of Service” for your code. Without a license, your code is technically “All Rights Reserved” under copyright law. That means nobody can legally use, copy, or modify it, even if it’s sitting in a public GitHub repo.

• Permissive Licenses (MIT, Apache, BSD): Minimal restrictions. “Do whatever you want, just give me credit.”
• Copyleft Licenses (GPL, AGPL): “If you use my code, your code must be open too.”

⚖️ Why Choosing the Right License Matters

Ignoring licensing isn't just a legal risk—it’s a missed opportunity for community growth.

• Adoption vs. Control: Permissive licenses (MIT) maximize adoption (React uses MIT). Copyleft licenses (GPL) ensure the software remains free forever (Linux uses GPL).
• Corporate Compatibility: Many large companies (Google, Microsoft) have strict policies against using GPLv3 code in their proprietary products due to “patent retaliation” clauses. They much prefer MIT or Apache 2.0.
• Legal Protection: The Apache 2.0 license is the only one of the big three that explicitly grants a patent license, protecting you from being sued by contributors over patent claims.

📜 The Big Three: MIT, GPL, and Apache Explained

1. MIT License: The Simple & Permissive Choice

Tagline: “I made this. You can use it for anything. Just don’t sue me.”

The MIT License is the most popular open source license on GitHub. It’s short, elegant, and places almost no restrictions on the user.

• Obligations: Keep the copyright notice and license text.
• Can I use it in a closed‑source app? ✅ Yes.
• Do I have to share my changes? ❌ No.
• Famous Users: React, Node.js, jQuery, .NET Core, Rails.

2. GNU GPL License: The Viral Protector

Tagline: “Free software stays free. You must share alike.”

The GNU General Public License (GPL) is the cornerstone of the Free Software Foundation. It has a strong copyleft provision: if you distribute software that includes GPL code, you must release the source code of the entire combined work under the GPL license.

• Obligations: Distribute source code; include license and copyright notice; state changes.
• Can I use it in a closed‑source app? ❌ Only if it's for internal use only (no distribution).
• Do I have to share my changes? ✅ Yes, if you distribute the software.
• Famous Users: Linux Kernel, Git, WordPress, MySQL.

3. Apache License 2.0: The Corporate Favorite

Tagline: “You can use this freely, and I promise not to sue you over patents.”

The Apache License 2.0 is a permissive license like MIT, but with a critical legal upgrade: an explicit grant of patent rights. This makes it the go‑to choice for large enterprises and foundations (Apache Foundation, Google, Android).

• Obligations: Include copyright, license, and state significant changes. Preserve NOTICE file.
• Can I use it in a closed‑source app? ✅ Yes.
• Do I have to share my changes? ❌ No.
• Patent Protection: Users are protected from patent lawsuits from contributors regarding the code.
• Famous Users: Android OS, Kubernetes, Apache Web Server, TensorFlow.

📊 Comparison Table: MIT vs GPL vs Apache

🧭 How to Choose the Right License (Flowchart Logic)

Still confused? Walk through this decision tree:

1. Do you care if someone makes a proprietary version of your software and sells it?
   • Yes, I want it to remain open forever. → Choose GPLv3.
   • No, I want maximum adoption. → Go to step 2.
2. Are you contributing to a large corporate project or worried about patent lawsuits?
   • Yes, I want explicit legal protection. → Choose Apache 2.0.
   • No, I just want simple attribution. → Choose MIT.

💡 Suggested Image: Add an infographic flowchart here showing the decision path from MIT → Apache → GPL.

🌍 Real‑World Use Cases & Why They Chose That License

• Linux Kernel (GPLv2): Linus Torvalds chose GPLv2 specifically (not v3) because he wanted to ensure drivers and modifications remained open source, but he disagreed with GPLv3's anti‑Tivoization clause for embedded devices.
• React (MIT): Facebook chose MIT to encourage massive adoption. It worked—React dominates the web. However, they initially had a controversial “BSD+Patents” clause which they later dropped due to community backlash.
• Android (Apache 2.0): Google deliberately chose Apache 2.0 for the Android Open Source Project (AOSP). It allows phone manufacturers (Samsung, Xiaomi) to modify the OS and keep their customizations (One UI, MIUI) closed source, while still protecting Google’s patents.

⚠️ Common Licensing Mistakes (And How to Avoid Them)

• Mistake 1: Not including a license file.
  Fix: Always add a LICENSE or COPYING file in your root directory.
• Mistake 2: Mixing incompatible licenses.
  Example: Using GPLv3 code inside an MIT project means the entire project likely must be GPLv3. Fix: Use tools like license-compatibility-checker or FOSSA.
• Mistake 3: Changing the license retroactively.
  Reality: You can change the license for future versions, but you cannot revoke the rights of people who already downloaded the MIT/GPL code.
• Mistake 4: Forgetting to add copyright headers to source files.
  Fix: Every .js or .py file should have a one‑line comment: // Copyright (c) 2026 Your Name. Licensed under MIT.

🛠️ Step‑by‑Step: Applying a License to Your GitHub Project

1. Navigate to your repository root.
2. Create a new file named LICENSE (no extension).
3. GitHub provides a handy template selector: Click “Add file” → “Create new file” → Type “LICENSE” → Click “Choose a license template” on the right sidebar.
4. Select MIT, GPL‑3.0, or Apache‑2.0 from the dropdown. GitHub will auto‑populate the correct legal text with your name and year.
5. Update the package.json (if Node.js project): "license": "MIT".
6. Update the README.md: Add a badge!
   [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)

✅ Key Takeaways

• MIT: Simple, do‑whatever‑you‑want. Best for libraries and maximum reach.
• Apache 2.0: MIT + Patent Shield. Best for enterprise and platforms (Kubernetes, Android).
• GPL: Viral copyleft. Best for ensuring user freedom and preventing proprietary forks (Linux, Git).
• No License = No Permission. Always include one.

💬 Frequently Asked Questions (FAQ)

1. Can I use MIT licensed code in a commercial, closed‑source app?

Yes. The MIT license is business‑friendly. You only need to keep the copyright notice intact somewhere in your app's documentation or "About" section.

2. Does GPL force me to open source my entire website if I use a GPL library?

No (usually). The GPL is triggered upon distribution. If you run a WordPress (GPL) site on your server and users only interact with it via a browser, you are not distributing the code to them, so you do not have to release your custom theme code. However, if you use AGPL code, you must share the source even for server‑side use.

3. What is the difference between GPLv2 and GPLv3?

GPLv3 added “Installation Information” requirements (anti‑Tivoization) to prevent hardware lock‑down, and it includes explicit patent license grants and compatibility improvements with Apache 2.0.

4. Can I change the license of my own project later?

You can change the license for future contributions and releases. However, any version of the code you already published under MIT remains MIT forever. Users can legally fork the last MIT commit and continue using it under those terms.

5. Why does Google prefer Apache 2.0 over MIT?

Because of the patent grant. Apache 2.0 explicitly states that contributors grant a license to any patents they hold that cover the code. This prevents a contributor from contributing code and later suing users for patent infringement—a huge legal risk for big corporations.

🗣️ Over to You

Which license do you usually default to? Have you ever faced a licensing nightmare with a client or an open source dependency? Share your war stories in the comments below—I’d love to hear how you navigated it!

Enjoyed this post? Don't forget to bookmark it and share it with a developer friend who still thinks "I'll add the license later" is a valid strategy.