What is a Source-available license?

What the category withholds

Open source is defined by four freedoms: run the program for any purpose, study how it works, redistribute copies, and improve it by publishing modifications, with the last one carrying an obligation to pass those freedoms on. Source-available means the code is published and the first two of those are usually intact, while one of the rest is restricted.

Knowing which one is restricted is the entire analysis, and the restrictions fall into a few recognisable shapes.

The service restriction. You may use it, self-host it, modify it internally, and you may not offer it to third parties as a hosted or managed service. This is the fair-code arrangement, and it is the reason the category is largely populated by companies whose product is a hosted version of software they also give away. n8n-io/n8n is the clearest case on this list: our analysis describes a visual canvas with custom JavaScript and Python, more than fifteen hundred integrations, running either from Docker on your own machine or in the vendor's cloud, and it names the licence as the part most teams underestimate.

The commercial restriction. Free for individuals, research and evaluation, not for commercial use without a separate agreement. shengjidaguai-china/BossHunter is an example, and its own description says commercial use requires written authorisation.

The redistribution restriction. You may run it and you may look at it, and you may not pass it on. WhiteDNS/WhiteDNS-Android is described in our analysis as source-available rather than open source with a licence that restricts redistribution, which rules out a whole class of delivery model at a stroke.

The field-of-use restriction. Permitted for one purpose and not another. Keychron/Keychron-Keyboards-Hardware-Design is the case in this list, where the analysis describes design files for a hundred-plus models published under a source-available licence that allows commercial use for original compatible accessories within its terms.

What all of them have in common is that a compliance scan will flag them, an OSI check will fail, and the text was written by someone with a specific competing business in mind.

How this differs from the categories either side

It helps to be precise about the neighbourhood, because the three categories are often confused in a way that causes real problems.

Against open source. The difference is not the visibility of the source; the source is right there. The difference is the grant. Open source grants unconditional rights and attaches a condition; source-available grants rights and attaches a restriction on what you may do with them. A project can be fully readable and still be the opposite of free software.

Against proprietary software. A proprietary product gives you an object and a support contract. A source-available product gives you the code, which means you can audit it, patch it, run it on your own hardware, and be rid of the vendor. That is a real and substantial difference, and it is the honest answer to the claim that the two categories are the same.

Against open core. Open core is a licensing and business arrangement rather than a licence type: a codebase that is open in one part and proprietary in another. It is compatible with either category, and the interesting question is always which directory the feature you need is in.

The term fair-code is used loosely and often as a synonym for source-available. It is closer to a description than a licence, and several incompatible licences get described that way, so it is a poor thing to put in a policy document.

One more difference from the past. Source-available licences are not new, but the reason they became common is specific: a hosted business model and a self-hosted distribution can now be the same codebase, and a licence that forbids the hosted use is what stops the free version from eating the paid one. That is a reasonable business decision and it is also the thing that makes the category worth understanding before you depend on it.

When it is the right choice, from both sides

For the publisher, the category is sometimes the only workable arrangement. Charging for a hosted service and giving the software away for self-hosting is a coherent business, and a copyleft licence would be a worse tool for the same goal because it constrains what the licensees may do with the code rather than what the publisher may do with the offering. hashicorp/terraform is the standard illustration of a company publishing a source-available tool and selling a commercial edition, and our analysis of Terraform describes the core as a Go binary that turns declarative configuration into an execution plan and then into provider API calls.

For the user, the case is genuine when four things hold. You need to self-host. You want to read the code. The restriction is one you do not hit. And the project is maintained. A source-available project that satisfies those four is often a better partner than a proprietary one that satisfies none of them.

The counter-case is equally real. The restriction is usually written against the one thing you might want to do: offer the same capability commercially. Adopting a source-available dependency is a decision about your own business model made by someone else's licence, and it should be made before the integration, not after a review finds it.

There is a third case that is often the practical one. A product that is source-available for its own reasons and which you have already decided to buy commercially anyway costs you nothing extra, and it gives you the source, the ability to patch, and the ability to leave. That is a real benefit that does not require the licence to be free software.

The traps

Six, and the fourth is the one that has ended more projects than the licence itself.

