How to Prove Software IP Ownership: Cryptographic Seal for Source Code (2026)

In September 2024, a Zurich-based startup engaged a freelance developer to build a recommendation engine for their B2B SaaS platform. The developer delivered the algorithm in December and invoiced CHF 42,000. Two months later, the startup's newly hired CTO claimed the algorithm was derived from internal research predating the contract. The startup's legal team demanded proof of independent creation. The contractor had a git repository. The startup's lawyers had one question: who can verify the commit dates are genuine?

Why Git History Is Weak Evidence in Court

Git is a collaboration tool, not a legal record-keeping system. History is mutable by design: git commit --amend alters a commit's timestamp, git push --force rewrites an entire branch, and a bad actor can clone a public repo, add backdated commits, and publish the fork as the original.

Even without deliberate fraud, git timestamps are challengeable. A misconfigured system clock or a CI/CD pipeline re-committing built artefacts produces timestamps courts treat as circumstantial. In a dispute over who wrote a proprietary algorithm first, git history is a starting point, not a conclusion.

What Qualified Electronic Timestamps Add

Swiss Trust Layer computes a SHA-256 hash of your source file or repository ZIP. Alter a single character and the hash changes completely. It then submits that hash to Swisscom Trust Services, a Qualified Trust Service Provider (QTSP) accredited under EU and Swiss law. Swisscom issues a timestamp compliant with RFC 3161, binding your hash to a precise UTC time with a cryptographic signature that neither party can alter.

The result is a PAdES-compliant certificate anyone can verify at swisstrustlayer.com/validate, no contact with you required. Under eIDAS Art. 41, the timestamp carries a legal presumption of accuracy across all 27 EU member states. ZertES Art. 2 provides the same presumption under Swiss law. That is a fundamentally different evidentiary standing than a git log.

What Would Have Been Different

If the Zurich contractor had sealed the initial prototype ZIP at engagement start and again on delivery, the dispute would have resolved in days. A qualified electronic timestamp from Swisscom Trust Services, compliant with RFC 3161, would have established that the algorithm existed in its delivered form before the startup's claimed development date. No internal git history from either party could contradict a QTSP-issued timestamp carrying the eIDAS Art. 41 legal presumption. The startup's lawyers would have had nothing to argue.

Three Critical Scenarios Where Developers Need This

Contractor dispute: who wrote the algorithm first?

A freelance developer delivers a machine-learning model. Months later, the client asserts the algorithm was developed in-house before the contract began. The client's internal repo can be fabricated retroactively. A qualified seal on the contractor's initial prototype, timestamped before the client's claimed date, provides legally presumed prior art that cannot be dismissed as a clock error or a rewritten commit.

Investor due diligence: proving IP chain of title

VC and M&A teams now routinely require software IP provenance. A cryptographic seal on the codebase at each milestone (prototype, Series A, Series B) creates an auditable chain of title that satisfies legal teams without relying on git history alone.

Open-source licensing: establishing prior art before a fork

If a commercial entity forks your library, strips attribution, and relicenses it, your strongest defence is the original publication date. A qualified timestamp on the first public release gives you a legally strong prior art record that the fork cannot predate.

Step-by-Step: Sealing a Source Code File or Repository ZIP

Step 1: Prepare your artefact. For a single file, use the source file directly. For a full repository, export a ZIP archive: git archive --format=zip HEAD > repo-v1.0.zip. Any file up to 500 MB is supported.

Step 2: Upload at swisstrustlayer.com. The SHA-256 hash is computed client-side. Your source code never leaves your browser. Only the hash is transmitted to Swiss Trust Layer's servers.

Step 3: Qualified timestamp is issued. Swisscom Trust Services anchors your hash to an RFC 3161-compliant qualified electronic timestamp. This is the legally binding event.

Step 4: Download your certificate. The PAdES-compliant certificate contains your file hash, timestamp, issuer chain, and verified identity. Store it alongside the original file or commit it to a separate evidence repository.

Step 5: Verify independently. Share the verification link at /validate with any third party (investor, lawyer, open-source foundation) who needs to confirm your prior art claim without taking your word for it.

Legal Weight: The Regulatory Basis

Software is protected as a literary work under Berne Convention Art. 5. Copyright exists from the moment of creation across 181 member states, no registration required. But the Convention protects the right; it does not prove the date. That is what a qualified timestamp does.

eIDAS Art. 41 grants a legal presumption of accuracy to the date and time a qualified electronic timestamp indicates, operative in every EU court, rebuttal burden on the challenger. ZertES Art. 2 is the Swiss-law equivalent. These are statutory presumptions, not guidelines.

Frequently Asked Questions

Is a git commit timestamp legally binding proof of authorship?
No. Git timestamps are set by the committer's local system clock and can be altered by anyone with repository access using standard git commands. They are treated as circumstantial evidence, not authoritative proof. A qualified electronic timestamp from an accredited QTSP under eIDAS Art. 41 carries a statutory presumption of accuracy that git history does not.

Can I seal an entire repository, not just a single file?
Yes. Export your repository as a ZIP archive using git archive --format=zip HEAD > repo.zip, then seal the ZIP file. Swiss Trust Layer supports any file format up to 500 MB, so a complete codebase, including documentation, tests, and build scripts, can be sealed in a single operation. The SHA-256 hash covers the exact binary contents of the entire archive.

Does sealing source code expose my proprietary code to Swiss Trust Layer?
No. The SHA-256 hash is computed in your browser before anything is transmitted. Swiss Trust Layer receives only the hash, a 64-character hexadecimal string, never the source code itself. Your proprietary algorithms and implementation details remain entirely private.

What if I seal a file and then make commits on top of it?
Each seal is a snapshot at a specific moment. Seal again when you release a new version. Volume plans are available for teams with frequent release cycles. Against the Swiss Arbitration Association's figure of CHF 150,000 to 400,000 for the average IP dispute, that arithmetic is not complicated. A qualified cryptographic seal, anchored to an independent, accredited timestamp authority and admissible under eIDAS, ZertES, and the Berne Convention, is the only evidence that courts treat as presumptively accurate. Seal your codebase before the dispute arises. Learn more about the legal framework at /eidas and /zertes.