Proving Source Code Authorship for Freelancers and IT Service Firms

In day-to-day engineering, a Git repository is usually enough for collaboration. In a dispute, however, Git history alone can be challenged: history can be rewritten, replayed, or reconstructed, and may not by itself prove that a specific code state existed at a specific date. (Git)

The goal is not to claim "absolute proof." It is to build a solid evidence file with a repeatable method: traceability (repo + releases) + integrity (hash) + timestamping (date evidence) + retention.

Proving source code authorship means showing that you held a specific version at a specific time and that the version has not changed since.

This guide provides a practical workflow you can apply immediately in freelance or IT service contexts: repo, commits, releases -> archive -> hash -> timestamp -> evidence pack.

Plain-English definition

Proving source code authorship means being able to show:

1. Who produced (or at least held) a specific version.
2. When that version already existed.
3. That the content presented today matches the historical version.

Under French copyright rules, authors generally enjoy rights by the mere fact of creation, independently from service contracts (subject to legal exceptions). (Legifrance)

Software made by employees in the course of duties follows a specific regime: economic rights can be vested in the employer, unless otherwise agreed. (Legifrance)

How it works

You freeze a verifiable snapshot of code, then anchor it in time.

• Repo + commits: development traceability.
• Tag/release: stable named milestone.
• Archive + hash: frozen content and integrity fingerprint.
• Timestamping: time evidence.
• Retention: long-term ability to verify.

1. 1
   Stabilize and name a milestone

   Pick a clear state (end of sprint, delivery) and create a tag/release such as v1.3.0-delivery-2026-02-22. Sign the tag when possible.
2. 2
   Sign commits and tags

   Enable GPG/SSH/S/MIME signatures. GitHub and GitLab Verified indicators improve attribution and authenticity perception.
3. 3
   Export a delivery archive

   Create a zip/tar from the tagged version and include a MANIFEST with version, commit ID, date, scope, and hash info.
4. 4
   Compute and store hash values

   Compute SHA-256 for the archive. This becomes your integrity reference: change one byte, hash changes.
5. 5
   Timestamp the archive or its hash

   Use a verifiable mechanism such as OpenTimestamps and keep the proof file (.ots).
6. 6
   Build a complete evidence pack

   Keep archive, hash, timestamp proof, release exports, and contextual documents (contract, PO, emails, meeting notes). Use redundant storage.

Command examples

Sign and verify a Git tag: (GitHub Docs)

git tag -s v1.3.0 -m "Release v1.3.0"
git tag -v v1.3.0

Enable automatic commit signing: (GitHub Docs)

git config --global commit.gpgsign true

Timestamp an archive with ots: (OpenTimestamps Client)

# Creates livraison-v1.3.0.zip.ots
ots stamp livraison-v1.3.0.zip

# Verifies timestamp proof (after blockchain confirmation)
ots verify livraison-v1.3.0.zip.ots

Where LegalStamp fits

LegalStamp fits at the freezing stage: you submit an archive (zip/tar, export, delivery PDF), it computes the hash, applies verifiable timestamping, and returns a receipt you can retain and verify later.

What it proves, and what it does not

What it proves well

• Priority: the archive fingerprint existed at a given date (or before a specific Bitcoin block for OpenTimestamps). (OpenTimestamps)
• Integrity: if the archive changes, the hash changes.
• Attribution: signed commits/tags and Verified indicators make it harder to challenge who authored the code. (GitHub Docs)

What it does not fully prove on its own

• Legal authorship/ownership in isolation: contract and legal context still matter. (Legifrance)
• Absence of collaboration by others: governance evidence (tickets, reviews, merge requests) is still needed.
• eIDAS qualified presumptions on date/time unless you use qualified timestamping under eIDAS trust-service rules. (ANSSI)

Best-practice checklist

• [ ] Work in a managed repo with issues and merge requests.
• [ ] Enable commit/tag signing and check Verified status. (GitHub Docs)
• [ ] Create named releases at each milestone (version + date + scope).
• [ ] Export a delivery archive from tag/release.
• [ ] Include a MANIFEST.txt (version, commit, date, file list, hash).
• [ ] Compute SHA-256 hash for every key archive.
• [ ] Timestamp and preserve proof (.ots or equivalent receipt). (OpenTimestamps Client)
• [ ] Keep a complete evidence pack (contract/PO, emails, notes, release notes, payment records).
• [ ] Store redundantly (cloud + vault + encrypted offline media).
• [ ] Define a dispute-response procedure in advance.

FAQ

1) Is a Git repo enough to prove I wrote the code?

Helpful, but not always sufficient under challenge. For higher-stakes cases, add signed release/tag, archive, hash, and timestamping. (Git)

2) Why sign commits and tags?

Signing cryptographically links commit/tag to your key (GPG/SSH/S/MIME). Verified indicators improve attribution trust. (GitHub Docs)

3) Why create zip/tar if the repo already exists?

A frozen deliverable is easier to explain and compare in legal or audit contexts.

4) Does timestamping reveal source code?

Not when timestamping the hash. You expose a fingerprint, not source content. (OpenTimestamps Client)

5) How long does OpenTimestamps confirmation take?

Full confirmation can take time depending on blockchain anchoring cadence, often a few hours. (OpenTimestamps Client)

6) In IT service firms, who owns software rights?

For employee-created software within employment duties, economic rights may vest in the employer unless contractual terms say otherwise. (Legifrance)

7) In freelancing, does the client automatically own everything?

Not automatically by default principle. Assignment/license clauses are key. (Legifrance)

8) Does eIDAS-qualified timestamping make a difference?

Yes. Qualified eIDAS timestamping carries specific presumptions on date/time accuracy and data integrity. (ANSSI)

Conclusion

A Git repo on its own rarely holds up in a serious dispute. What does hold up is the combination: Git for traceability, signed tags for attribution, a frozen release archive for a specific state, hash + timestamp for dating and integrity, and long-term retention so you can actually demonstrate it later.

LegalStamp handles the critical step — freeze, timestamp, archive, verify — without adding friction to daily delivery.

Disclaimer: This article is informational only and not legal advice. For concrete ownership, assignment, employment, subcontracting, or litigation matters, seek legal counsel.