Open Source Licenses Explained: What You Can and Can't Do With Free Software

Nobody Reads the License. Until They Really Wish They Had.

Software licenses occupy a special category of text that shares a reading experience with terms and conditions: everyone knows they should read it, almost nobody does, and a small number of people have interesting stories about the time they really should have.

For self-hosters, it usually doesn’t matter. Install Jellyfin, run it, enjoy your media library. Jellyfin is GPL licensed. You’re fine. But “I run this for myself” and “I run this as a service” and “I’m building a product” are three different situations with three different answers.

For developers building on open-source libraries or forking projects, the license is load-bearing. Getting it wrong ranges from “awkward GitHub issue” to “corporate legal department involvement.” Understanding the basic categories takes twenty minutes and saves you from being in either situation.

The Two Big Categories: Permissive vs Copyleft

Every major open source license falls into one of two philosophies.

Permissive licenses say: do whatever you want with this software. Use it, modify it, incorporate it into commercial products, keep your modifications private. The only requirements are usually attribution (credit the original authors) and license preservation (include the original license text).

Copyleft licenses say: use this software freely, but if you distribute or publish software that incorporates it, your software must also be open source under compatible terms. The freedom is designed to be viral — free software should create more free software.

Neither is objectively better. They represent different philosophies about software freedom and how to sustain open source development.

The Permissive Family

MIT License

The minimum viable license. In full, it’s about 170 words. The gist:

Do whatever you want. Give us credit. Don’t sue us.

That’s it. You can use MIT-licensed code in commercial software. You can modify it without releasing your modifications. You can incorporate it into a proprietary product. The only obligations are including the copyright notice and license text.

Most npm packages are MIT. Most small utility libraries are MIT. It’s the “I just want people to use this” license.

Best for: Libraries you want widely adopted, developer tools, anything where you want zero friction for potential users.

Apache 2.0

Apache adds one significant thing to MIT: patent grants. When contributors submit code to an Apache-licensed project, they implicitly grant users the right to use any of their patents that cover that code. This matters for larger companies that care about patent risk.

Apache 2.0 is also explicit about trademark: you can’t use the project’s name to endorse your derived work. You can fork and redistribute Apache-licensed code, but you can’t call your product the same name.

Google’s Android uses Apache 2.0 for most components. Many enterprise-friendly projects use it because companies’ legal departments are comfortable with the patent clauses.

Best for: Projects aimed at enterprise adoption, anything where contributors might hold relevant patents.

BSD Licenses (2-Clause, 3-Clause)

BSD licenses are essentially MIT with minor variations. BSD 2-Clause is nearly identical to MIT. BSD 3-Clause adds “you can’t use the project’s name in advertising” — similar to Apache’s trademark clause, less thoroughly specified.

BSD licenses are common in BSD-derived operating systems, academic software, and anywhere the culture predates MIT’s prevalence.

The Copyleft Family

GPL (GNU General Public License) v2 and v3

GPL is the original copyleft license. The core requirement: if you distribute a program that incorporates GPL-licensed code, the entire program must also be licensed under the GPL and its source code must be available.

Key clarification: “distribute” means sharing the software with others. Running GPL software yourself — including running it on a server you administer — does not require you to release anything. Your self-hosted Jellyfin install, your homelab running GPL software, your work server running Linux: no disclosure requirements.

“Distribute” means shipping software to others. Companies that ship products with GPL components must release source or face legal action. This is how companies get in trouble — they ship a router running Linux (GPL) without making the modified kernel source available.

GPL v2 vs v3: v3 adds provisions against “tivoization” (using hardware restrictions to prevent running modified software, even with source available), stronger patent protections, and compatibility adjustments. The Linux kernel uses v2 specifically (with “or later” removed) because Torvalds has specific views about v3 provisions.

Best for: Projects where the author wants to ensure derivatives stay open. Desktop applications. Tools where “if you improve it, share it back” is the value system.

LGPL (GNU Lesser General Public License)

LGPL is the library-friendly version of GPL. The difference: you can incorporate LGPL-licensed code into a proprietary application, as long as:

• The LGPL component remains separately linkable (not statically merged)
• Users can replace the LGPL component with their own version

This was designed for libraries — the intent is that developers can use free libraries without being forced to open-source their entire application. FFmpeg, for example, offers LGPL and GPL versions depending on which components you use.

Best for: Libraries where you want free use but still want changes to the library itself to stay open.

AGPL (GNU Affero General Public License)

