Software licenses for self-hosters: what each label lets you do

Start here

Four questions cover almost everything people need from a license:

1. Can I run it at home?
2. Can my company run it?
3. Can I change the code?
4. Can I host it for other people?

Most home setups only need the first answer. The rest start to matter the moment you modify an app, ship it to someone, or sell hosting built on it.

Three things worth internalising before the table:

• A free download is not an open-source license.
• Open-source software can still be sold as a service, by you or by anyone else.
• A free binary can still ban company use.

The repository's license grant decides all of it. The marketing page does not.

Open source vs source-available

Open source, under the Open Source Definition, lets people use, study, change, and share the software for any purpose, including commercial use. MIT, Apache-2.0, GPL, and AGPL all qualify. AGPL's network-copyleft rule does too: requiring source is not the same as restricting use.

Source-available means the code is public and usually free to run, but the terms add limits that open-source licenses cannot. SSPL section 13 conditions service use on releasing service source. Elastic License and many Sustainable Use terms directly restrict managed services. BSL, FSL, and PolyForm depend on project parameters, time limits, or whether the use competes with the publisher.

A public repo proves nothing either way. If the license is not OSI-approved, treat the project as software you can often self-host, with extra rules that still apply to you.

The four families

Every license above belongs to one of four families, and the family answers most questions on its own. What separates them is one thing: what you owe when the software leaves your hands.

Permissive asks only that copyright notices survive redistribution. Your fork can stay closed forever.

Weak copyleft scopes the share-back duty to the covered code. Distribute modified MPL files or a changed LGPL library and that source stays open. The rest of your product stays yours.

Copyleft covers the whole program, and the trigger is the part people get wrong.

Restricted is source-available, not open source. The code is public, but different licenses limit different uses. SSPL conditions a service offering on releasing service source. Elastic-2.0 and many Sustainable Use terms directly limit managed services. BSL 1.1, FSL, and PolyForm turn on project parameters, a conversion date, or whether your use competes with the publisher. Self-hosting for yourself or your company is usually the intended free path, but the exact text still controls.

The copyleft trigger

GPL compliance starts when you distribute a covered copy. Modification is not required: distributing an unmodified copy can still require license notices and, for object code, corresponding source.

AGPL adds a network trigger in section 13. When people use your modified version over a network, you must offer them its corresponding source.

That clause stops a modified hosted clone from staying closed, which makes AGPL a common choice for self-host web apps.

Two things follow that are worth stating plainly, because both get misread constantly:

• Unmodified upstream does not trigger AGPL section 13, even when family, coworkers, or other remote users log in.
• The extra network rule needs modified code plus remote interaction. If you are the only user, there is no section 13 source-offer duty.

Choosing a license for your own app: the short path

If you are shipping a self-host app and want one answer rather than thirty:

• You want maximum adoption and do not care who profits. MIT. Apache-2.0 if you want an explicit patent grant.
• You want fixes shared back but not a fight over combined products. MPL-2.0.
• You are shipping a library. LGPL-3.0, or MIT if you want it everywhere.
• Your real fear is a hosted closed clone. AGPL-3.0. This is the common open-source choice for that goal.
• You want a commercial business on top. AGPL-3.0 plus a paid commercial license, dual-licensed.
• You need to block managed-service resale specifically, and can accept losing the open-source label. BSL 1.1 or FSL, both of which convert to open source later. Elastic-2.0 or Sustainable Use if you do not want a conversion date.
• You want personal use free and all company use paid. PolyForm Noncommercial, understanding business adoption will be small.

Whatever you pick, write a plain-language paragraph next to the LICENSE file explaining what a self-hoster may do. Self-hosters read that paragraph before they read the legal text, and often instead of it.

Questions that come up

Does AGPL stop me self-hosting an app for my family?
No for unmodified upstream, and no when you are the only user. If you modify it and someone else, including family, uses it remotely, AGPL section 13 requires you to offer that version's corresponding source.

I run an unmodified AGPL app and let friends log in. Do I owe them source?
Unmodified upstream does not trigger AGPL section 13. The extra source-offer duty appears when remote users interact with a modified version.

My company runs a GPL app internally with local patches. Do we have to publish them?
No. GPL triggers on distribution. Internal use is not distribution.

Is a public GitHub repo open source?
Not necessarily. Check whether the license is OSI-approved. SSPL, BSL, FSL, Elastic, and PolyForm are all public and none of them are open source.

Can I sell hosting for an MIT-licensed app?
Yes. Permissive licenses do not block that, which is exactly why some projects move to AGPL or a source-available license later.

Two projects both say BSL 1.1. Do they grant the same rights?
No. The Additional Use Grant and change date differ per project. Read both.

The repo has no LICENSE file. Can I use it?
First check the README, documentation, or another file for an express license grant. GitHub's licensing guidance explains the default: if the repository grants no license anywhere, normal copyright applies and you should treat it as all rights reserved.