Software licenses for self-hosters
Self-host apps usually show a short license label such as MIT, AGPL, SSPL, or Elastic. That label tells you what you are allowed to do with the software. It also tells app authors what rights they are giving other people.
This page is a practical guide, not legal advice. If money, customers, or a commercial product are involved, read the project's LICENSE file and get legal help when you need it.
Use the sidebar to jump straight to a license label you already saw. The two short notes below set the basics. The self-host apps directory uses the same short names.
Who this page is for
If you install self-host apps, this page helps you read the license on an app card. The main questions are: can I run this at home, can my company run it, can I change the code, and can I host it for other people?
Most home setups only need the first answer. The later questions matter when you modify an app, give it to customers, or sell hosting based on it.
If you build and publish a self-host app, this page helps you compare licenses before you pick one. Some licenses make it easy for anyone to reuse your code. Some require people to share their changes. Some let people read and self-host the code, but block certain commercial uses.
A free download is not the same thing as an open-source license. Open-source software can still be sold as a service. A free binary can still ban company use. Trust the LICENSE file in the project, not only the marketing page.
Open source vs source-available
Open source, as defined by the Open Source Initiative (OSI), means people can use, study, change, and share the software for any purpose, including commercial use, under a license that meets that definition. MIT, Apache-2.0, GPL, and AGPL are open source in this sense.
Source-available means the code is public and often free to run, but the license adds business limits. Common limits include: no offering it as a managed service, no competing product, non-commercial use only, or production rights that later turn into an open-source license. SSPL, Elastic License, BSL, FSL, and PolyForm Noncommercial are in this group.
A public GitHub repo does not automatically mean open source. If the license is not OSI-approved, treat the project as software you can often self-host, with extra rules you still need to follow.
Permissive licenses
MIT License
MIT
MIT is a short permissive license. You can run the software, change it, use it commercially, and host it for others. The main rule is that you keep the copyright and license notice when you give the code or a package to someone else.
- OSI open source
- Yes (OSI-approved).
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Yes for internal company use.
- Modify
- Yes. Keep the required notices when you redistribute.
- Redistribute
- Yes, including inside a closed product, as long as notices stay with the distribution.
- Offer as a service
- Yes. This open-source license does not block hosting the software for other people. Trademarks and branding can still apply.
- Copyleft
- None.
- Notices
- Include the MIT copyright and permission notice with distributions.
If you are running this software:
For home or company self-hosting, MIT is one of the easiest licenses to live with. You can run the official image, change config, and keep a private fork without sharing it.
If you only run the app and never ship a package to other people, day-to-day compliance is usually just using the software as published.
If you are choosing a license for your own app:
Choose MIT if you want other people, including companies, to reuse your code with very few conditions. It is widely understood and rarely blocks adoption.
MIT will not stop a cloud company from hosting your app as a paid service. If that is a real concern, look at AGPL, SSPL, BSL, FSL, or a paid commercial license instead.
Common mistake: Assuming MIT means the project has no paid edition. Many apps are MIT for the core code and separately paid for enterprise modules or hosted plans.
Apache License 2.0
Apache-2.0
Apache-2.0 is a permissive license like MIT, with clearer patent terms and stricter notice rules when you redistribute. You can still run, change, and use the software commercially.
- OSI open source
- Yes (OSI-approved).
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Yes for internal company use.
- Modify
- Yes. Mark modified files as changed when you redistribute them.
- Redistribute
- Yes, including closed products, with Apache notice rules.
- Offer as a service
- Yes. This open-source license does not block hosting the software for other people. Trademarks and branding can still apply.
- Copyleft
- None.
- Notices
- Keep copyright and license notices when you distribute copies. Apache also requires NOTICE handling when a NOTICE file exists.
If you are running this software:
Running Apache-licensed apps at home or work is straightforward. For operators, the practical freedom is very close to MIT.
The extra notice rules matter mainly if you repackage the software and give that package to other people.
If you are choosing a license for your own app:
Choose Apache-2.0 if you want permissive reuse plus an explicit patent grant. Many infrastructure and foundation projects use it for that reason.
If you ship builds, keep the license text, copyright statements, and any NOTICE file contents. That is the main extra work compared with MIT.
Common mistake: Treating Apache-2.0 and MIT as identical when shipping a product. For private self-hosting they feel similar. For redistribution, Apache asks for more care with notices.
BSD 2-Clause License
BSD-2-Clause
BSD-2-Clause is a permissive license. You can use and change the software freely as long as you keep the copyright notice and disclaimer when you redistribute it.
- OSI open source
- Yes (OSI-approved).
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Yes for internal company use.
- Modify
- Yes. Keep the required notices when you redistribute.
- Redistribute
- Yes, with the copyright notice and disclaimer.
- Offer as a service
- Yes. This open-source license does not block hosting the software for other people. Trademarks and branding can still apply.
- Copyleft
- None.
- Notices
- Keep the copyright notice and disclaimer in source and binary distributions.
If you are running this software:
For self-hosting, BSD-2-Clause behaves like MIT. Home labs and internal company installs are normally fine.
If you are choosing a license for your own app:
A clear permissive option when you want simple terms and wide reuse. Check that the repo really uses the 2-clause text, not another BSD variant.
Common mistake: Assuming every BSD label is the same. 2-clause, 3-clause, and older 4-clause texts differ.
BSD 3-Clause License
BSD-3-Clause
BSD-3-Clause is like BSD-2-Clause, with one extra rule: you may not use the original author's name to promote your product without permission.
- OSI open source
- Yes (OSI-approved).
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Yes for internal company use.
- Modify
- Yes. Keep the required notices when you redistribute.
- Redistribute
- Yes, with notice, disclaimer, and the non-endorsement rule.
- Offer as a service
- Yes. This open-source license does not block hosting the software for other people. Trademarks and branding can still apply.
- Copyleft
- None.
- Notices
- Keep required notices. Do not claim the original authors endorse your product.
If you are running this software:
Day-to-day self-hosting freedom is the same as other permissive licenses.
If you are choosing a license for your own app:
Useful if you want permissive reuse but still want to block people from implying you endorse their product.
ISC License
ISC
ISC is a short permissive license. In practice it works a lot like MIT: use it, change it, and keep the notice when you redistribute.
- OSI open source
- Yes (OSI-approved).
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Yes for internal company use.
- Modify
- Yes. Keep the required notices when you redistribute.
- Redistribute
- Yes, with the copyright and permission notice.
- Offer as a service
- Yes. This open-source license does not block hosting the software for other people. Trademarks and branding can still apply.
- Copyleft
- None.
- Notices
- Keep the copyright and permission notice with distributions.
If you are running this software:
There are no special self-host traps here. Treat it like MIT for running the software.
If you are choosing a license for your own app:
Fine when you want a short permissive text. MIT and Apache-2.0 are more familiar to many company legal teams.
zlib License
Zlib
zlib is a permissive license. You can use it commercially, as long as you do not misrepresent where the code came from and you mark altered versions when required.
- OSI open source
- Yes (OSI-approved).
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Yes for internal company use.
- Modify
- Yes. Do not misrepresent the origin. Mark altered versions when required.
- Redistribute
- Yes, including commercial products, under zlib notice rules.
- Offer as a service
- Yes. This open-source license does not block hosting the software for other people. Trademarks and branding can still apply.
- Copyleft
- None.
- Notices
- Do not claim you wrote the original. Keep origin credit as required.
If you are running this software:
zlib often appears as a library under an app rather than as the app's top-level license. Either way, self-hosting is normally fine.
If you are choosing a license for your own app:
Reasonable for libraries. For a full self-host app, MIT or Apache-2.0 are usually clearer for contributors and companies.
Weak copyleft licenses
Mozilla Public License 2.0
MPL-2.0
MPL-2.0 is a weak copyleft license. You can combine it with other code, but if you distribute changes to MPL-covered files, those files must stay under MPL and their source must remain available.
- OSI open source
- Yes (OSI-approved).
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Yes for internal company use.
- Modify
- Yes. Share modifications to MPL files if you distribute those files.
- Redistribute
- Yes. MPL files stay under MPL. Other files can use other licenses.
- Offer as a service
- Usually fine for hosting. If you distribute modified MPL files, source for those files must stay available under MPL.
- Copyleft
- Weak, file-level.
- Notices
- Keep MPL notices on covered files and offer source for distributed MPL changes.
If you are running this software:
Running MPL software privately is usually easy. Source-sharing mainly starts when you distribute modified packages, not when you only run the app for yourself.
If you are choosing a license for your own app:
Choose MPL if you want people to share fixes to your own files, without forcing their entire product to become MPL.
It sits between MIT and GPL: more share-alike than MIT, less all-or-nothing than GPL for combined products.
Common mistake: Treating MPL like AGPL. Hosting a service does not automatically force your whole stack open under MPL.
GNU Lesser General Public License 2.1
LGPL-2.1
LGPL-2.1 is a weak copyleft license designed mainly for libraries. You can often link it into other software more flexibly than GPL, but changes to the LGPL library itself still need to be shared when you distribute them.
- OSI open source
- Yes (OSI-approved).
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Yes for internal company use.
- Modify
- Yes. Distributed library changes generally stay under LGPL.
- Redistribute
- Yes, with source rules for the LGPL library portion and linking details that matter if you ship a product.
- Offer as a service
- Hosting is usually fine. Shipping modified binaries is where the source duties show up.
- Copyleft
- Weak, library-oriented.
- Notices
- Provide notices and corresponding source for the LGPL parts you distribute.
If you are running this software:
You can run LGPL software at home or work without special drama.
If you ship a custom image that includes modified LGPL libraries, plan to offer that library source.
If you are choosing a license for your own app:
Better suited to libraries than to full self-host apps when you want some copyleft without full GPL pressure on every program that links to you.
For a complete self-host application, AGPL or GPL usually send a clearer signal.
Common mistake: Reading LGPL as if it were MIT. It is friendlier than GPL for libraries, but it is still copyleft.
GNU Lesser General Public License 3.0
LGPL-3.0
LGPL-3.0 is the newer weak copyleft library license. It keeps the library-focused share-alike idea from LGPL-2.1 and updates the terms around combining and installing the library.
- OSI open source
- Yes (OSI-approved).
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Yes for internal company use.
- Modify
- Yes. Distributed library changes generally stay under LGPL-3.0.
- Redistribute
- Yes, with LGPL-3.0 source rules for the library portion.
- Offer as a service
- Private and company hosting are normally fine. Binary distribution is the trigger for the detailed duties.
- Copyleft
- Weak, library-oriented.
- Notices
- Ship notices and corresponding source for distributed LGPL parts.
If you are running this software:
Same practical story as LGPL-2.1 for people who only run apps.
If you are choosing a license for your own app:
Use it for libraries when you want modern GPL-3-era terms without forcing every combined work into full GPL.
Eclipse Public License 2.0
EPL-2.0
EPL-2.0 is a weak copyleft license used a lot in the Eclipse and Java tooling world. Source-sharing duties focus on the EPL modules you distribute, not automatically on everything around them.
- OSI open source
- Yes (OSI-approved).
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Yes for internal company use.
- Modify
- Yes. Distributed EPL changes need source under EPL terms.
- Redistribute
- Yes, with EPL source rules for covered modules.
- Offer as a service
- Hosting without shipping modified EPL code is usually simple. Modified packages need source compliance.
- Copyleft
- Weak in practice for modules.
- Notices
- Keep EPL notices and provide source for distributed EPL code.
If you are running this software:
Fine for self-host use. For operators it feels closer to MPL than to AGPL.
If you are choosing a license for your own app:
A natural fit if you are in the Eclipse or Java tooling ecosystem. Outside that world, MPL or Apache may be easier for contributors to understand.
European Union Public Licence 1.2
EUPL-1.2
EUPL-1.2 is a European copyleft license. You can use it commercially, but sharing and remote-access rules still apply, so it is not as free-form as MIT.
- OSI open source
- Yes (OSI-approved).
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Yes for internal company use.
- Modify
- Yes. Distributed derivatives generally stay under EUPL or a listed compatible license.
- Redistribute
- Yes, with EUPL source and copyleft rules.
- Offer as a service
- EUPL treats giving remote access as a form of distribution. If you offer a modified public service, source sharing may apply.
- Copyleft
- Copyleft with remote-use wording.
- Notices
- Keep notices and meet source rules when you distribute or offer covered public access.
If you are running this software:
Home and internal installs are fine. Public multi-tenant hosting of a modified version needs a careful read of the license text.
If you are choosing a license for your own app:
Common in EU public-sector and European open projects. If most of your users are global self-hosters, AGPL is often the more familiar network-copyleft option.
Common mistake: Putting EUPL next to MIT only because both allow commercial use. Commercial use is allowed. Share-alike and remote-use terms still matter.
Strong and network copyleft
GNU General Public License 2.0
GPL-2.0
GPL-2.0 is a strong copyleft license. You can run and change the software. If you distribute the program to other people, you must also provide the corresponding source under GPL terms.
- OSI open source
- Yes (OSI-approved).
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Yes for internal company use.
- Modify
- Yes for private use. Shipping modified versions means GPL source terms apply.
- Redistribute
- Yes, but the distributed GPL work stays under GPL-compatible terms with source.
- Offer as a service
- Running a server for users is not automatically the same as distributing the program. Shipping images, appliances, or downloads is.
- Copyleft
- Strong, triggered mainly by distribution.
- Notices
- Keep GPL notices and offer corresponding source when you distribute covered works.
If you are running this software:
Self-hosting GPL apps is normal and expected. Private changes on your own server stay private until you distribute them.
Companies hit GPL more often when they ship appliances or custom images, not when they only run the app inside the company.
If you are choosing a license for your own app:
Choose GPL when you want improvements that get distributed to remain free software under the same kind of terms.
If your real concern is a hosted competitor that never ships code to users, AGPL is the stronger network-oriented choice.
Common mistake: Thinking GPL bans commercial use. It does not. It requires that people who distribute the program also pass along user freedom and source access.
GNU General Public License 3.0
GPL-3.0
GPL-3.0 is the updated strong copyleft license. Like GPL-2.0, you can run and change it freely, and distribution of the program brings source-sharing duties under GPL-3.0 terms.
- OSI open source
- Yes (OSI-approved).
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Yes for internal company use.
- Modify
- Yes for private use. Distributed versions need GPL-3.0 source terms.
- Redistribute
- Yes under GPL-3.0 share-alike rules with corresponding source.
- Offer as a service
- Network hosting alone is not the same trigger as AGPL. Distribution of the program still is.
- Copyleft
- Strong, triggered mainly by distribution.
- Notices
- Keep notices and provide corresponding source on distribution.
If you are running this software:
If you only run an upstream Docker image, GPL-3.0 rarely changes your day-to-day work.
Forking the project and shipping a commercial appliance is where the duties become important.
If you are choosing a license for your own app:
A solid default when you want copyleft without AGPL's network trigger.
Many self-host apps choose AGPL instead because hosted SaaS clones are a more common risk than boxed appliances.
Common mistake: Using GPL and AGPL as if they were the same. AGPL adds a network interaction rule that GPL does not express the same way.
GNU Affero General Public License 3.0
AGPL-3.0
AGPL-3.0 is a strong open-source license with a network rule. You can run and change the software. If other people use your modified version over a network, you must offer them the corresponding source under AGPL.
- OSI open source
- Yes (OSI-approved).
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Yes for internal company use.
- Modify
- Yes. Private changes are fine. Network use of a modified version triggers a source offer to those users.
- Redistribute
- Yes under AGPL share-alike rules.
- Offer as a service
- Yes, but modified network services must offer corresponding source. Many companies buy a commercial license instead when they want closed changes.
- Copyleft
- Strong network copyleft.
- Notices
- Keep AGPL notices and provide corresponding source as required, including for network use of modified versions.
If you are running this software:
Running stock AGPL software for your family or company is normal. That is how most self-host AGPL apps expect to be used.
The hard case is changing the code and offering that modified service to outsiders without sharing the source.
If you are choosing a license for your own app:
A common choice for self-host web apps such as notes tools, media apps, admin panels, and collaboration software.
It keeps the project free for self-hosters while making it harder for someone to run a closed hosted clone of your modified code. Many teams also sell a separate commercial license for companies that need different terms.
Common mistake: Believing AGPL forbids self-hosting or company use. It does not. It protects users of network services from hidden modifications.
Open Software License 3.0
OSL-3.0
OSL-3.0 is a strong copyleft license with network-use language. It is less common than AGPL, but it raises similar questions when you offer software to other people.
- OSI open source
- Yes (OSI-approved).
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Yes for internal company use.
- Modify
- Yes, with OSL share-alike duties when you distribute or deploy in ways the license treats as distribution.
- Redistribute
- Yes under OSL copyleft terms.
- Offer as a service
- If you offer the software to third parties, source sharing may apply. Read the text before building a public service on it.
- Copyleft
- Strong, with network-sensitive terms.
- Notices
- Keep OSL notices and meet source requirements on distribution or external deployment.
If you are running this software:
Home and internal use are usually fine. Treat public service offerings carefully.
If you are choosing a license for your own app:
A valid copyleft option, but AGPL is better known in the self-host world. Prefer AGPL unless you have a specific reason to use OSL.
Source-available and restricted
Server Side Public License 1.0
SSPL-1.0
SSPL-1.0 is a source-available license created by MongoDB. You can often run and change the software yourself, but if you offer it as a service to other people, the license can require you to release a very large part of your service stack under SSPL.
- OSI open source
- No. Not OSI-approved.
- Home self-host
- Usually yes.
- Company internal use
- Usually yes when you are not selling a public or customer-facing service product built on it.
- Modify
- Yes under SSPL terms.
- Redistribute
- Yes under SSPL, with hard service-related conditions.
- Offer as a service
- Heavily restricted. Offering it as a service can require releasing the whole service stack under SSPL.
- Copyleft
- Source-available service copyleft.
- Notices
- Follow SSPL notices and source rules. Read section 13 before any managed offering.
If you are running this software:
Self-hosting for yourself or your company is usually the intended free path.
Do not call the project open source just because the source is on GitHub. SSPL is not OSI-approved open source.
If you are choosing a license for your own app:
Used when you want the code readable and self-host friendly, while making it hard for cloud providers to turn your software into their product without sharing a lot more source.
Expect pushback from some Linux distributions and enterprise open-source policies. AGPL is the OSI-approved alternative with a different edge.
Common mistake: Seeing public source and calling the project open source. Public source plus SSPL is source-available, not OSI open source.
Elastic License 2.0
Elastic-2.0
Elastic License 2.0 is a source-available license used by Elastic products. Self-managed use is usually allowed. Providing the product to others as a managed service is not.
- OSI open source
- No.
- Home self-host
- Usually yes for self-managed deploys.
- Company internal use
- Usually yes for internal self-managed use.
- Modify
- Yes within Elastic License limits.
- Redistribute
- Limited. Read before shipping derivatives.
- Offer as a service
- No for providing the software as a hosted or managed service under the license restrictions.
- Copyleft
- Source-available limits.
- Notices
- Do not remove licensing, copyright, or protection mechanisms the license forbids removing.
If you are running this software:
Running Elastic software yourself is the normal free path. Reselling Elastic-as-a-service is the blocked path.
Always check which license your exact version and distribution use, because Elastic has changed options over time.
If you are choosing a license for your own app:
A model if you want free self-managed adoption and still want to stop managed-service freeloading of your product.
Some projects later add AGPL or other options. Be explicit about which license each distribution uses.
Common mistake: Assuming Elastic License and SSPL are interchangeable. Both limit managed services, but the texts and product choices differ.
Business Source License 1.1
BUSL-1.1
BSL 1.1 is a source-available license with project-specific parameters. What you may do in production depends on that project's Additional Use Grant. After a published change date, the code converts to a named open-source license.
- OSI open source
- No until the change date converts it to the open-source license named in the BSL parameters.
- Home self-host
- Depends on the Additional Use Grant. Many grants allow self-host use. Read the parameters for that project.
- Company internal use
- Depends on the grant. Some allow internal production use if you are not competing with the licensor.
- Modify
- Usually yes under BSL terms and the grant.
- Redistribute
- Limited. Follow BSL and the project's grant text.
- Offer as a service
- Often restricted when the service competes with the licensor. That is the usual commercial boundary.
- Copyleft
- Source-available with delayed open-source conversion.
- Notices
- Keep the BSL parameters, change date, and grant text with the code.
If you are running this software:
Never assume one BSL project has the same rights as another. The Additional Use Grant and change date decide almost everything.
Home lab use is often allowed. Company production use needs a careful read of that specific project's grant.
If you are choosing a license for your own app:
Choose BSL when you want the source public now, limited competition for a period, and a future conversion to open source.
Write the Additional Use Grant in plain language. Self-hosters will judge the project on that paragraph.
Common mistake: Reading only the generic BUSL-1.1 text and ignoring the Additional Use Grant. The grant is where self-host production rights often live.
Functional Source License
FSL is a source-available license that allows broad use, with a temporary ban on competing commercial use. After a delay period, the code converts to Apache-2.0 or MIT.
- OSI open source
- No during the non-compete period. Becomes open source after the delay.
- Home self-host
- Usually yes.
- Company internal use
- Usually yes if you are not offering a competing product.
- Modify
- Yes under FSL terms.
- Redistribute
- Yes under FSL terms, with the non-compete limit during the restricted period.
- Offer as a service
- Allowed for many uses, but not for competing commercial products during the restriction window.
- Copyleft
- Source-available with delayed open-source conversion.
- Notices
- Keep the FSL text and note which open-source license applies after the delay.
If you are running this software:
Running the app for yourself is typically fine. Building a hosted competitor during the restricted period is the blocked case.
If you are choosing a license for your own app:
Useful when you want self-host freedom and public source, with a temporary shield against competing hosted products.
Labels like FSL-1.1-MIT tell people which open license arrives after the delay. Make that obvious in the repository.
Common mistake: Calling FSL open source on day one. It is designed as eventually open source, not immediately OSI open source.
PolyForm Noncommercial 1.0.0
PolyForm-Noncommercial-1.0.0
PolyForm Noncommercial allows non-commercial use, modification, and sharing. Commercial use needs a separate permission from the publisher.
- OSI open source
- No.
- Home self-host
- Usually yes for personal non-commercial self-hosting.
- Company internal use
- No under this license alone. You need another grant.
- Modify
- Yes for non-commercial purposes.
- Redistribute
- Yes for non-commercial purposes under the license terms.
- Offer as a service
- Not for commercial services.
- Copyleft
- Restricted source-available, non-commercial.
- Notices
- Keep license notices and respect the non-commercial boundary.
If you are running this software:
A personal home setup is usually allowed. A company deployment is not, unless the publisher sells or grants a commercial license.
If you are choosing a license for your own app:
Use this when free personal use is welcome and any company use should pay or ask first.
It will limit business adoption. That can be intentional.
Common mistake: Deploying PolyForm Noncommercial software on company infrastructure only because the repository is public.
PolyForm Shield 1.0.0
PolyForm-Shield-1.0.0
PolyForm Shield allows broad use of the software, except for using it to compete with the licensor's products.
- OSI open source
- No.
- Home self-host
- Usually yes.
- Company internal use
- Usually yes if your product is not a competitor under the license definition.
- Modify
- Yes under Shield terms.
- Redistribute
- Yes under Shield terms, excluding competing use.
- Offer as a service
- Allowed unless the offering competes with the licensor the way the license defines.
- Copyleft
- Source-available non-compete style limit.
- Notices
- Keep the license text and respect the competition boundary.
If you are running this software:
Self-hosting for normal personal or internal use is usually fine. Building a competing product needs a careful read.
If you are choosing a license for your own app:
A way to keep source readable and block direct commercial clones without banning all commercial use.
Define competition carefully. Fuzzy boundaries create support load and distrust.
Sustainable Use License
Sustainable Use License is a family of vendor source-available terms. Many versions allow free internal self-hosting, while limiting your right to offer the software itself to third parties as a service.
- OSI open source
- No.
- Home self-host
- Usually yes.
- Company internal use
- Usually yes for internal production use.
- Modify
- Often yes for internal use. Check the exact version text.
- Redistribute
- Limited. Many versions restrict providing the software to third parties.
- Offer as a service
- Usually no for multi-tenant or customer-facing hosting of the software itself.
- Copyleft
- Source-available internal-use style.
- Notices
- Follow the publisher's license file and any commercial upgrade path.
If you are running this software:
Treat the label as a family, not one universal text. Open that project's license page before any commercial hosting plan.
If you are choosing a license for your own app:
Used by products that want free self-host adoption and paid rights for offering the product to others.
If you use this pattern, publish a short plain-language FAQ next to the legal text. Self-hosters will look for it.
Common mistake: Assuming every Sustainable Use License matches another vendor word for word.
Proprietary EULAs and custom commercial licenses
A proprietary EULA or custom commercial license means your rights come only from that vendor agreement. There is no general open-source permission set underneath it.
- OSI open source
- No.
- Home self-host
- Only if the EULA says so.
- Company internal use
- Only if the EULA or paid plan says so.
- Modify
- Only if explicitly allowed.
- Redistribute
- Usually no.
- Offer as a service
- Only with a hosting or MSP grant.
- Copyleft
- Proprietary.
- Notices
- Follow seat counts, branding rules, and the vendor agreement.
If you are running this software:
Free to download is not the same as open source. Check personal versus business tiers before you put the software on a work server.
If you are choosing a license for your own app:
Fine when the product is commercial-first. Be honest in the README so directory users are not surprised.
If you also offer a free self-host community edition, say which features sit behind the paid EULA.
Common mistake: Assuming a free download is open source.
Public domain and Creative Commons
The Unlicense
Unlicense
The Unlicense is a public-domain style dedication. Where it works as intended, you can use, change, and share the software with almost no conditions.
- OSI open source
- Yes, as a public-domain-equivalent license.
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Yes for internal company use.
- Modify
- Yes.
- Redistribute
- Yes.
- Offer as a service
- Yes.
- Copyleft
- None.
- Notices
- None required, though keeping provenance is still smart.
If you are running this software:
There is little to worry about for running the software.
If you are choosing a license for your own app:
Maximum reuse, almost no protection. Many creators prefer MIT because company legal teams understand it better.
CC0 1.0 Universal
CC0-1.0
CC0 is a Creative Commons public-domain dedication. It is common for data and documentation, and sometimes used to waive copyright on code as far as the law allows.
- OSI open source
- Widely treated as public-domain dedication. For software, MIT or Apache are often clearer on patents.
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Yes for internal company use.
- Modify
- Yes.
- Redistribute
- Yes.
- Offer as a service
- Yes.
- Copyleft
- None.
- Notices
- No attribution required by CC0, though credit is still polite.
If you are running this software:
Fine for use. Remember CC0 addresses copyright. It does not clear trademarks.
If you are choosing a license for your own app:
Great for datasets, configs, and docs. For application source, MIT or Apache-2.0 usually create fewer surprises.
WTFPL
WTFPL
WTFPL is an informal do-what-you-want license. Practically it is very free, but some companies reject the text as unclear for policy purposes.
- OSI open source
- Not a license corporate policy teams rely on.
- Home self-host
- Yes for normal home self-hosting.
- Company internal use
- Practically yes, though legal teams may reject it.
- Modify
- Yes.
- Redistribute
- Yes.
- Offer as a service
- Yes under the license text.
- Copyleft
- None.
- Notices
- Almost none.
If you are running this software:
Fine for small utilities in a home lab.
If you are choosing a license for your own app:
If you want permissive terms people can trust, use MIT instead.
Creative Commons Attribution 4.0
CC-BY-4.0
CC BY 4.0 is a content license that requires attribution. It is built for creative works and data more than for application backends.
- OSI open source
- Not designed as a software OSI license.
- Home self-host
- Private use of covered material is fine. Confirm whether the project meant software, docs, or both.
- Company internal use
- Yes if attribution is handled when you share the material.
- Modify
- Yes, with attribution.
- Redistribute
- Yes, with attribution.
- Offer as a service
- Usually fine for using the material, with credit rules if you publicly share adapted content.
- Copyleft
- None. Attribution only.
- Notices
- Give the required credit when you share the material.
If you are running this software:
Check whether CC BY covers only docs and assets, while the application code sits under MIT, AGPL, or another software license.
If you are choosing a license for your own app:
Use CC BY for docs, diagrams, and media. Prefer a software license for application code.
Common mistake: Treating CC BY as a normal app license without checking which part of the project it covers.
Creative Commons Attribution-ShareAlike 4.0
CC-BY-SA-4.0
CC BY-SA 4.0 is a content license with attribution and share-alike. If you publicly share adapted material, that adaptation must use a compatible ShareAlike license.
- OSI open source
- Not a standard software OSI license.
- Home self-host
- Private use of covered content is fine.
- Company internal use
- Yes for use, with share-alike if you distribute adapted material.
- Modify
- Yes. Public sharing of adaptations triggers ShareAlike.
- Redistribute
- Yes under CC BY-SA terms.
- Offer as a service
- Depends on whether you are distributing adapted content. Running software is not the same as republishing a CC work.
- Copyleft
- ShareAlike for the covered content.
- Notices
- Attribution plus compatible ShareAlike licensing on adapted public releases.
If you are running this software:
You will mostly meet this on docs, wikis, diagrams, and media packs around self-hosting, not on Docker app backends.
If you are choosing a license for your own app:
Good for shared documentation communities. Keep application code on a software license.
Creative Commons NonCommercial licenses
CC-BY-NC-4.0
CC NonCommercial licenses allow free non-commercial use and require attribution. Company use and other commercial use need a different permission.
- OSI open source
- No.
- Home self-host
- Usually fine for pure personal non-commercial use of covered material.
- Company internal use
- No for company use without another license.
- Modify
- Yes for non-commercial purposes, with attribution and any ShareAlike rules.
- Redistribute
- Only non-commercially under the CC NC terms.
- Offer as a service
- Not for commercial services.
- Copyleft
- None or ShareAlike, plus NonCommercial.
- Notices
- Attribution, NonCommercial boundary, and ShareAlike if present.
If you are running this software:
Hobby use may be fine. Company wikis, marketing sites, and paid products need a separate grant.
If you are choosing a license for your own app:
Use when free personal sharing is welcome and commercial reuse should stop or pay. Expect lower business adoption.
Common mistake: Using NC-licensed material in company material without a separate grant.
Dual licenses and custom patterns
Dual licensing
Dual licensing means the same code is offered under two or more licenses. You follow one path, or different people are allowed to choose different paths.
- OSI open source
- Depends on which license you actually use.
- Home self-host
- Usually yes under at least one offered license.
- Company internal use
- Usually yes. Companies often buy the commercial path to avoid copyleft duties.
- Modify
- Depends on the chosen license.
- Redistribute
- Depends on the chosen license.
- Offer as a service
- Depends on the chosen license. AGPL plus commercial is a common pair.
- Copyleft
- Depends on the chosen license.
- Notices
- Say which license you are using when you redistribute.
If you are running this software:
Labels like AGPL-3.0/MIT mean you need the project's docs to know which option applies to your use.
If you only run upstream releases, follow the operator path the project documents.
If you are choosing a license for your own app:
A practical model is a free AGPL or GPL community edition, plus a paid commercial license for closed modifications or SaaS vendors.
Be explicit in the README. Dual strings without explanation create confusion.
Common mistake: Picking the friendliest short label from a dual string without reading which option applies.
Community edition plus enterprise modules
Many self-host products split the software into a community edition and paid enterprise modules. The core may be open or source-available, while features like SSO or support packs use a separate commercial license.
- OSI open source
- Only for the open parts. Enterprise modules are usually proprietary.
- Home self-host
- Community edition usually yes. Enterprise features only with a license.
- Company internal use
- Community under its own terms. Enterprise features need paid rights.
- Modify
- Follow the core license for core code. Enterprise code is usually closed or restricted.
- Redistribute
- Do not redistribute enterprise packages unless the contract says so.
- Offer as a service
- Core may allow self-host service use. Enterprise features and cloud rights are separate.
- Copyleft
- Mixed.
- Notices
- Keep community license notices and commercial agreement limits.
If you are running this software:
When you compare apps, check which features you need and which edition contains them.
A directory card can say AGPL or MIT and still hide SSO behind a paid module.
If you are choosing a license for your own app:
Very common for self-host businesses. Keep the free core genuinely useful or people will fork and leave.
Publish a clear feature matrix. That matrix is part of the license story for users.
Common mistake: Assuming every feature in screenshots is included in the community license.
or-later, linking exceptions, and mixed trees
Some projects use version suffixes, linking exceptions, or mixed licenses by folder. Those details change what you may do, even when the short label looks familiar.
- OSI open source
- Depends on each component.
- Home self-host
- Usually still fine for running upstream releases.
- Company internal use
- Usually fine, but product builders must map each component.
- Modify
- Follow each file or package license.
- Redistribute
- The strictest relevant duty wins for the combined work you ship.
- Offer as a service
- Map AGPL, SSPL, and commercial modules carefully before multi-tenant hosting.
- Copyleft
- Mixed or exception-limited.
- Notices
- Preserve each license's notices. Do not drop exception texts.
If you are running this software:
For normal self-host installs, run the release the project ships and you are usually fine.
If you vendor a monorepo into your own product, inventory the subfolder licenses.
If you are choosing a license for your own app:
Prefer one clear license for the main app, plus short notes for SDKs or docs if they differ.
GPL-2.0-only is not the same as GPL-2.0-or-later. Say which one you mean.
Common mistake: Trusting a single SPDX label on a multi-package monorepo without checking subfolders.