Every piece of open-source software you deploy, from your Linux kernel to the Docker images running your services, comes with a license that defines what you can and cannot do with it. Ignoring licenses is not just a legal risk; it is a strategic mistake that can force painful rewrites, block acquisitions, or expose your organization to litigation. Yet most developers treat the LICENSE file as boilerplate they never read.

This guide breaks down the major open-source licenses, explains the critical distinction between permissive and copyleft, covers the newer "source-available" licenses that have stirred controversy, and provides practical guidance for choosing a license for your own projects.

The Two Families: Permissive vs Copyleft

Every open-source license falls into one of two broad categories:

Aspect Permissive Copyleft
Philosophy Maximum freedom for users Freedom must be preserved
Core requirement Attribution (keep copyright notice) Share-alike (derivative works must use same license)
Proprietary use Allowed (can close source) Restricted (must share source)
Examples MIT, Apache 2.0, BSD GPL, AGPL, LGPL, MPL
Corporate preference Generally preferred Often avoided in proprietary products
Community effect Broader adoption, less contribution back Ensures contributions return to community

Permissive Licenses

MIT License

The MIT license is the most popular open-source license on GitHub. It is 171 words long and says, in essence: "Do whatever you want with this code, just keep the copyright notice and do not blame me if it breaks."

MIT License

Copyright (c) 2025 Your Name

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND...
  • You can: Use commercially, modify, distribute, sublicense, use privately
  • You must: Include the copyright notice and license text
  • You cannot: Hold the author liable

Used by: React, jQuery, Rails, Vue.js, Node.js, Electron, .NET

Apache License 2.0

Apache 2.0 is similar to MIT but adds two important provisions: an explicit patent grant and protection against patent trolling.

  • Patent grant: Contributors automatically grant users a royalty-free patent license for any patents covering their contributions
  • Patent retaliation: If you sue the project for patent infringement, your patent license is automatically terminated
  • NOTICE file: If the project includes a NOTICE file, you must include it in derivative works
  • Contribution tracking: Requires marking modifications in changed files

Used by: Kubernetes, Android (AOSP), Swift, TensorFlow, Kafka, Elasticsearch (pre-SSPL)

Tip: If your project might be contributed to by people at large companies, prefer Apache 2.0 over MIT. The explicit patent grant makes corporate legal teams more comfortable, and the patent retaliation clause protects you from contributors who later try to assert patents.

BSD Licenses (2-Clause and 3-Clause)

The BSD licenses are nearly identical to MIT in effect. The 2-Clause BSD is functionally equivalent to MIT. The 3-Clause BSD adds a "non-endorsement" clause preventing you from using the project's name to endorse derivatives without permission.

Used by: FreeBSD, Nginx (original), Go (standard library), Django

Copyleft Licenses

GPL v2 and GPL v3

The GNU General Public License is the flagship copyleft license. Its core principle: if you distribute software that includes GPL code, you must make the complete source code available under the GPL.

Feature GPL v2 GPL v3
Copyleft scope Distributed works Distributed works
Patent protection Implicit Explicit patent grant
Tivoization protection No Yes (anti-lockdown)
DRM restrictions No Yes (anti-DRM clause)
Compatibility GPL-2.0 only Compatible with Apache 2.0

The critical question: Does linking your proprietary code with a GPL library make your code GPL? This is the subject of intense legal debate. The FSF says yes (dynamic linking creates a derivative work). Others disagree. Most companies take the conservative approach and avoid GPL dependencies in proprietary products.

Used by: Linux kernel (GPL-2.0-only), Git, WordPress, MariaDB, BusyBox

AGPL (Affero General Public License)

The AGPL extends the GPL to close the "SaaS loophole." Under regular GPL, providing software as a network service (without distributing binaries) does not trigger the copyleft requirement. The AGPL changes this: if users interact with your software over a network, you must provide the source code.

# AGPL trigger scenarios:
# 1. You modify AGPL software and run it as a web service
#    -> You must publish your modified source code
#
# 2. You use an AGPL library in your web application
#    -> Depends on interpretation; most treat it as triggering AGPL
#
# 3. You use AGPL software internally (never exposed to users)
#    -> No obligation to share source
#
# 4. You use unmodified AGPL software as a service
#    -> Original source is already available; you are fine

Used by: Nextcloud, Grafana, MongoDB (pre-SSPL), Mastodon, Discourse

Warning: Many companies have blanket policies against using AGPL software, even internally. If you are building software for enterprise customers, using AGPL dependencies may limit your market. Understand your customers' policies before choosing AGPL.

LGPL (Lesser GPL)

The LGPL is a weaker copyleft that allows proprietary software to link against LGPL libraries without the copyleft applying to the proprietary code. Modifications to the LGPL library itself must still be shared.

Used by: glibc, Qt (dual-licensed), FFmpeg (some components), libcurl (option)

MPL 2.0 (Mozilla Public License)

The MPL is a file-level copyleft. Only modified MPL files must remain under MPL. You can combine MPL files with proprietary code in the same project without the copyleft spreading to your files.

Used by: Firefox, Terraform (pre-BSL), Consul (pre-BSL), Syncthing

