No. The GNU FAQ says complete corresponding source means the source the binaries were made from, and that does not imply your tools must reproduce an exact hash of the shipped binary. But the source must correspond to the binary you distribute, not an older or newer version. Not legal advice.
Definition
The FAQ states that complete corresponding source means the source that the binaries were made from. It gives reasons an exact hash match may be nearly impossible: a system might put timestamps in binaries, or the program might have been built against a different, even unreleased, compiler version. So a matching hash is not the test.
It also says that if you distribute an extended version of a GPL program in binary form, it is not enough to supply source for the original. You must supply source that corresponds to the binary, from which users can rebuild the same binary.
What "corresponds" means in practice
| Practice | Meets the idea? |
|---|---|
| Publishing the tagged commit that built the shipped release | Yes |
| Publishing the latest main branch | No, unless it matches the shipped build |
| Publishing the upstream project's source when you made changes | No |
| Publishing source without your build scripts | Weak; GPLv2 refers to scripts that control compilation and installation |
| Publishing instructions that point to a version control checkout | Acceptable if the process is not burdensome, with instructions for the exact version |
On version control, the FAQ says anyone who can download your object code should be able to check out the source from your version control system, using a publicly available free software client, and that users should get clear instructions for the exact code they downloaded, not the latest development code.
Where source can live
The FAQ says that if you make object code available on a network server, you must provide the Corresponding Source on a network server as well. The source can sit on the same server or on another, with clear instructions, and it should be as easy to reach as the object code. You must keep it available for as long as you distribute the object code.
Release procedure that holds up
- Tag every release in version control at build time.
- Store the build scripts and configuration with the tag.
- Record compiler and toolchain versions in the release notes.
- Publish the tagged source and instructions next to the binary download.
- For mobile or firmware releases, link the source from the About screen or the device documentation.
- Keep the source up for as long as the binary is distributed, including older versions still downloadable.
Why reproducible builds still help
You are not required to match hashes. But if your builds are reproducible, you can show that the published source produced the binary, and that is also useful for supply chain assurance. It is a security benefit, not a GPL requirement.
Try it yourself
The SCA inventory demo shows a record of what went into a release. Click through it and consider how a component list tied to a version supports the habit of tagging and archiving each release.
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning record the components in each build. A free scan is available at gold.safeguard.sh/scan.
Quick check
Do I need bit for bit reproducible builds for the GPL?
No. The FAQ says an exact hash match is not implied, because of timestamps or toolchain differences.
Can I publish just the upstream source if I added features?
No. The FAQ says you must supply source corresponding to your binary.
How long must I keep the source available?
The FAQ says as long as you distribute the object code.
Sources
Last reviewed: 19 October 2026.
