How do you prove your source code existed before a specific date? Git history feels like proof, but it isn't independent. Commit dates come from the developer's own machine and can be set to anything, and history can be rewritten before it's pushed. The strongest approach is to freeze the code at a known point (a tagged release, an archive or a bundle), calculate its SHA-256 fingerprint, and record that fingerprint somewhere nobody in the dispute controls. This guide covers why commit dates are weak on their own, what signed commits and hosted releases add, and a simple routine that gives your code a date that holds up.
Disclosure: I'm Inna Hall, an Australian lawyer and co-founder of TimeBinder, which is mentioned below. This is general information, not legal advice. Copyright, employment and contract law differ between countries, so get advice on your own situation.
When the date of your code matters
Most developers never need to prove when they wrote something. The ones who do usually find out at a bad moment:
- You're starting a job or a contract. Your side project or your own library existed before you signed, and you want to keep it. Many employment and contractor agreements give the employer or client rights in code written during the engagement, so "it was mine before I started" needs to be shown, not just said.
- A co-founder leaves. Someone says the core of the product was written before the company existed, or after they left, or by them alone.
- A contractor delivers. You want a clear record of exactly what was handed over and when, especially if the invoice is disputed.
- Someone ships something that looks like yours. A former client, a competitor or a fork without attribution. The first question is usually which version came first.
- Due diligence. An investor or buyer asks you to show the history of your codebase and who wrote it.
Code is protected by copyright as a literary work in most countries. In Australia that protection is automatic and there is no register (see the Australian Copyright Council's software fact sheet). So when a dispute comes up, the argument tends to be about evidence: what existed, when, and who had access to it.
Why Git commit dates are not proof on their own
Every Git commit stores two dates, the author date and the committer date. Both come from the machine that made the commit, and both can be overridden. The git commit documentation lists a --date option that sets the author date, and the environment variables GIT_AUTHOR_DATE and GIT_COMMITTER_DATE set both. Change your computer's clock and every new commit gets that date too.
History can also be rewritten. Rebasing, amending and tools that rewrite a whole repository create new commits with whatever dates the person chooses. Until code is pushed somewhere others can see, nobody else can tell.
None of this means Git history is worthless. A long, consistent history pushed to a shared remote over months is persuasive, and most people never tamper with it. The problem is that the other side can say "you could have made that up", and a log that came from your own laptop can't really answer that. You want at least one record that comes from outside your machine.
What signed commits, tags and releases add
Signed commits and tags (git commit -S, git tag -s) attach a cryptographic signature using your GPG or SSH key. As the Git book's chapter on signing your work explains, others can then check the commit or tag really came from the holder of that key and hasn't been altered. That's good evidence about who. It isn't evidence about when, because the date inside a signed commit is still the one your machine supplied.
Pushes to a hosted remote such as GitHub, GitLab or Bitbucket leave records on someone else's servers. They help, but you don't control those records, retention varies, private repositories can't easily be shown to a third party, and accounts and repositories can be deleted.
Published releases with downloadable archives, package registry uploads and public announcements are strong evidence for code you're happy to make public. Most of the code people argue about is private, though.
The gap is an independent date for private code. That's where a timestamp fits.
Freeze the code into one file
A timestamp records a fingerprint of a file, so first turn the code into a file that won't change. Three common options:
-
A source archive of a tag or commit.
git archive --format=zip -o myapp-v1.4.0.zip v1.4.0produces a zip of exactly the files at that tag (see the git archive docs). It contains the code but not the history. -
A Git bundle.
git bundle create myapp-2026-10-26.bundle --allpacks the whole repository, history included, into one file that can be cloned from later (see the git bundle docs). This is the best choice when the history itself matters, for example to show which commits existed by a certain date. -
A commit list. A text file with the output of
git log --format="%H %an %ad %s". Each Git commit ID depends on its contents and on its parent commits, so the latest commit ID effectively fingerprints the history behind it. Timestamping this small file anchors the history without including any code. Keep the repository itself safe as well, because you'll need it to show what those IDs refer to.
Whichever you choose, keep the exact file you fingerprinted. Don't rebuild it later and expect the same result. Archives and bundles made from the same code on another day, or with another Git version, can differ by a few bytes, and a different byte means a different fingerprint.
Fingerprint it and anchor the fingerprint
A SHA-256 hash is a 64-character fingerprint of a file. The same file always gives the same hash, and changing a single byte gives a completely different one. You can calculate it with sha256sum myapp-v1.4.0.zip on Linux, shasum -a 256 on macOS, or in your browser with our free SHA-256 file hash checker.
A hash on its own has no date. To give it one, record it somewhere independent. With TimeBinder your browser calculates the SHA-256 fingerprint and it's anchored to the Bitcoin blockchain, and you get a Proof of Time Certificate with the transaction details. The code is never uploaded, which matters for private and client work. One TimeBind holds up to 10 files, so a release archive, a bundle, the commit list and the contract or statement of work can go in together. You can also put the tag name or commit ID in the Reference field.
There are other ways to anchor a hash, including open-source tools that use the same Bitcoin approach. We compare them honestly in TimeBinder vs OpenTimestamps.
What a timestamp proves, and what it doesn't
A blockchain timestamp shows that a particular file existed no later than a certain time, and that it hasn't changed since. It doesn't prove who wrote the code, that it's original, or who owns it. Ownership depends on your employment terms, contracts and the law where you are. If you used open-source components, their licences still apply. A timestamp also can't show the code existed before the moment you made it, so it only helps if you make it early.
What it does is take one argument off the table: the argument about when your version existed. Combined with signed commits (who), your contracts (what you were allowed to do) and your remote history (how the work progressed), it makes a much harder record to attack.
An illustrative example (not a real case): a freelance developer has spent a year on a scheduling library in her spare time. Before starting a six-month contract, she creates a Git bundle of the repository and a short commit list, TimeBinds both, and attaches the certificate to an email confirming the library is excluded from the contract. A year later the client says the library was built during the engagement. She can show that the bundle, with its full history, existed before the contract began and is unchanged. Whether the contract gave the client any rights is still a legal question, but the timing isn't.
A routine for developers and small teams
Sign your commits and tags so authorship is easier to show later.
At each release or milestone, make a source archive of the tag and a commit list, and TimeBind them together.
Before code changes hands, TimeBind a bundle: before you start a contract or a job, when a contractor delivers, and before you send code for due diligence.
Store the exact files with the certificate in one folder per release, and back it up.
Write down what each file is in the Reference or Details field: project, tag, commit ID and the reason, such as "pre-existing work before contract with Client X".
For routine milestones a Pooled TimeBind (1 Token) is usually enough. For the moments most likely to be argued about, such as pre-contract code or a final handover, an ASAP TimeBind (3 Tokens) gets its own Bitcoin transaction that anyone can check without relying on TimeBinder. The Free plan gives you 1 Token a month with no credit card required. Details are on the ASAP vs Pooled explainer, and our page on source code timestamping covers what developers usually TimeBind.
AI can rewrite files. It can't rewrite time. Before your next release or contract, give your code a date nobody can quietly change.
This article is general information, not legal advice. Sources were checked on 26 October 2026. More free tools are on our free tools page.
Frequently Asked Questions
- Can Git commit dates be faked?
Yes. Both the author date and the committer date come from the machine making the commit, and Git lets you set them directly. History can also be rewritten before it's pushed. Treat commit dates as supporting evidence, not as independent proof.
- Does a signed commit prove when the code was written?
No. A signature shows the commit came from the holder of a particular key and hasn't been changed, but the date inside it is still self-reported. Pair signatures with an independent timestamp if the date matters.
- Do I have to upload my code to timestamp it?
No. Only a SHA-256 fingerprint is recorded, and a fingerprint can't be turned back into code. The archive or bundle stays on your machine.
- Should I timestamp every commit?
Usually not. Releases, milestones and the moments code changes hands are enough for most people. A commit list captures the history up to that point anyway.
Originally published at https://timebinder.io/blog/prove-source-code-existed-before-a-date/ . I'm Inna Hall and I work on TimeBinder.
Top comments (0)