Overview
You’ve chosen FOSS hosting. But do you know what your FOSS license actually requires? The license on your software affects what you can do with it, whether you must share modifications, and what obligations you have to your users.
This guide explains the licenses you’ll encounter most often and what they mean in practice for self-hosters.
Difficulty: Beginner Legal disclaimer: This is educational, not legal advice.
The FOSS License Landscape
FOSS licenses generally fall into two categories:
| Category | Obligation | Famous Examples |
|---|---|---|
| Copyleft / Viral | You must release source code of derivatives | GPL, AGPL, EUPL |
| Permissive | Use, modify, redistribute freely | MIT, BSD, Apache |
The “viral” aspect is often misunderstood. It only kicks in if you distribute the software. Pure internal use (self-hosting) rarely triggers viral obligations.
GPL (GNU General Public License)
Version: 2.0, 3.0 Copyleft: Strong Notable projects: Linux kernel, WordPress, MySQL, git
What GPL Means
If you modify GPL software and distribute it (e.g., offer a hosted service to others), you must:
- Release the full source code
- License it under GPL
- Include the GPL license text
For Self-Hosters
Internal use is safe. Running WordPress on your own server and offering a blog service is fine. You don’t need to release your custom WordPress theme or plugins because you’re not distributing WordPress — you’re using it.
Where it gets tricky: If you build a product that includes GPL components and sell access to it (Software-as-a-Service), some lawyers argue the GPL “传染” to your entire service. The AGPL closes this loophole.
Real-World Example
WordPress is GPL. You can:
- Use it for your business website ✓
- Build custom themes and plugins ✓
- Sell WordPress hosting ✓
- Keep your custom themes private (you’re not distributing WordPress) ✓
WordPress plugins that extend WordPress (hooks, themes) are generally considered derivative works — but the community norm is to keep custom work private unless you distribute it.
AGPL (Affero General Public License)
Version: 3.0 Copyleft: Strong + SaaS loophole closed Notable projects: Nextcloud, Mastodon, PostgreSQL (AGPL client), MediaWiki
What AGPL Means
Same as GPL, plus: If you modify the software and use it over a network, you must also release the source to users.
This was specifically designed to close the “SaaS loophole” where companies could use GPL software internally, modify it, and offer it as a service without releasing the changes.
For Self-Hosters
If you run AGPL software (Nextcloud, Mastodon) and modify it for your own use:
- You must release your modifications if you make the modified software available over a network to others
- Pure internal use (even with modifications) doesn’t trigger the AGPL obligation
Real-World Example
Mastodon is AGPL. If you run mastodon.social (the biggest instance) and modify it:
- Your modifications are available to your users (AGPL triggers)
- You must make your modifications available (e.g., on GitHub)
If you run a private Mastodon instance for your company and modify it:
- Only your employees access it
- Most lawyers agree this doesn’t trigger AGPL (not “public” in the legal sense)
- Safer to keep modifications private: don’t make modified code accessible to the public
MIT License
Copyleft: None (permissive) Notable projects: React (MIT), Angular (MIT), Rails (MIT), Express.js, jQuery
What MIT Means
The most permissive common license. You can:
- Use, modify, and redistribute the software
- Use it in proprietary products
- Keep your modifications private
- Sublicense it under different terms
With only one requirement: include the original copyright notice and license text in all copies.
For Self-Hosters
No obligations whatsoever for internal use. Even better: no viral effect if you incorporate MIT-licensed code in your products.
Real-World Example
You build a Node.js app using Express.js (MIT) and jQuery (MIT). You can:
- Keep your entire codebase proprietary ✓
- Sell access to your hosted app ✓
- Use it internally without any obligations ✓
Apache 2.0
Copyleft: None (permissive), but with patent grant Notable projects: Kubernetes, Docker (Apache 2.0 parts), TensorFlow, Spring Framework
What Apache 2.0 Means
Like MIT, plus:
- Explicit patent grant from contributors (protects you from patent trolls)
- Explicit patent retaliation clause (if you sue over patents related to Apache code, your Apache license is terminated)
- NOTICE file requirement: if you redistribute the software with modifications, include the NOTICE file
For Self-Hosters
No obligations for internal use. Better than MIT for enterprise use due to patent protections.
BSD (2-Clause and 3-Clause)
Copyleft: None (permissive) Notable projects: Nginx (BSD-2), FreeBSD (BSD-2), PostgreSQL (PostgreSQL license, similar), Node.js (mostly MIT/BSD)
What BSD Means
Very permissive. 3-Clause BSD adds one extra requirement over MIT: don’t use the project’s name for endorsement without permission.
For Self-Hosters
No obligations for internal use.
EUPL (European Union Public License)
Copyleft: Strong, with compatibility clause Notable projects: European Commission’s FOSS projects
What EUPL Means
Like GPL, but explicitly compatible with other FOSS licenses (GPL, AGPL, MPL, etc.). If you’re in the EU public sector, EUPL is often the required license for funded software.
For Self-Hosters
Same rules as GPL for practical purposes.
Quick Reference Table
| License | Viral? | SaaS Triggers? | Private Modifications OK? | Notable Projects |
|---|---|---|---|---|
| MIT | No | No | ✓ Yes | Express, jQuery, Rails |
| BSD-3 | No | No | ✓ Yes | Nginx, FreeBSD |
| Apache 2.0 | No | No | ✓ Yes | Kubernetes, TensorFlow |
| GPL v3 | Yes | No* | ✓ Yes (internal) | Linux, WordPress |
| AGPL v3 | Yes | Yes | ⚠ Careful | Nextcloud, Mastodon |
| EUPL | Yes | No* | ✓ Yes (internal) | EU FOSS projects |
*GPL v3 and EUPL do NOT have the SaaS loophole closure. AGPL v3 explicitly does.
Practical Rules for Self-Hosters
Rule 1: Internal Use Is Almost Always Safe
Running software on your own servers for your own purposes rarely triggers any FOSS license obligations. The viral clauses only apply when you distribute software.
Rule 2: If You Modify and Offer as a Service, Know Your License
- AGPL: You must release modifications to users
- GPL: You must release if you distribute the software itself
- MIT/BSD/Apache: No obligations
Rule 3: If You Build On Top of FOSS, Consider the Stack
Example: You build a Node.js app using:
- Express (MIT) ✓
- React (MIT) ✓
- PostgreSQL (PostgreSQL license, permissive-ish) ✓
- Nextcloud SDK (AGPL) ⚠ — your modifications to any Nextcloud integration may be affected
Rule 4: Read the License Before Commercial Use
If you’re building a commercial product on top of FOSS:
- Read the license header in the source files
- Check the project’s LICENSE file
- Consider consulting a FOSS-savvy lawyer for complex stacks
Rule 5: Keep Track of What You Use
Use licensee or similar tools to audit your dependencies:
# Install licensee
gem install licensee
# Check a project's license
licensee detect https://github.com/WordPress/WordPress
Common Scenarios
”I run Nextcloud for my family. Do I need to release my custom config?”
No. Internal use doesn’t trigger AGPL obligations.
”I modified Nextcloud and want to offer it as a hosted service to clients.”
Yes. AGPL triggers because you’re providing access over a network to third parties. You must make your modifications available under AGPL.
Workaround: Keep your modifications in a separate plugin/app that calls Nextcloud APIs, rather than modifying Nextcloud core itself.
”I use WordPress for client websites. Do I need to release my custom theme?”
No. You’re providing hosting services, not distributing WordPress. However, if you were to sell a “WordPress-based CMS product” that included WordPress core, GPL considerations apply.
”I’m building a SaaS product. Can I use PostgreSQL for free?”
Yes. PostgreSQL uses its own permissive license (similar to BSD/Apache). It’s free for any use, including commercial SaaS, without source code obligations.