Open-Source

Open-source software is software whose source code is published under a licence that allows anyone to read, audit, modify and redistribute it. In the VPN market, the term usually refers to a provider's client apps (Windows, macOS, Linux, Android, iOS) and the tunnelling protocols they use. Closed-source, or proprietary, software keeps the code private, so users have to trust the vendor's description of what it does.

How it works

The provider puts the code in a public repository, typically on GitHub or GitLab, together with a licence such as GPL, MIT or Apache 2.0. Security researchers, competitors and ordinary users can then read it, report bugs, propose fixes or build the app themselves.

For VPNs, open source applies on two levels:

• Protocols. OpenVPN and WireGuard are open source and widely reviewed. Variants such as AmneziaWG (a WireGuard fork with DPI obfuscation) are also public. Proprietary protocols, like some vendors' in-house designs, can only be reviewed if the vendor allows it.
• Client apps. Some providers publish the full code of their apps. Others publish only parts, or nothing at all, even if they use an open protocol underneath.

Server software and the backend that manages accounts and payments are almost never fully public, even at providers with open-source apps.

Why it matters

Open code lets people check claims that would otherwise rest on trust: whether the app leaks DNS requests, how the kill switch behaves, which ciphers are used (for example AES-256 or ChaCha20), and whether the app sends analytics or identifiers home. Problems found in public code tend to be reported and fixed in the open, and the commit history shows when and how changes were made.

It also reduces lock-in. If the provider shuts down or changes direction, the code can be forked, and open protocols work with third-party clients and self-hosted servers.

Limits and risks

Open source is a signal, not a guarantee.

• Code is not the server. Public app code says nothing about what happens on the provider's servers. Whether traffic or connection logs are kept depends on server configuration and the no-logs policy, which need independent audits to verify.
• Published code may not equal the shipped app. Unless the provider offers reproducible builds, you cannot be sure the app in the store was built from the public source.
• Public does not mean reviewed. Many repositories get little real scrutiny. A professional security audit is still worth more than code that nobody has read.
• Partial openness. "Open source" in marketing sometimes means only one component, such as a library or a browser extension, is public.
• Bugs are visible to attackers too. This is usually outweighed by faster fixes, but unpatched open-source apps are not automatically safer.

Open source vs audited vs transparent

The strongest position combines open-source apps, regular independent audits of both apps and servers, and a clear transparency report.

What to check when comparing tools

• Which parts are open: all client apps, only some platforms, or just the protocol.
• Where the repository lives and whether it is actively maintained, with recent commits and responses to issues.
• The licence type, and whether it allows forking and redistribution.
• Whether builds are reproducible or signed in a verifiable way.
• Dates and scope of independent security audits, and whether reports are published in full.
• Which protocols are offered, and whether proprietary ones have been publicly reviewed.
• Whether a bug bounty program exists for reporting vulnerabilities.

Related features to look at alongside open source include obfuscated servers, which often rely on open protocols to bypass censorship.