An archive of your project or of a release, a Sealway proof, and months later you can establish that this exact version already existed on that date: before a delivery, a collaboration, a release. Sealway does not say who wrote the code, who owns it or whether it is original; it fixes a content and a date.
Built for
An independent developer builds a library. They send a first version to a client, then evolve it with the client for several months. A disagreement then arises about the origin of some functions: did they exist before the collaboration, or were they written for the client?
The claims contradict each other, and each side produces what it has: screenshots, a Git repository whose history shows dates, emails. Yet the dates in a Git history are written by the machine of whoever commits and can be rewritten; a hosted repository shows what the host displays, not an independent finding; an archive found on a disk carries whatever date the system gives it. None of that fixes, in a way a third party can verify, that a specific version existed on a specific date.
A Sealway proof created on the day the version existed answers that question, and that question only: this archive, with this exact content, existed at the latest on that date. Who its author is, who owns the rights, whether the code is original or borrows third-party code remain questions of law and contract, which the proof does not absorb.
Your repository’s history tells the work: who committed what, in what order, with which messages. It is a valuable chronology, but produced by you, on machines you control, and editable. The archive of a version freezes the exact content of a step: what the project contained at that moment, independently of the tool.
Sealway adds the layer both lack: a date fixed by a qualified third party and a fingerprint that makes it possible to verify, later, that the archive produced is the one from back then. The history remains useful to explain; the archive and its proof serve to establish.
No connector, nothing to install: the workflow works with any tool, repository or forge, since it starts from an archive.
Software is protected by copyright, without formality, if it is original. Three distinct questions arise in a dispute: did the code exist on that date, is it original, who owns the rights? Sealway only answers the first. The French provisions below implement EU rules that apply across the Union.
Works of the mind include “software, including preparatory design material”. In the European Union, computer programs are protected by copyright as literary works; protection applies to the expression in any form of the program, not to the ideas and principles underlying it.
The author enjoys the right by the mere fact of creation, and the work is deemed created, regardless of any disclosure, by the mere realisation, even unfinished, of the author’s conception. A prototype, a working branch, an isolated module already fall under copyright if they are original. No filing creates the right; you still have to be able to show what existed, and when.
A program is protected if it is original “in the sense that it is the author’s own intellectual creation”. The French Cour de cassation requires courts to look into how the choices made show the author’s own intellectual contribution and personal effort; providing “a particular solution” to a problem is not enough. Evidence of existence does not establish originality.
Neither the functionality of a program, nor the programming language, nor the format of data files used to exploit some of its functions are a form of expression of the program protected by copyright. What you date is code, not an idea or a function.
Under French law, the author is presumed, until proven otherwise, to be the person under whose name the work is disclosed. For software created by employees in the course of their duties or on the employer’s instructions, the economic rights vest in the employer, unless statutory provisions or contractual terms provide otherwise. An independent developer keeps their rights unless the contract assigns them. A date settles none of these questions.
Three needs stand apart: dating a version (the INPI’s e-Soleau, Sealway), archiving it for evidential purposes with a body (the Agence pour la protection des programmes) or placing it in escrow for a client (the INPI’s “entiercement”). The table below compares what each establishes. Sealway meets the first need, with a qualified timestamp verifiable without it; it is neither a deposit nor an escrow.
Cour de cassation · 1st civil chamber · 17 October 2012
Quashed · decision under appeal: cour d’appel d’Aix-en-Provence, 11 May 2011
A publisher sues a competitor for infringement of a case-management program for commissaires de justice. The court of appeal finds the software original on the ground that it provides “a particular solution” to that management. The Cour de cassation quashes the judgment.
By so ruling, without looking into how the choices made showed an intellectual contribution of their own and a personal effort of the person who had developed the software in dispute, which alone can give it the character of an original work protected as such by copyright, the court of appeal gave no legal basis to its decision.
What Sealway takes from it
Existing on a date and being protected are two different things. The Sealway proof fixes the first; originality is demonstrated through the design choices of the code, and that is another discussion. Producing a dated archive does not dispense with having it, but keeps it from stalling first on “which version existed when”.
The workflow is manual and takes a few minutes: generate the archive of a version, check it, create the proof, keep the archive. It works with any version control tool, or without one.
A version about to leave your hands or change in nature: sending to a client, contractual delivery, release, rewrite. Not every commit.
An export or archive of the version from your tool (a Git archive of a tag, for example), as ZIP or TAR. With or without the .git directory: if it is included, its history is part of the dated content, without its internal dates being certified for all that.
Open it: it does contain the complete sources, the release notes, no secret. This exact archive is what you will produce later; an archive regenerated afterwards will have another fingerprint.
From the app, import the archive and, if useful, the release notes or a README separately. Give the proof an explicit title, “lib-x v1.4.0”, and note the tag and the commit identifier in the description: reference points for you, editable, outside what is timestamped.
Keep the archive as it is, in storage of your own, with the evidence file: without a storage plan, Sealway keeps the original 7 days. The evidence file you keep remains verifiable indefinitely, but it only means something against the archive.
One proof per version that matters, in a collection named after the project: the chronology of versions reads in the collection, and each proof can be verified separately.
Up to 10 files and 250 MB per proof. An archive rarely exceeds that; a larger project is split into several archives, in one proof or in one collection.
There is no need to create a proof at every commit. It is more relevant to document the important steps: release, delivery, transfer to a third party, major change.
First archive of the project, before any sending. Proof “v0.1.0”.
The version presented and then delivered to the client. Proof created on the day of sending.
The version published or put into production. Proof “v1.0.0” with the release notes.
New architecture, new components: a proof that marks the change.
Each proof fixes a version and a date. Placed end to end in the project’s collection, they tell what existed before each step, without depending on your tool’s history.
Sealway proves that this archive, history included, existed on the date of the proof. The commit dates it contains therefore existed on that date; they do not become certified facts.
The host displays dates and authors; it is a trace held by a third party, useful, but subject to its rules, its retention and a history that can be force-pushed. It is not a qualified timestamp.
A signature establishes that the content comes from a given key and has not changed since the signing. It does not establish when the signature was applied other than by declaration.
They show that a build was run on a given content; they are operational traces, kept for a while, on infrastructure you or your host control.
A dated proof is useful whatever the regime, but it does not change it.
Under French law, the economic rights on software created by employees in the course of their duties or on the employer’s instructions vest in the employer, unless statutory provisions or contractual terms provide otherwise (art. L. 113-9). The employer has an interest in dating versions; the employee remains the author.
The provider keeps their rights unless the contract assigns them. Dating what existed before the assignment tells pre-existing code from code written for the client; the contract says what is assigned.
A client receiving a delivery also has an interest in dating what they received, and when: a proof of the delivered archive, at receipt, complements the acceptance report.
A free licence organises the rights of use; it does not dispense with knowing who wrote what and when. Dating the versions of an open project documents its history independently of the forge.
The proof rests on the SHA-512 fingerprint of the archive, from which it cannot be reconstructed. Verifying the proof requires the archive; producing it remains your decision.
The archive travels over an encrypted connection and is encrypted server-side before storage. The Security page details the set-up.
Keys, tokens and passwords have no place in a dated version: they prove nothing and create a risk. Exclude them before generating the archive.
In a dispute, you choose what you produce: a proof can bear on an isolated module rather than the whole project, if that is what is disputed.
The developer archives version v0.3.0 of their library, with its notes, and creates a proof. The synchronisation component is already in it.
The code is shown to the client; the collaboration begins. The developer archives and dates the version presented.
Delivery of v1.0.0, archive dated on the day of sending, handover email with Sealway in BCC.
The client claims the synchronisation component was developed for them. The proof of 10 January shows that a specific version of the component existed before the collaboration.
The proof of 10 January establishes that an archive containing this component, in this form, existed on that date, before the presentation to the client. It can help show that the component pre-dated the collaboration; on its own it does not determine who owns the rights on the delivered version, which the contract, any assignments and, failing agreement, the court decide.
Different tools for different needs: working, dating, depositing, escrowing.
| Approach | What it brings | Its limits |
|---|---|---|
| Git history, hosted repository | The working chronology: commits, authors, messages, branches; traces held by the host. | Dates declared by machines, rewritable history; no independent finding of a date. |
| e-Soleau (French INPI) | An INPI receipt with the deposit date, the list of items and their fingerprints; retention by the INPI. | Confers no right; limited volume per deposit; deposit of the content with a body. |
| Deposit with the APP | Evidential archiving of a version by a body specialised in software, with escrow options. | Confers no right; the body’s own procedure and cost. |
| Escrow (INPI, APP) | Source code placed in escrow for a beneficiary, accessible on agreed conditions: continuity of operation. | Meets a need for continuity, not for dating prior existence. |
| Sealway | An archive dated by a qualified electronic timestamp, verifiable without Sealway, with no deposit of the content with any body. €1.99 per proof. | Confers no right; establishes neither originality, nor authorship, nor ownership; does not certify Git’s internal dates. |
These means do not exclude one another: a project can be dated at each version with Sealway, deposited at a key step and placed in escrow for a client. None of them replaces a clear contract on the rights.
The contract, the author’s status, the licences and, in a disagreement, the court decide the rest. The proof gives them a version and a date that do not depend on the person producing them.
A version archive is placed in a Sealway proof on the day it matters. Months later, it is possible to verify that the archive produced is the one bound to the timestamp created that day.
What developers, studios and their clients ask.
Texts, decisions and official sources cited on this page; the French sources are in French.
Sealway does not provide legal advice. The protection of software, the ownership of rights and compliance with licences depend on the applicable law, on the contracts and, in a disagreement, on the court’s assessment. The French provisions cited implement EU directives; other jurisdictions have their own rules on authorship and employee-created software.
A piece of music before sending it, a deliverable handed over by email: a dated version before it leaves your hands.
Demo, master, beat, lyrics or stems: document a version before sending it to a label, a producer or a collaborator.
Learn more →Prove what was sent to the client, with which attachment and when, by adding Sealway in BCC of the handover email.
Learn more →An archive, a SHA-512 fingerprint, a qualified electronic timestamp under eIDAS, an evidence file a third party can verify. Join the waitlist to be notified at launch.
Thank you! Your registration is recorded. We will reach out shortly.