Source Available vs Open Source: The Three Questions That Settle It

A procurement reviewer opens a vendor's GitHub repo, sees a public link, and ticks the open source box on the security questionnaire. Nobody checks further because the code is right there, readable, forkable in theory. This happens most weeks for any QA lead evaluating a test management tool. It happens fast because the reviewer has forty other line items to close before lunch. The problem is that a public repo tells you almost nothing about what you are actually allowed to do with the code. The real question is source available vs open source, and the two get confused constantly. This post gives a non-lawyer a reliable way to tell them apart in about five minutes. It uses three questions that actually settle it, and explains why the distinction started mattering commercially rather than philosophically.

The plain difference between the two

Open source gives you three freedoms at once. You can run the software for any purpose. You can modify it and run your modified version. You can pass it on to someone else. Source available gives you the first of those, reading the code, and then restricts one or more of the other two. The repository can look identical either way. The licence file is where the real difference lives, and almost nobody reads it before the questionnaire is due on Friday.

That gap between what a repo looks like and what its licence permits is exactly where teams get caught out later, often during a security review or an acquisition, long after the tool is already in production.

The three questions that actually settle it

You do not need a law degree to tell the two apart. You need to ask the licence three plain questions and see which ones it answers no to.

• Can I run this software for any purpose, including a commercial one, without asking permission first?
• Can I modify it and run my modified version, for my own use, without restriction?
• Can I pass it on to someone else, modified or not, under the same terms I received it?

An open source licence answers yes to all three. A source available licence answers no to at least one. Usually it is the third one, and often with a carve out aimed at a specific kind of use, like reselling the software as a hosted service.

The licences a reader will actually meet

Most people run into a small handful of these repeatedly. It helps to know the shape of each one before it shows up in a vendor contract.

• The Business Source Licence, BSL, restricts commercial use for a fixed period, often three years. After that it converts to a fully open licence. The delay is the whole mechanism.
• The Server Side Public License, SSPL, permits almost everything except offering the software as a hosted service to third parties. That is the one use case it targets directly.
• Bespoke clauses, often written by the vendor's own lawyers, say something close to "you may not offer this as a service" without adopting a recognised licence at all.

None of these are open source under the common definitions the industry uses. Yet the source code for each one sits in a public repository, often right next to projects that genuinely are open source, which is exactly why the confusion spreads.

Why this became a commercial question, not a philosophical one

A decade ago this distinction mostly showed up in mailing list arguments about software freedom. It matters differently now. Several well known open source projects relicensed as they grew, moving from a fully open licence to something closer to source available. The usual reason was to stop a large cloud provider from reselling their software as a managed service without contributing anything back.

The README often did not change a single word during that transition. The licence file did. A reader who only skims the top of the repository can easily miss a change that reshapes what they are allowed to do with code they have already been running for two years. Nobody sends a memo when a licence file changes. Someone in procurement finds it during the next renewal.

What this means for a test management tool specifically

For most QA organisations evaluating a self hosted test management tool, the freedoms that matter are narrow and practical. The team wants to run a modified build internally, maybe with a custom field type or an internal integration, for its own testers. That is close to the least demanding thing you can ask a licence to permit. It is also exactly the use case that source available licences most often still allow.

The restrictive clause usually targets someone reselling the software as a service, not a QA team running its own fork behind its own firewall. Reading the licence with that specific use in mind answers the practical question much faster than debating the abstract label of "open" versus "not open".

Where a 1,400 case suite meets the licence question

A QA lead migrating a 1,400 case suite off a legacy tool typically asks two things of a new one. Can the team run it themselves, and can they modify it if a custom workflow shows up later. Those two questions map almost exactly onto the second of the three freedoms above.

A tool with a clear open source licence, Apache 2.0 for example, answers yes without qualification. A tool under a source available licence might still answer yes for internal use, but the reviewer has to actually read the clause rather than assume it from a badge on the landing page. Our notes on avoiding vendor lock-in cover the related question of what happens when you eventually want to leave a tool, which is worth reading alongside this one.

A short honest note before you sign anything

Everything above describes the shape of these licences in plain terms, not a legal opinion on any specific one. Licence text is written by lawyers for a reason, and small wording differences change outcomes. If a decision touches a contract, a customer commitment, or an acquisition, take the specific licence text to your own counsel before you rely on any summary, including this one.