You can read the code. Excellent. Can you run it for your customers, modify it, or pay someone else to host it?
Those are separate questions, and the answer is in the licence rather than the enthusiasm of the landing page.
The short answer: open-source software carries rights consistent with the Open Source Definition. Source-available software exposes source code but may restrict uses, redistribution or commercial competition. Visible code is not the same promise as an open-source licence.
What makes software open source?
The Open Source Initiative’s definition covers more than access to source. It includes redistribution and derived works, and rejects discrimination against people, groups or fields of endeavour.
That is why a licence prohibiting commercial use or a particular business activity should not casually be described as open source. A restriction may be commercially understandable and still fall outside the definition.
Open source does not mean that every service is free, that support is included or that there are no obligations. The licence comparison explains several common permission and copyleft models.
Compare rights rather than labels
| Question | Open-source expectation | Source-available caution |
|---|---|---|
| Can I inspect the code? | Source must be available under the licence | Usually, but check what is included |
| Can I modify it? | Modification and derived works are permitted under conditions | Permission may be limited |
| Can I redistribute it? | Redistribution is permitted under conditions | Distribution may be restricted |
| Can I use it commercially? | Commercial use is not excluded as a field | Commercial or competing uses may be prohibited |
| Can I offer a hosted service? | Check applicable licence obligations | Hosting may require separate permission |
| Can I obtain support? | A separate practical and commercial question | Also a separate question |
Neither column establishes security or business suitability. Both require an evaluation of the actual product and deployment.
Follow the exact version
Projects can change the licence of later releases, use different licences for different components, or offer community and commercial editions. Record the release you plan to use and preserve its licence text with your evaluation.
Do not assume that an older article describing a product still applies to its current version. Equally, do not assume that a later licensing announcement changes every right you received under an earlier valid licence. The facts and terms require inspection.
A dependency can also introduce different obligations from the main application. Review the components actually shipped or deployed, not simply the badge at the top of the repository.
An illustrative procurement problem
Imagine a consultancy selecting a source-available workflow tool for internal work. Its intended use may be permitted. Later it decides to package that tool as a hosted service for clients, and discovers that the licence restricts that business model.
The mistake was not necessarily choosing source-available software. It was failing to test the foreseeable use against the licence before building a commercial dependency around it.
Write the intended use plainly: internal service, client installation, modified distribution, embedded component or hosted offering. Ask the supplier to identify the terms covering it, and have uncertain boundaries reviewed.
Source-available can still be the right choice
A product may meet your needs with acceptable terms, good support and a workable exit route. There is no prize for rejecting it on principle if the rights are sufficient and the trade-offs are understood.
The problem is buying one set of freedoms while believing you bought another. Keep the commercial discussion honest. If your requirement is supplier substitution or unrestricted commercial redistribution, make that explicit in procurement.
For public infrastructure, the ability to sustain a service and change suppliers may matter over a much longer period than the initial implementation. The digital sovereignty worksheet widens the assessment beyond the software licence.
Keep a rights and exit record
Record the component, version, licence, intended use, restrictions, support arrangement and exit assumptions. Attach the source of the terms and the date checked. Assign an owner to revisit the record before a major upgrade or business-model change.
Test data export and replacement options alongside the legal review. A legal right to leave does not magically produce a usable migration path.
Choose the software with your eyes open about the bargain. Calling everything open source makes the conversation easier for about five minutes. It makes the eventual procurement problem considerably harder.
Sources and scope
Reviewed 1 November 2026. The examples and worksheets are my suggested working methods, not measured client results or official standards.