AGPL closes the “SaaS loophole” in GPL. The loophole: if you run GPL software as a network service (a website, a SaaS), you’re not distributing it — users interact with it but never receive the software. GPL’s distribution trigger doesn’t apply.

AGPL adds: if you run modified AGPL software as a network service, you must make the modified source available to users of that service. This matters significantly for SaaS businesses.

MongoDB uses AGPL for its community edition. If you run a modified version of MongoDB as a service, you must release your modifications. Companies that want to use MongoDB in a SaaS without open-sourcing their modifications need the commercial license — which is exactly MongoDB’s intended business model.

Many developers adding AGPL code to a project trigger unexpected obligations. This is why some companies blanket-prohibit AGPL dependencies in internal policies.

Best for: Server-side software where the author wants modifications exposed even if the software is “run as a service” rather than distributed.

Practical Comparison Table

What “Self-Hosting” Means Legally

For the self-hosters in the audience: running software on your own servers for yourself or your household imposes essentially no license obligations under any of these licenses. The GPL distribution trigger requires you to give the software to others.

Running Gitea (MIT), Jellyfin (GPL), Nextcloud (AGPL), Home Assistant (Apache), Bitwarden/Vaultwarden (GPL) for your family — zero disclosure requirements. No source code release needed. No license complications.

Where it gets interesting:

• Running a service for others: If you run a Nextcloud instance for your business, your employees, or as a paid service — you’re still fine under GPL (GPL only triggers on distribution, not running a service). Under AGPL, you might need to make modified source available if you’ve modified the software.

• Building a product on top: If you’re building a commercial product that includes GPL-licensed code and shipping it to customers — you need to provide source or a written offer for it. Many companies handle this with a “compliance package” — a ZIP of all open-source component sources included in the product.

• Contributions and forks: If you fork a GPL project and want to keep your modifications private — you can, as long as you don’t distribute it. The moment you ship it to others, you must open-source the modifications.

The License Dramas: Recent History

HashiCorp BSL (2023)

HashiCorp switched Terraform, Vault, Consul, and other tools from Mozilla Public License 2.0 to Business Source License 1.1 in August 2023. BSL is not an open-source license by OSI definition. The key restriction: BSL prohibits using the software in competing commercial products. For most users (self-hosters, non-competing businesses, practitioners), nothing changed. But it broke the social contract with the open-source community.

The community responded by forking: OpenTofu (Terraform fork, now under Linux Foundation) and OpenBao (Vault fork). This is the copyleft community running its course — when a steward goes proprietary, the last truly open version lives on.

n8n “Fair-Code”

n8n uses a “fair-code” license — a term they coined. It’s roughly Apache 2.0 with an additional restriction: you can’t offer n8n as a managed service without a commercial license. This isn’t recognized as open source, but it’s also less restrictive than BSL. The self-hosted community generally accepted it with mild grumbling.

Redis Commons Clause and BSD+SSPLs

Redis switched to SSPL (Server Side Public License, similar to AGPL but more aggressive) in 2024, then split into two forks: one maintained by the community under BSD (Valkey, now under Linux Foundation) and the commercial Redis under proprietary terms. Valkey has become the default Redis in many Linux distributions.

The pattern: successful open-source infrastructure projects with venture funding facing competitive pressure from AWS/Azure hosting the software → license change → community fork.

Practical Guidance: What to Actually Do

You’re a developer using open-source libraries:

• MIT/Apache/BSD in your dependencies: no worries
• LGPL: check whether you’re statically linking vs dynamically linking
• GPL: if you’re distributing, all linked code must be GPL-compatible
• AGPL: if you’re running a service, check whether you’ve modified the library

You’re building a commercial product:

• Audit your dependency tree for GPL/AGPL before shipping
• Tools like licensee, license-checker (npm), and pip-licenses can automate this
• Maintain a list of open-source components and their licenses for compliance

You’re self-hosting:

• Stop worrying. Almost nothing applies to you.

You’re picking a license for your own project:

• Want maximum adoption: MIT
• Want patent protection for enterprise users: Apache 2.0
• Want contributions to stay open: GPL
• Want SaaS use to trigger obligations: AGPL
• Want to monetize while allowing most use: BSL or a dual-license

The two-minute rule: if you can’t explain your license choice in two sentences, you probably haven’t thought through your goals for the project. A clear goal leads to a clear license.

Now you’ve read more about software licenses than 95% of developers. You’re welcome.