Free to use, not free to compete. The restriction is usually aimed at the case where you become a competitor, and it will be written broadly enough to catch you. Read the definition of the prohibited use rather than the title of the licence.

The hosted version has its own terms. The self-hosted version and the vendor's cloud are two products, and the one you are reading the licence for is often the one with less support behind it.

The self-hosted path is the lesser path. invoiceninja/invoiceninja is the honest illustration: our analysis describes Invoice Ninja 5 as a Laravel application for invoices, quotes, projects and time tracking, shipped as a hosted service or as a self-hosted install, with a documented API and a fast release cadence, and it notes that the self-hosted path asks for real operational work. A fast cadence aimed at the hosted product is not the same as support for the one you run.

Abandonment. alienator88/Pearcleaner is a source-available Mac app cleaner with orphaned file search, a Homebrew manager and a trash monitor, and our analysis records that its README states development stopped at the end of 2025, which makes the question whether the current build still fits your Mac. sharetribe/sharetribe is the same category one step further along: our analysis describes Sharetribe Go as a Ruby on Rails marketplace application that is no longer actively maintained, with the last push on 2026-05-11, running on MySQL and Sphinx under a community public licence rather than an OSI one. A source-available project with nobody maintaining it has no upgrade path, no support, and a licence that will never be renegotiated.

Relicensing. Your product depends on code whose terms can change with a release. That has happened in this category more than once, and the cost lands on every downstream user at once.

Redistribution limits break delivery. If the licence forbids redistribution, you cannot vendor the code, cannot ship it inside an appliance for a customer, and cannot pass it to a contractor. That is a procurement conversation, not a legal footnote.

How the projects divide

The ten projects here cover the range, including one category that is easy to overlook.

Hosted platforms with a self-hostable build. n8n is the archetype: the analysis describes a visual workflow builder, custom code in two languages, a large integration catalogue, and a choice between your own Docker and the vendor's cloud. Adopting it means deciding whether you intend to compete with it.

Infrastructure tooling sold commercially. Terraform is the case, and the pattern is the opposite of n8n's: the source is published and the company sells a different, more capable version to the same audience.

Business applications. invoiceninja/invoiceninja publishes the code and sells hosting, which is the arrangement above with an actual invoice attached.

Design assets, not software. Keychron publishes CAD files in several formats for a hundred-plus models, and the analysis describes the licence allowing commercial use for original compatible accessories within its terms. Shopify/dawn is the same idea in a different medium: our analysis describes it as a source-available reference theme on the Online Store 2.0 platform, HTML-first with JavaScript used only as needed, and a starting point for theme developers rather than a finished storefront. A reference theme is not something an end user installs, which changes what the licence is for.

Utilities and clients. Pearcleaner for local cleanup, WhiteDNS for DNS tunnelling on Android with proxy and VPN modes; both are the shape where a source-available grant lets people inspect and patch but not redistribute.

A small agent tool. shengjidaguai-china/BossHunter automates job collection, scoring and message drafting across four Chinese recruitment platforms, and our analysis notes that every application still needs human confirmation and that the agent stops rather than bypassing a CAPTCHA, a rate limit or a login wall, under a noncommercial source-available licence. This is a licence designed to prevent a commercial tool, and the safety behaviour is a separate design decision.

The smallest case is a skill rather than a program. Evianis/travel-photo-abstraction is described in our analysis as a source-available Codex skill that inventories the visual facts of a photograph, maps them to minimal marks and pixel-verifies the result against the untouched original, with a strict licence and a hard dependency on Codex image generation. A licence can be as small as the artefact it covers, and the analysis you still have to do is the same.

And the generation that ended. Sharetribe Go represents what happens when a source-available project stops: the code remains, the licence remains, and neither of them is a maintenance commitment.

In practice

A source-available licence is a business model expressed as a licence, and the analysis of one is short: which freedom is restricted, whether you hit that case, and who is maintaining it. Read the definition of the prohibited use rather than the licence name, check whether the self-hosted path is the supported one, and treat abandonment as the largest risk because no source-available project carries a commitment to keep releasing. Publish a policy that says what your company will and will not adopt before a scanner decides for you, and when you do adopt one, keep the boundary in your dependency list so a future maintainer knows it was a decision rather than an accident.