Show HN: Supso, a CLI for selling licenses to your projects(github.com)

Published Jun 11, 2026

Launching supso: the CLI for paid licensing with Supported Source

A command-line tool for paid licensing, so project owners get paid

Today we're introducing supso, the official command-line tool
for Supported Source. Supported Source helps maintainers get paid,
by selling paid licenses to their projects. But how will companies certify they
bought a license? The answer is supso: companies can use supso to sync their license
certificates from our website to their local file system.

You can find it on GitHub at
github.com/SupsoOrg/supso.

What supso does

Supported Source projects are commercial open source: hobbyists and evaluators
can use them for free, but companies pay for a license. A license is just a
certificate that cryptographically proves your organization is allowed to use
a given project. supso is the tool that manages those certificates
on disk and verifies them, so your projects work and your builds stay green.

The mental model is simple: certs is what you have installed,
projects is what you're licensed for, and verify is
the scriptable yes/no gate you can drop into CI or a build script.

Getting started

supso ships as a single static binary, so installing it is a one-liner whichever
way you prefer:

brew install SupsoOrg/tap/supso # Homebrew
cargo install supso # or from crates.io

Once it's installed, sign in and pull your certificates down:

supso login # sign in via the browser
supso sync # pull your licensed certificates into ~/.supso
supso certs # see what's installed

After that, your licensed projects just work. You can also use supso verify
to double check that the certs you've synced are verifying.

Built for deploys

Verification happens offline at runtime. When you ship a service that
embeds a Supported Source project, the
supso-project
library checks the license certificate locally. There's no network call or login
flow in production. You provision the certificate the same way you'd provision
any other deploy secret, either by mounting it into a directory and pointing
SUPSO_LICENSE_PATH at it, or by baking it into your build artifact:

supso sync --dir ./.supso/license_certificates
# at runtime: SUPSO_LICENSE_PATH=/app/.supso/license_certificates

Because a certificate identifies your organization, you can treat it like your
existing secrets. Just keep it out of public source control, and don't run the interactive login flow
inside a deployed service.

Why this matters

The point of supso isn't really the certificates. It's what they make possible.

Open source built the modern world, and it did so with almost no financial
support. The people who maintain the libraries everyone depends on are, with
very few exceptions, not paid for it. They do it on nights and weekends until
they burn out and walk away, at which point the multi-billion-dollar companies
depending on their work scramble to find someone else to do it for free. It's
the tragedy of the commons, and it's a structural problem, not a personal one.

Supported Source exists to fix that. Companies are happy to pay for software
that's reliable, supported, and secure. They do it all the time. What's been
missing is a good way to do that with their dependencies. Supported Source is
the missing piece: it's how a company licenses a project, and it's how the
revenue from that license flows back to the maintainer who built it.

If you maintain a project that companies depend on, that means you can get paid
for it. The license fees companies pay to use your project go to you, so the
work everyone relies on is funded. This helps a project stay healthy because
there's an actual business model behind it.

If you maintain a project companies depend on,
get in touch to see how we can help you get paid for it.

Open source built the world. Supported Source helps the people who build it.