What source-available means for your self-hosted tools

Software licensing is one of those topics that matters more than most people realize. When you pick a self-hosted tool, the license determines what you can actually do with the code. Not just whether you can run it, but whether you can read it, audit it and trust it long-term.

A source-available project management tool is one where the source code is published and readable, but the license restricts certain uses like redistribution or commercial resale. It sits between fully proprietary software (where you never see the code) and open source software (where the license grants broad freedoms including modification and redistribution).

TL;DR: Source-available means the code is public and readable, but the license limits redistribution. It gives you the ability to audit, inspect and verify the software you run. It is different from open source, which grants broader rights. For self-hosted tools, source availability is what enables trust.

How does source available project management differ from open source?

The difference comes down to what the license allows. Both source-available and open source projects publish their code. You can read every line. The distinction is in the permissions.

Open source licenses (MIT, Apache 2.0, GPL and others) grant you the right to use, modify and redistribute the software. You can fork it, change it and ship your own version. The Open Source Initiative maintains a formal definition with ten criteria that a license must meet.

Source-available licenses publish the code but restrict some of those rights. Typically, you can read and run the software. You can modify it for your own use. But you cannot redistribute it commercially or create a competing product from it.

Here is a practical way to think about it:

• Proprietary: You get a binary. You cannot see how it works. You trust the vendor completely.
• Source-available: You get the full source code. You can read and audit it. The license limits what you can do with it commercially.
• Open source: You get the full source code with broad rights to modify and redistribute.

For someone evaluating a self-hosted tool, the key question is usually: can I read the code? Both open source and source-available answer yes. The redistribution restrictions in source-available licenses rarely matter to teams who just want to run the software on their own infrastructure.

Why does code visibility matter for self-hosted tools?

When you self-host software, you are running it on your servers, inside your network, handling your data. That is a different trust relationship than using a cloud service.

With a cloud tool, you trust the vendor's security team. You read their SOC 2 report and hope for the best. With a self-hosted tool, you can go further. If the code is available, your team can actually read it.

This has practical consequences:

• Security audits. Your security team can review the codebase before deploying it. They can check how authentication works, how data is stored, how secrets are handled. No black boxes.
• Dependency review. You can see exactly which libraries the software uses. You can check for known vulnerabilities in those dependencies.
• Update evaluation. Before applying an update, you can read the diff. You can see exactly what changed between versions and decide whether to upgrade.

None of this requires the right to redistribute the code. It just requires the right to read it. Source-available licenses give you that.

What is the spectrum from proprietary to open source?

It helps to think of software licensing as a spectrum rather than a binary choice. Here is how common tools fall along it:

Fully proprietary. Asana, Monday.com, ClickUp. You never see the source code. You trust the vendor entirely. If they shut down, you export what you can and move on.

Source-available. GitLab (Enterprise Edition), Sentry, Eigenfocus. The code is published and readable. You can audit it, run it on your own servers and inspect every update. The license restricts commercial redistribution.

Open source. Planka, OpenProject, Taiga. Full source code with permissive or copyleft licenses. You can fork, modify and redistribute.

Each position on this spectrum involves trade-offs. Proprietary tools invest in polished UX because their business model does not depend on community contributions. Open source tools benefit from community patches and forks. Source-available tools try to combine code transparency with a sustainable business model.

The right choice depends on what you need. If you need to fork the software and build your own product on top of it, you need open source. If you need to read, audit and verify the software you deploy, source-available gives you that.

See Eigenfocus pricing and editions.

How does source available project management affect security audits?

Security teams think in terms of attack surface and verifiability. When they evaluate a tool for internal deployment, they want to answer a simple question: what does this software actually do?

With proprietary tools, the answer comes from the vendor. You get a whitepaper, maybe a penetration test report, possibly a SOC 2 certification. All of these describe what the vendor says the software does. You cannot independently verify it.

With source-available tools, your security team can verify it themselves. They can:

1. Review authentication logic. Check how passwords are hashed, how sessions work, how SSO is implemented.
2. Inspect data handling. See exactly how your project data is stored, encrypted (or not) and transmitted.
3. Check for telemetry. Verify whether the software phones home or sends any data to external servers.
4. Audit update mechanisms. Understand how the update process works and whether it introduces any risk.

