A checklist you can actually run in five minutes — before anything touches your machine.
Section 01Start with the source: who made it and why
The first thing to ask about any program is not "does it do the thing?" but "who is behind it?" For a well-known open-source tool — VLC, KeePassXC, Audacity, LibreOffice — this question is largely already answered by reputation and years of public scrutiny. For something you found via a search result or a forum recommendation, it demands a few minutes of actual checking.
Look for an official project page: a named organisation, a foundation, a named development team, or at minimum a public source-code repository on a platform like GitHub or GitLab. Anonymous software with no named maintainer and no visible history is a meaningful warning sign. It may be harmless; it may not. The point is that you cannot tell, and that asymmetry matters before installation.
Check when the project last had activity. A repository where the most recent commit is several years old is not automatically dangerous — some tools are simply finished — but if it is security-adjacent software (a password manager, a VPN client, a firewall tool), recent maintenance is not optional. Unpatched vulnerabilities accumulate quietly.
Section 02The licence, the permissions, and the download itself
Once you know who made it, look at what the software is licensed under. Open-source licences — the GPL, the Apache Licence, the MIT Licence — are legal documents published by real organisations. The Free Software Foundation stewards the GPL family; the Apache Software Foundation publishes the Apache Licence; the Open Source Initiative maintains the canonical list of licences that qualify as open source. If a program claims to be "free" but carries no named licence, or uses a custom licence you have never seen, slow down and read it.
The licence matters for more than ideology. A programme distributed under a recognised open-source licence has its terms publicly reviewed and legally defined. You know, in principle, what the developer can and cannot require of you. A vague proprietary licence — especially one claiming the right to collect data, send it to third parties, or modify the software on your machine without notice — is worth reading carefully before you click anything. This is explanation rather than legal advice; if the terms matter to you professionally, get a lawyer.
Next, look at what the program asks for at install time and at runtime. On a desktop, this mostly means: does the installer want administrator or root privileges, and if so, why? A media player that insists on a system-level driver is more suspicious than one that runs fine as a normal user. On mobile, the permission model is more granular and the stakes are higher — a torch app requesting access to your contacts is the canonical absurd example, but subtler overreach is common. Pay attention to what access is described as optional versus required, and decline anything that isn't explained.
You know, in principle, what the developer can and cannot require of you.
Where you download from is as important as what you download. The official project page is always the right starting point. Avoid mirror sites you cannot verify, and be sceptical of any site offering a "bundled" installer that packages the program you want alongside other software you did not ask for. Bundled extras and how they get there is a well-established distribution tactic that ranges from mildly annoying to genuinely harmful. Check the file you receive against any hash or checksum the project publishes — most serious projects list SHA-256 hashes alongside their releases, and your operating system or a free utility can verify them in seconds.
Before you install · step through it
Nothing is stored or sent.
0 of 6 checked

Key facts · the words used here
- open-source licence
- a legal licence granting rights to use, inspect, modify and distribute software
- SHA-256 hash
- a fingerprint value used to verify a downloaded file has not been tampered with
- sandboxing
- running a program in an isolated environment to limit what it can access
- changelog
- a published record of what changed between software versions
- administrator/root privileges
- elevated system access that lets a program alter core OS files
Section 03Five minutes of independent checks
With the basics done, spend the remaining time on a short sequence of independent checks. None of these individually is definitive; together they give you a picture.
Search the program's name alongside the words "privacy" and "security". Not to find enthusiastic reviews, but to find complaints, incident reports, and documented misbehaviour. A tool with a history of phoning home, bundling adware, or being distributed with malware is usually documented somewhere. If the search returns nothing but promotional content, that is mildly reassuring; if it returns forum threads full of people asking why their antivirus flagged the installer, pay attention.
Check how the program updates itself. Software that updates automatically, silently, and without any way to inspect what changed is asking for a degree of trust that most tools have not earned. Good projects publish changelogs. They explain what changed and, for security releases, why. An update mechanism that bypasses the operating system's normal package management — especially one that runs with elevated privileges — deserves scrutiny. Keeping software current is genuinely important for security, but the update mechanism itself is an attack surface, and a well-designed one is a sign of a project that takes this seriously.
Look at the installer behaviour before you confirm it. On Windows, many installers offer a "custom" path during setup that reveals what the default path silently includes. Always choose custom if the option exists, read each screen, and uncheck anything pre-selected that you did not ask for. On macOS and Linux, package managers from the official repositories handle most of this for you — another reason to prefer them over standalone downloaded installers when the option exists.
Check reviews that are not on the developer's own site. App stores, regardless of platform, carry user reviews that sometimes surface real problems: battery drain, unexpected network activity, crashes on particular hardware. These are not always reliable — reviews can be gamed — but a consistent pattern of complaints about the same behaviour is signal worth weighing.
Give the program a trial run with limited privileges if you can. On most operating systems you can create a standard user account without administrator rights and run unfamiliar software under it. This limits what the program can do to your system even if its intentions turn out to be bad. Sandboxing tools, virtual machines, and containerised environments offer stronger isolation if you need it for higher-risk cases. For most everyday tools this is unnecessary caution; for something unusual that you found in an unverified place, it is sensible.
Section 04What the checks cannot tell you
No five-minute process makes risk disappear. Open-source code is publicly readable, but being able to read the source is not the same as anyone having read it: a project with a small or inactive community may carry vulnerabilities that nobody has looked for. Proprietary software from a large, reputable company can misbehave in ways that only emerge later. What these checks do is shift the odds — they filter out the most obvious problems and give you a rational basis for a decision, rather than pure hope.
The honest version of this checklist is not "run these steps and be safe." It is: gather enough information to make a considered choice, not an accidental one. A named maintainer, a recognised licence, an official download source, a clean search history, and sensible installer behaviour are each individually weak signals. Together they amount to something. A program that fails several of these checks simultaneously is not making a good case for itself.
One last thing: the best version of this process is one you do not have to run at all, because the software comes from a repository your operating system or distribution already vets. When that option exists, use it. The checklist is for the cases where it does not.
Free Software Foundation
Referenced in this piece
US nonprofit that stewards the GPL family of licences
Apache Software Foundation
Referenced in this piece
nonprofit that publishes the Apache Licence and hosts many open-source projects
Open Source Initiative
Referenced in this piece
nonprofit that maintains the canonical approved list of open-source licences
GitHub / GitLab
Referenced in this piece
code-hosting platforms where many open-source projects publish their repositories publicly
Programs and organisations are named as examples, not recommendations. Where we link, we link the official project page. The desk hosts no files and ranks no vendors.
