{
  "id": 13386399,
  "title": "Open source or source-available? 3 license traps to check before you self-host",
  "url": "https://urgent.news/2026/10/10/open-source-or-source-available-3-license-traps-to-check-before-you",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-10T10:36:17.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/sarmaasis/open-source-or-source-available-3-license-traps-to-check-before-you-self-host-44i2"
  },
  "original_language": "en",
  "account": "Assuming a project is merely \"open source\" simply because it is hosted on GitHub can lead to costly mistakes. Many widely-used self-hosted tools publish their code under licenses that impose restrictions on their use, with the consequences often becoming apparent only after deployment. In examining hundreds of self-hosted tools, three common patterns emerged.\n\nThe first pattern involves source-available licenses that resemble open source but come with limitations. For instance, n8n, a popular workflow automation tool on GitHub, uses the Sustainable Use License instead of an OSI-approved license. The Sustainable Use License restricts certain commercial uses, so while it may be suitable for specific needs, it's crucial to review the license terms rather than making assumptions. To identify this pattern, look for non-standard license names like Sustainable Use, Fair Source, Business Source, as opposed to the well-known open-source licenses such as MIT, Apache-2.0, GPL, AGPL, BSD, or MPL.\n\nAnother pattern involves open-source licenses being augmented with extra conditions that diminish the user's freedoms. A notable example is Chaskiq, a messaging platform similar to Intercom. Chaskiq's license is AGPL-3.0, but it incorporates the Commons Clause, which prohibits selling services whose value stems primarily from the software, including hosting and support. As a result, Chaskiq is considered source-available, as indicated by GitHub's license badge displaying \"Other\" instead of the standard OSI-approved badges. To recognize this scenario, watch for a license badge labeled \"Other,\" \"NOASSERTION,\" or a LICENSE file beginning with a preamble before the standard license text.\n\nThe third pattern revolves around projects offering a combination of open-source and proprietary components, known as source-available or open-core models. Windmill, for example, has an open-source core with additional enterprise features available under a commercial license, potentially depending on the deployment. Some projects maintain enterprise code in separate directories like ee/ or enterprise/, each accompanied by distinct licenses. To detect this pattern, search for directories such as ee/ or enterprise/ alongside multiple LICENSE files or installation instructions directing users to \"community\" or \"enterprise\" images.",
  "summary": "\"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…",
  "key_points": [
    "Source-available licenses restrict commercial use, unlike open source; review terms carefully.",
    "AGPL-3.0 license with Commons Clause in Chaskiq prevents selling services based on software value."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}