Zenodo or Software Heritage vs a timestamp: dating your code or research files

Zenodo, Software Heritage and a timestamp at a glance

What Zenodo records

Zenodo’s documentation says a record consists of metadata, files and a persistent identifier, and that once published "Metadata CAN be modified" while "Files and the persistent identifier CANNOT be modified" (Zenodo: About records). A new version is a separate record with its own metadata and files. The publication date is a field you fill in. By default it is the date the draft was created, and Zenodo asks you to use the date of first publication if the work was published elsewhere. It also keeps track of the date a record was uploaded to the repository (Zenodo: Publication date).

So the repository’s own upload date is the date to look at for dating, and the publication date is a descriptive field you set.

What Software Heritage records

Software Heritage archives source-code repositories. Its public API describes "visits": each visit of an origin has a date (in UTC) and, if it was complete, a snapshot of what was found (swh-web API). You can ask it to archive a public repository through its "Save Code Now" request, and archived objects get SoftWare Hash identifiers computed from their content. That gives a public record that a snapshot of a repository existed by the date of the visit.

Where an archive is the better choice

• You want the work public and citable. A DOI or an archive entry can be cited in papers and documentation.
• You want long-term preservation. These are institutions set up to keep copies.
• You want others to retrieve the work. A timestamp keeps no copy.

Where a timestamp is the better choice

• The code is private or pre-release. You can date it without publishing anything.
• You are about to open-source it. Date the private state first, then publish. See timestamp your code before you open-source it.
• You want to date files that aren’t a repository. Design documents, test data, build artefacts and notes can go in the same TimeBind, up to 10 files.
• Publication could affect your options. Public disclosure can affect later patent or trade secret positions. Get advice from an IP adviser before you publish. See provisional patent vs a timestamp and defensive publication vs a timestamp.

Using both

1. Before you publish, make a TimeBind of the release archive, the changelog and the key design documents.
2. Publish through your normal channel and, if you want a citable record, deposit the release in an archive.
3. Keep the certificate with the exact files. A changed file won’t match.

For Git history specifically, see are Git commit dates proof of when code existed?.

What none of them shows

• Who wrote the code, or that it is original.
• That the code is free of third-party material or licence problems.
• How a court, a client or an employer will treat the record.

When a timestamp isn’t the right tool

• You want a public, citable record. Use an archive.
• You need to sign releases for supply-chain trust. See TimeBinder vs Sigstore.
• You need advice on ownership or licences. Talk to a lawyer.

What a dated record adds to a deposit

A repository deposit keeps a public history of your code. A TimeBind adds a dated record of an exact archive at a moment you choose, adding a layer of protection if a date or version is disputed. It does not show who wrote the code.

General information, not legal advice. A TimeBind shows that this exact file existed no later than the recorded time and still matches its fingerprint. It does not show authorship, ownership, copyright status or how any court, tribunal, client or insurer will treat it.