You find the GitHub repository, send the link to IT and ask for a code review. IT opens it. There is a roadmap and an issue tracker, but no product code to review.
For Pharen Hub, that distinction is real: our public repository contains the roadmap and issues. Access to the product code needs to be clarified separately.
The confusion begins when “open” is made to answer three questions at once: can you see the code, what may you do with it, and can you run it yourself? Follow those questions separately and the difference between fair-code and open source becomes much easier to understand.
Access does not grant every right
You can read a book without acquiring the right to sell copies. Software terms work differently, but the distinction is useful: access to the material and rights over it are separate questions.
The OSI Open Source Definition sets requirements for open-source licences, including rights concerning redistribution and modification. A qualifying licence cannot exclude particular fields of use. Commercial use cannot simply be prohibited.
Showing the code is therefore not enough. The licence explains what you may do with it. That matters in procurement. Will your developers make changes? Will the software become part of a service you provide to customers? Those plans may engage different terms.
Fair-code is a model, not one licence
Fair-code describes a model in which source is available and commercial use may be restricted. The particular licence defines those restrictions. The name alone does not establish permission for your intended use.
This does not make the product unsuitable. Its terms may fit your organisation well. But a requirement for an OSI-compliant licence should not be replaced with a similar-sounding label.
Request the actual licence for the product and version under consideration. Compare your intended use with its terms. Where the answer is unclear, obtain a reliable clarification from the vendor rather than relying on the most generous reading of a marketing page.
Your own server creates operating responsibilities
Self-hosting establishes where an application can run. By itself, it says nothing about permission to modify or redistribute the code.
An open licence also does not promise that somebody will maintain your installation. Open-source software can be offered as a managed service. Software with other licensing terms may be available to run on your server. The combinations vary because licensing and operation remain separate decisions.
For an AI application, include the model service. A locally hosted interface can call an external model. Understanding the data path means examining the whole setup, not just the location of one component.
What to establish with Pharen
We describe Pharen Hub as open fair-code. It is not offered as OSI open source. Before a code review, establish with us which parts are accessible, what rights apply to your intended use and how updates are provided.
Your own deployment adds practical questions: which components are required, who maintains them, and how can data be backed up and restored? The self-hosting page is a starting point for that operating discussion. It does not replace the licensing question.
This remains worth doing when you already like the product. A convincing demonstration can show that a workflow is promising. It cannot establish that the rights and responsibilities fit your organisation.
Ask for three concrete things
You need the applicable licence, a clear description of code access and an operating agreement. Together they should explain what you may inspect, use and change, and who takes care of the running system.
Ask us for the code access and terms needed for your review.