This is not theoretical. Organizations in regulated industries (finance, healthcare, government) often require source code review as part of their vendor evaluation process. Source-available licenses make that possible without requiring a special agreement or NDA with the vendor.

For a closer look at what self-hosted infrastructure actually requires, see what self-hosted project management actually costs to run.

Does source-available mean the software could disappear?

This is a fair concern. If the company behind a source-available project stops maintaining it, you are left with code you can read but cannot freely redistribute or fork into a new project (depending on the specific license terms).

But consider the alternative. If a proprietary cloud tool shuts down, you lose both the software and potentially your data. If a proprietary self-hosted tool stops getting updates, you have a binary you cannot patch. At least with source-available code, you can read it, understand it and maintain a running instance.

Some source-available licenses also include provisions for relicensing under open source terms if the project is abandoned. Even without that, having the code means you can continue running the version you have, fix critical bugs for your deployment and make informed decisions about migrating.

The real question is not whether the license is perfect. It is whether you have more or less control compared to proprietary alternatives. Source-available consistently gives you more.

What should you look for when evaluating a source-available tool?

If you are considering a source-available tool for your team, here are the things worth checking:

• Where is the code published? A public GitHub or GitLab repository is the standard. If the code is only available "on request," that is a different level of transparency.
• What license is it under? Read the actual license file. Check what is allowed and what is restricted. Most source-available licenses are short and readable.
• How often is the code updated? A public repository with regular commits shows active development. You can see the pace and quality of changes.
• Can you run the published code? Some projects publish source code but require proprietary build tools or dependencies. The code should be buildable and runnable from the public repository.
• Does the license allow your use case? Most source-available licenses allow running the software for internal business purposes. Restrictions usually apply to redistribution and competing commercial use.

Eigenfocus, for example, publishes its Free Edition source code on GitHub. You can read it, clone it, build it and run it. The code is there for anyone to inspect.

For teams that care about what runs on their servers, code visibility changes the conversation from "do we trust this vendor?" to "we have read the code and we know what it does."

How does this connect to data ownership?

Source availability and data ownership are related but separate. Source availability means you can read the code. Data ownership means you can read your data.

The strongest position is having both. When you can inspect the source code and directly access your database, there is very little you have to take on faith. You know how your data is stored because you can read the code that stores it. You know your data is intact because you can query it directly.

Eigenfocus stores everything in a single SQLite file. Combined with public source code, this means you can verify the full picture: what the software does with your data and what your data actually looks like on disk. For more on the data side, see data ownership in PM: where does your data actually live?.

Frequently asked questions

What is the difference between source-available and open source?

Both publish their source code publicly. The difference is in the license. Open source licenses (MIT, Apache 2.0, GPL) allow modification and redistribution. Source-available licenses let you read, audit and run the code but restrict commercial redistribution. For teams evaluating self-hosted tools, both provide code transparency.

Can I modify source-available software for my own use?

In most cases, yes. Source-available licenses typically allow you to modify the code for internal use. What they restrict is distributing your modified version commercially. If you want to tweak something for your own deployment, that is usually fine. Always check the specific license terms.

Is source-available software less secure than open source?

No. Security comes from code quality and review practices, not from the license type. Source-available code can be audited just as thoroughly as open source code. The code is equally visible. The only difference is in redistribution rights, which do not affect security.

Why would a company choose source-available over open source?

Source-available lets a company publish its code for transparency while maintaining a sustainable business model. Without redistribution restrictions, competitors could take the entire codebase and offer it as their own product. Source-available balances code transparency with commercial viability.

Can I self-host a source-available tool on my own servers?

Yes. Source-available licenses are designed to allow exactly this. You can deploy the software on your own infrastructure, manage your own data and control your own updates. The license restrictions apply to redistribution, not to running the software for your team.

Evaluate your tools by what you can verify

Licensing is not just a legal detail. It determines how much you can see, verify and control about the software you depend on. For self-hosted tools especially, code visibility is a practical feature, not a philosophical stance.

Eigenfocus is source-available, runs in a single Docker container and stores everything in SQLite. You can read the code. You can read your data.

See pricing and get started

Explore how teams use Eigenfocus for self-hosted deployment or as a public-source alternative to closed-source tools. For a comparison of self-hosted PM tools across the spectrum, see self-hosted PM: more than a Kanban board, less than Jira.