Is Signal Open Source? Licensing and Transparency, Explained

Published: October 7, 2026 Updated: October 8, 2026

Yes, Signal's apps are open source, published under the AGPLv3 license, and the server code is published too. Anyone can read the code, check the privacy claims against it, and even build the app from source. But open source is a transparency property, not a magic guarantee: it does not prove the servers run the published code, and it does not make software bug-free. This page covers what is open, what that means, and what it honestly does not promise.

What "open source" means here

Signal's client apps, Android, iOS, and Desktop, are published under the AGPLv3 license. In plain language: the complete source code is public, anyone may read it, and anyone may modify and redistribute it as long as they keep the same freedoms for the next person. This is a strong copyleft license, deliberately chosen: it means nobody can take Signal's code, close it up, and ship a proprietary version without sharing their changes.

Why does the license matter for privacy? Because Signal's privacy claims, end-to-end encryption, minimal metadata, sealed sender, are claims about what the software does. With closed-source software you take those claims on trust. With open-source software you, or any security researcher on earth, can read the code and verify the claims. Trust is replaced by checkability, at least in principle. The encryption guide describes what the code does; the open license is what lets anyone confirm it.

The server code is published too

Many open source apps open only the client and keep the server closed, which leaves a gap: you can verify the app, but not what the service does with your data. Signal publishes its server code as well, so researchers can inspect how messages are relayed and accounts are managed on the service side. The honest limit stays the same: published code proves what the software can do, not what the running servers are doing. Our guide to Signals published server code walks through exactly what is public and where verification stops.

Reproducible builds for Android

There is a second gap open source has to bridge: the app on your phone is a compiled binary, not source code. How do you know the APK you installed was actually built from the published source, and not from modified code with something extra inside? The answer is reproducible builds, a build process designed so that compiling the published source produces a byte-identical file to the one distributed. Anyone can then rebuild from source, compare fingerprints, and confirm the distributed app matches the public code.

Signal has worked toward reproducible builds for its Android app, and this is a verifiable claim rather than a slogan: the process is documented so independent parties can perform the comparison themselves. A note of honesty about our own page here: the official APK we link to throughout this guide is the website build from Signal's own download page, and verifying any build yourself requires technical comfort with build tooling. The point is that the possibility of verification exists, which is more than closed-source apps offer.

Forks as proof the license is real

One of the clearest signs an open-source license is genuine is that independent forks exist and thrive. Molly is the best-known example: an independent, fully open-source fork of Signal for Android, built by people with no connection to the Signal Foundation, adding features like encrypted local backups and multiple profiles. It exists because the AGPLv3 license permits it, and it is clearly labeled as independent, never presented as official Signal.

Forks do two useful things for everyone else. First, they prove the code is really open: you cannot fork what you cannot see. Second, they create a second set of eyes on the codebase, since fork maintainers track upstream changes closely. The Signal vs Molly comparison covers what the fork adds and who it suits.

What it guarantees, and doesn't

Open source guarantees this	It does NOT guarantee this
Anyone can read the code and check the privacy claims	That anyone actually has read every line recently
Backdoors are hard to hide, many eyes, public history	That the code is bug-free; bugs and open code coexist
The license blocks proprietary capture of the code	What code is running on Signal's servers right now
Forks like Molly can exist and be inspected too	That your device or your contacts are trustworthy
Security researchers can audit continuously, not just once	A passing grade from any single audit, forever

The last row deserves emphasis because "has it been audited?" is the question everyone asks. Audits are snapshots: a team reviews the code at one point in time and reports what it found. They are valuable, and Signal's protocol and code have received serious public scrutiny over the years. But an audit from last year says nothing about code written last week. Continuous openness, the code always being readable, is the durable property. A single audit is a photograph; open source is leaving the curtains open.

Why AGPLv3 specifically

Not all open-source licenses are the same, and Signal's choice of AGPLv3 is deliberate. Licenses fall on a spectrum. Permissive licenses (like MIT) let anyone take the code, modify it, and ship a closed proprietary product, the openness is a gift with no strings. Copyleft licenses (like the GPL family) attach a condition: if you distribute a modified version, you must share your changes under the same open terms. The AGPLv3 goes one step further than the regular GPL: it closes the "run it on a server" loophole, so even offering the software as a network service triggers the share-your-changes requirement.

For a messaging app, that choice is doing real work. It means a company cannot take Signal's code, build a closed competitor on it, and keep its modifications secret. Improvements flow back to the commons or they cannot be distributed at all. It is also what makes forks like Molly possible and legitimate: the license explicitly permits independent versions, which is why Molly can exist as a separate project rather than a knock-off.

The trade-off is flexibility: some developers avoid strong copyleft because it restricts how they can reuse the code. Signal accepted that cost in exchange for a guarantee, that its code, and everything built on it, stays inspectable forever. When you read "AGPLv3," read it as a structural commitment to transparency, not just a legal label.

How you can check things yourself

You do not need to be a cryptographer to benefit from open source. Practical steps, in increasing order of effort:

• Read the plain-language explanations of what the code does (like the guides on this site). Notice that they link to inspectable code rather than asking for trust.
• Follow the public development. Issues, fixes, and releases happen in the open, and the tone of that work tells you a lot.
• If you are technical, build the Android app from the published source and compare it against the distributed APK. That is exactly what reproducible builds enable.

The bottom line is unglamorous and that is the point. Open source does not make Signal magically trustworthy. It makes Signal checkable, by you, by researchers, by competitors, by anyone with the skill and the time. In a field full of privacy claims you must take on faith, checkability is the rarest property of all. For what that transparency protects in practice, the honest privacy assessment continues from here.

Frequently asked questions

Keep reading

• the independent open-source fork: Signal vs Molly compared
• what the code actually does: encryption beginner's guide
• the honest privacy assessment: is Signal really private
• verifying the APK you install: APK safety checks
• Molly's source code, publicly checkable: the fork's open code