Open-Source Licenses: MIT, GPL & Apache Explained

You found the perfect library on GitHub, dropped it into your project, and shipped. Job done — right? Not quite. “Open source” is one of the most misunderstood phrases in software: it does not mean “public domain,” “free for anything,” or “no strings attached.” Almost every open-source project comes with a license, and that license is a real, binding set of conditions on how you’re allowed to use, change, and redistribute the code.

The good news is that the conditions are usually simple once someone explains them without the legalese. This guide walks through the licenses you’ll actually run into — MIT, Apache 2.0, and the GPL family — what each one requires of you, and how to both comply with other people’s licenses and choose a smart one for your own code. Because this is IPSurge, the focus stays on the part that matters: what this means for you as a developer or maker.

A gold open padlock on a code document with three ribbons branching to three license tags, on navy, symbolizing source code offered under a choice of open-source licenses — “Open source” doesn’t mean “no rules” — it means the rules are spelled out in a license you agree to when you use the code.

What an Open-Source License Actually Does

Here’s the thing most people miss: source code is protected by copyright automatically, the moment it’s written. By default, that means nobody else has permission to copy, modify, or distribute it. An open-source license is how the author grants you those permissions — but in exchange for following a few rules.

Track the cases yourself

Every current AI-copyright ruling — and the ones still being fought — lives in our AI Copyright Ruling Tracker. Filter by your creator type to see, in plain language, how each case affects your rights.

So a license isn’t a restriction bolted onto free code; it’s the thing that makes the code usable at all. Ignore the license and you’re not in some neutral zone — you’re technically infringing the author’s copyright, the same as if you’d copied a photo or a song without permission. The license is your permission slip, and the conditions printed on it are the price of admission. Miss those conditions and the permission can evaporate.

To count as genuinely “open source,” a license generally has to meet the Open Source Initiative’s definition — free redistribution, source code available, derivative works allowed, no discrimination against users or uses. Within that umbrella, though, licenses vary a lot in how much they ask of you.

The Two Big Families: Permissive vs. Copyleft

Nearly every open-source license falls into one of two camps, and understanding this split is 80% of the battle.

Permissive licenses (MIT, Apache 2.0, BSD) are the relaxed ones. They basically say: “Do almost anything you want with this — use it commercially, modify it, bundle it into closed-source products — just keep our copyright notice around and don’t blame us if it breaks.” They let the code travel almost anywhere, including into proprietary software you sell.

Copyleft licenses (the GPL family, and to a lesser degree the LGPL and MPL) come with a catch known as share-alike. They grant you the same broad freedoms, but with a condition: if you distribute software built on that code, you generally have to release your derivative work under the same license too, with source included. The freedom is designed to be “contagious” — it propagates to everything downstream, which is why copyleft is sometimes called a “viral” license (a loaded term, but it captures the mechanic).

Neither family is better or worse. Permissive maximizes adoption and flexibility; copyleft maximizes the guarantee that the code — and improvements to it — stay free and open. The one you’re dealing with determines what you owe.

A light floating gold tag on the left versus a heavier gold tag chained back to a stack of code on the right, on navy, symbolizing permissive versus copyleft open-source licenses — The core split: permissive licenses let the code travel almost anywhere; copyleft loops obligations back onto anything you build from it.

MIT — The Minimalist Favorite

The MIT License is the most popular open-source license on the planet, and for good reason: it’s about two paragraphs long and you can read it in under a minute. It’s permissive to the bone.

What it lets you do: use the code commercially, modify it, distribute it, sublicense it, and fold it into private, closed-source projects. What it asks in return is almost nothing: keep the original copyright notice and the license text in any copies or substantial portions of the software. That’s essentially the whole obligation. It also disclaims all warranty — the code comes “as is,” and the author isn’t liable if it fails.

For most indie developers, MIT is the path of least friction. If you’re using an MIT-licensed library, your only real homework is making sure that copyright/license notice ships with your distribution — typically by keeping the library’s LICENSE file intact. The BSD licenses (2-clause and 3-clause) are close cousins with nearly identical terms; the 3-clause version adds a rule that you can’t use the author’s name to endorse your product without permission.

Apache 2.0 — Permissive With Patent Armor

Apache 2.0 is permissive like MIT, but longer and more deliberate — and it adds one genuinely important feature: an express patent grant. Contributors to Apache-licensed code grant you a license to any patents they hold that are needed to use their contribution. In plain terms, it reduces the risk that a contributor could later turn around and sue users for patent infringement over the very code they gave away. MIT is silent on patents; Apache 2.0 handles them head-on. That’s why a lot of larger and enterprise-facing projects prefer it.

