"It's on GitHub, so it's open source" is one of the most expensive assumptions a team can make. Plenty of popular self-hosted tools publish their code under terms that restrict how you can use it, and the difference often only matters once you are in production.
While cataloguing a few hundred self-hosted tools, these are the three patterns I see most often.
Trap 1: A source-available license that looks like open source
Some projects publish all of their code under their own license instead of an OSI-approved one.
Example: n8n. n8n is one of the most popular workflow automation tools on GitHub, and you can self-host it. But it uses the Sustainable Use License, not an open-source license, and its terms limit some commercial uses. It may be fine for what you are doing. The point is that you have to read the license for your use case instead of assuming.
How to spot it: the license name is the project's own ("Sustainable Use", "Fair Source", "Business Source") rather than MIT, Apache-2.0, GPL, AGPL, BSD or MPL.
Trap 2: An open-source license with a condition added
A project can take a real open-source license and attach an extra condition that removes a freedom.
Example: Chaskiq. Chaskiq is a messaging platform modelled on Intercom. Its LICENSE file is AGPL-3.0 with the Commons Clause added, which removes the right to sell services whose value comes substantially from the software, including hosting and support. That makes it source-available. GitHub's license badge shows "Other" for it, a hint to open the file itself.
How to spot it: the license badge says "Other" or "NOASSERTION", or the LICENSE file starts with a preamble before the standard text.
Trap 3: The same project, different builds
Many projects are open-core: an open-source core plus enterprise features under a commercial license, sometimes in the same repository.
Example: Windmill. Windmill distinguishes the community binaries it distributes from an AGPL build you compile from source, so which terms apply depends on what you deploy. Other projects keep enterprise code in a separate directory, such as ee/ or enterprise/, under a different license.
How to spot it: look for ee/ or enterprise/ directories, more than one LICENSE file, or install docs that point to a specific "community" or "enterprise" image.
The five-minute check
Before you put a self-hosted tool into production:
- Open the LICENSE file, not just the GitHub badge.
- Check whether the license is OSI-approved. If it is not, read what it restricts.
- Look for added conditions such as the Commons Clause.
- Find out which build or image you are actually deploying, and which license covers it.
- If it is AGPL and you will modify it and offer it over a network, understand your obligation to share those changes.
None of this means source-available tools are bad. Several are excellent. It means the license is part of the decision, alongside features and maintenance activity.
I built PickOpenSource to show the license, hosting model and repository activity for each project side by side, and you can browse tools by license, for example everything under AGPL-3.0. If you have been caught by a license surprise, I would like to hear about it in the comments.
Top comments (0)