Source-Available (Non-OSI) Licenses

Recent years have seen a wave of companies switching from OSI-approved licenses to "source-available" licenses that restrict certain uses. These are not considered open source by the OSI.

BSL (Business Source License)

Created by MariaDB and adopted by HashiCorp, CockroachDB, and others. The BSL makes source code available but restricts production use. After a specified period (typically 4 years), the code automatically converts to a standard open-source license (usually Apache 2.0).

# BSL structure:
# - Source code is publicly available
# - You can read, fork, and modify
# - Non-production use is unrestricted
# - Production use requires a commercial license
# - After the "change date" (e.g., 4 years), becomes Apache 2.0
#
# Companies using BSL:
# - HashiCorp (Terraform, Vault, Consul) - changed from MPL in 2023
# - CockroachDB
# - Sentry
# - MariaDB (MaxScale)

SSPL (Server Side Public License)

Created by MongoDB. The SSPL is based on the AGPL but extends the copyleft to the entire stack: if you offer SSPL software as a service, you must open-source all the software in your service stack, not just the SSPL component.

Used by: MongoDB, Elasticsearch (post-2021), Kibana

The distinction between open source and source-available matters for self-hosters. BSL and SSPL software can still be self-hosted freely for internal use. The restrictions typically apply only to offering the software as a commercial service to third parties. However, the licensing landscape is evolving, so always read the specific license terms.

Choosing a License for Your Project

Use this decision framework:

  1. Want maximum adoption? Use MIT or Apache 2.0. Corporations will adopt it freely.
  2. Want contributions back? Use AGPL or GPL. Copyleft ensures improvements return to the community.
  3. Building a library? Use MIT, Apache 2.0, or LGPL. Copyleft on libraries limits adoption.
  4. Building a SaaS product? Use AGPL if you want to prevent cloud providers from offering it as a service without contributing back.
  5. Building a business? Consider dual licensing (open source + commercial) or BSL for a time-delayed open source approach.
  6. Have patentable technology? Use Apache 2.0 for its explicit patent grant and retaliation clause.

License Compatibility

Not all licenses can be combined in a single project. Here is a simplified compatibility matrix:

License MIT Apache 2.0 GPL-2.0 GPL-3.0 AGPL-3.0
MIT Yes Yes Yes* Yes* Yes*
Apache 2.0 Yes Yes No Yes* Yes*
GPL-2.0 Yes* No Yes No No
GPL-3.0 Yes* Yes* No Yes Yes
AGPL-3.0 Yes* Yes* No Yes Yes

* Combined work must be distributed under the copyleft license.

Dual Licensing

Many successful projects use dual licensing to balance community and commercial interests:

# Dual licensing models:
#
# 1. Open Core (e.g., GitLab CE/EE, usulnet AGPL + Commercial)
#    - Core product is open source
#    - Premium features require commercial license
#
# 2. GPL + Commercial (e.g., MySQL, Qt)
#    - Community version under GPL
#    - Commercial license for proprietary embedding
#    - Requires CLA (Contributor License Agreement)
#
# 3. AGPL + Commercial (e.g., MongoDB pre-SSPL, Grafana)
#    - AGPL for self-hosting
#    - Commercial license for SaaS providers
#
# 4. BSL + Delayed Open Source (e.g., CockroachDB)
#    - Source available immediately
#    - Becomes open source after change date

Docker Image Licensing Considerations

When running self-hosted software with Docker, licensing applies at multiple layers:

Layer License applies to Example
Base image The OS and packages in the image Alpine (MIT), Ubuntu (various), Debian (DFSG)
Application The main software in the container Nextcloud (AGPL), Gitea (MIT), Grafana (AGPL)
Dependencies Libraries bundled in the image npm packages, Go modules, Python packages
Configuration Your custom configuration files Your code, not affected by container license
Tip: When self-hosting software for internal use, even AGPL and GPL software can be used freely because you are not distributing it to third parties. The copyleft obligations only trigger on distribution (GPL) or network interaction by external users (AGPL). Running Nextcloud for your team does not obligate you to publish your configuration or modifications.

Practical Implications for Self-Hosters

  • Using MIT/Apache software: No restrictions. Use freely, modify, deploy internally or externally.
  • Using GPL software: Fine for internal use. If you distribute modified versions, share the source.
  • Using AGPL software: Fine for internal use. If external users access it, share modified source code.
  • Using BSL software: Fine for internal non-production or non-commercial use. Check the specific additional use grant for production use.
  • Using SSPL software: Fine for internal use. Do not offer it as a managed service without open-sourcing your entire stack.

For tools like usulnet that use AGPL licensing, self-hosting for your own infrastructure management is fully within the license terms. The AGPL's network copyleft provision would only apply if you were to offer usulnet as a service to external third parties.

Summary

Open-source licenses are not just legal boilerplate. They define the social contract between software creators and users. Understanding them helps you make informed decisions about what you deploy, what you build on, and how you contribute back. For self-hosters, the practical advice is simple: read the license, use internally without fear, and be careful if you plan to redistribute or offer services to others.