Your obligations under Apache 2.0 are a bit more involved than MIT, but still manageable. You must keep the license and copyright notices, state any significant changes you made to the files, and preserve any NOTICE file the project includes (passing along its attributions). It also has a defensive clause: if you sue someone alleging the software infringes your patents, your patent license under Apache 2.0 terminates. For most users, none of this is onerous — keep the notices, note your changes, carry the NOTICE file forward, and you’re compliant.

A gold shield overlapping a document with a patent-style ribbon seal and a protective arc over it, on navy, symbolizing a license that grants both copyright and patent permission — Some permissive licenses, like Apache 2.0, add an explicit patent grant — legal armor a bare copyright license doesn’t give you.

The GPL Family — Copyleft and the “Share-Alike” Catch

Now the one that trips people up. The GNU General Public License (GPL) is the flagship copyleft license, and its central rule has real consequences: if you distribute a program that includes or is derived from GPL code, you must release the entire combined work under the GPL and make the complete source available. You can absolutely use GPL software commercially — “free” here means freedom, not price — but you can’t wrap it into a closed-source product you ship and keep the source secret. That’s the deal.

A few important nuances:

Distribution is the trigger. The obligation to share source generally kicks in when you distribute the software to others. Using GPL code purely internally, for yourself, usually doesn’t force you to publish anything.
The AGPL closes the “SaaS loophole.” The Affero GPL (AGPL) extends copyleft to software users interact with over a network — so if you run modified AGPL code as a web service, you may owe users the source even though you never “shipped” them a copy. Watch for this one in server-side dependencies.
The LGPL is the softer sibling. The Lesser GPL is designed for libraries: you can generally link to an LGPL library from your proprietary app without your whole app becoming GPL, as long as users can swap in a modified version of the library. It’s copyleft on the library itself, not on your program.
The MPL is per-file copyleft. The Mozilla Public License splits the difference: modifications to MPL-licensed files must stay open, but you can combine them with proprietary code in a larger work.

The practical upshot: before you build a commercial, closed-source product on a dependency, check whether it’s GPL/AGPL. If it is, either comply fully (open your source), keep your use internal, look for a permissively licensed alternative, or ask the author about a separate commercial license — many dual-license their projects for exactly this reason.

What This Means for You: Picking and Complying

Two situations cover almost everything you’ll face. Here’s the short playbook for each.

When you’re using someone else’s code:

Find the license first, not last. Look for a LICENSE file, a header in the source, or the license field in package.json/pyproject.toml. No license at all? That means “all rights reserved” — you have no permission to use it, ironically less than an open-source one.
Keep the notices. For permissive licenses, preserving the copyright and license text is usually the whole job. Carry forward any NOTICE file.
Track your dependencies. Modern projects pull in dozens of transitive dependencies, each with its own license. A license-scanning tool (or your package manager’s audit command) can flag a surprise GPL/AGPL buried three levels deep before it becomes a problem.
Respect the copyleft trigger. If you’re distributing and a dependency is copyleft, plan for the share-alike obligation deliberately — don’t discover it after launch.

When you’re releasing your own code:

Choose on purpose. Want maximum adoption and don’t mind others using it in closed products? Go permissive — MIT for simplicity, Apache 2.0 if patents are a concern. Want to guarantee your work and its derivatives stay open? Choose the GPL or AGPL.
Actually add the file. Put a real LICENSE file in the repo. A tool like choosealicense.com walks you through it in a couple of clicks. Code posted with no license is not open source — and it leaves would-be users legally unable to touch it.
Remember you keep your copyright. Licensing your code open source doesn’t give away ownership; you still hold the copyright and can license it other ways (including commercially) in parallel.

A gold solo developer at a desk reaching for one of three floating license tags with a checkmark above it, on navy, symbolizing an indie developer choosing the right open-source license — For your own projects, the license you pick decides how freely others can use your work — and whether they must share back.

Open-source licenses look intimidating from the outside, but the mental model is simple: code is copyrighted by default, a license is the permission that unlocks it, and the license’s family — permissive or copyleft — tells you what you owe in return. Permissive means “keep the notice and go build.” Copyleft means “build freely, but share alike if you distribute.” Get those two ideas straight and you’ll navigate the vast majority of real-world situations without a lawyer on speed dial.

This article is general information, not legal advice. Open-source license terms are specific, and their exact application — especially around copyleft, linking, and commercial use — can hinge on details of how you combine and distribute software. For decisions with real money or liability on the line, review the full license text and consult a qualified intellectual-property or technology attorney.

IPSurge helps creators, developers, and small businesses understand and protect their intellectual property — the code, work, and ideas that make them unique.

Sources & further reading:

Open-Source Licenses Explained: MIT, GPL, Apache, and What They Require