Une archive de votre projet ou d’une release, une preuve Sealway, et vous pouvez établir des mois plus tard que cette version exacte existait déjà à cette date : avant une livraison, une collaboration, une sortie. Sealway ne dit pas qui a écrit le code, ni à qui il appartient, ni s’il est original ; il fixe un contenu et une date.
Conçu pour
Un développeur indépendant construit une librairie. Il en envoie une première version à un client, puis la fait évoluer avec lui pendant plusieurs mois. Un désaccord apparaît ensuite sur l’origine de certaines fonctions : existaient-elles avant la collaboration, ou ont-elles été écrites pour le client ?
Les affirmations se contredisent, et chacun produit ce qu’il a : des captures d’écran, un dépôt Git dont l’historique montre des dates, des emails. Or les dates d’un historique Git sont écrites par la machine de celui qui commet et peuvent être réécrites ; un dépôt hébergé montre ce que l’hébergeur affiche, pas une constatation indépendante ; une archive retrouvée sur un disque porte la date que le système lui donne. Rien de tout cela ne fixe, de façon vérifiable par un tiers, qu’une version précise existait à une date précise.
Une preuve Sealway créée le jour où la version existait répond à cette question, et à elle seule : cette archive, avec ce contenu exact, existait au plus tard à cette date. Qui en est l’auteur, à qui appartiennent les droits, si le code est original ou s’il reprend du code tiers restent des questions de droit et de contrat, que la preuve n’absorbe pas.
L’historique de votre dépôt raconte le travail : qui a commis quoi, dans quel ordre, avec quels messages. C’est une chronologie précieuse, mais produite par vous, sur des machines que vous contrôlez, et modifiable. L’archive d’une version fige le contenu exact d’une étape : ce que contenait le projet à ce moment-là, sans dépendre de l’outil.
Sealway ajoute la couche qui manque aux deux : une date fixée par un tiers qualifié et une empreinte qui permet de vérifier, plus tard, que l’archive produite est bien celle de l’époque. L’historique reste utile pour expliquer ; l’archive et sa preuve servent à établir.
Aucun connecteur, rien à installer : le parcours fonctionne avec n’importe quel outil, dépôt ou forge, puisqu’il part d’une archive.
Le logiciel est protégé par le droit d’auteur, sans formalité, s’il est original. Trois questions distinctes se posent en cas de litige : le code existait-il à cette date, est-il original, à qui appartiennent les droits ? Sealway ne répond qu’à la première.
Sont considérés comme œuvres de l’esprit « les logiciels, y compris le matériel de conception préparatoire ». Dans l’Union européenne, les programmes d’ordinateur sont protégés par le droit d’auteur en tant qu’œuvres littéraires ; la protection s’applique à toute forme d’expression du programme, et non aux idées et principes qui sont à sa base.
L’auteur jouit de son droit du seul fait de la création, et l’œuvre est réputée créée, indépendamment de toute divulgation, du seul fait de la réalisation, même inachevée, de la conception de l’auteur. Un prototype, une branche de travail, un module isolé relèvent déjà du droit d’auteur s’ils sont originaux. Aucun dépôt ne crée le droit ; encore faut-il pouvoir montrer ce qui existait, et quand.
Un programme est protégé s’il est original, « en ce sens qu’il est la création intellectuelle propre à son auteur ». La Cour de cassation exige que soit recherché en quoi les choix opérés témoignent d’un apport intellectuel propre et d’un effort personnalisé ; apporter « une solution particulière » à un problème ne suffit pas. Une preuve d’existence n’établit pas l’originalité.
Ni la fonctionnalité d’un programme, ni le langage de programmation, ni le format des fichiers de données utilisés pour exploiter certaines de ses fonctions ne constituent une forme d’expression du programme protégée par le droit d’auteur. Ce que l’on date est un code, pas une idée ni une fonction.
La qualité d’auteur appartient, sauf preuve contraire, à celui sous le nom de qui l’œuvre est divulguée. Pour les logiciels créés par des employés dans l’exercice de leurs fonctions ou d’après les instructions de l’employeur, les droits patrimoniaux sont dévolus à l’employeur, sauf dispositions statutaires ou stipulations contraires. Un indépendant conserve ses droits sauf cession prévue au contrat. Une date ne tranche aucune de ces questions.
Trois besoins se distinguent : dater une version (e-Soleau de l’INPI, Sealway), l’archiver à titre probatoire auprès d’un organisme (Agence pour la protection des programmes) ou la placer sous séquestre au profit d’un client (entiercement de l’INPI). Le tableau ci-dessous compare ce que chacun établit. Sealway répond au premier besoin, par un horodatage qualifié vérifiable sans lui ; il n’est ni un dépôt, ni un séquestre.
Cour de cassation · 1re chambre civile · 17 octobre 2012
Cassation · décision attaquée : cour d’appel d’Aix-en-Provence, 11 mai 2011
Un éditeur poursuit un concurrent en contrefaçon d’un logiciel de gestion d’études d’huissiers. La cour d’appel retient l’originalité du logiciel au motif qu’il apporte « une solution particulière » à cette gestion. La Cour de cassation casse l’arrêt.
En se déterminant ainsi, sans rechercher en quoi les choix opérés témoignaient d’un apport intellectuel propre et d’un effort personnalisé de celui qui avait élaboré le logiciel litigieux, seuls de nature à lui conférer le caractère d’une œuvre originale protégée, comme telle, par le droit d’auteur, la cour d’appel n’a pas donné de base légale à sa décision.
Ce que Sealway en retient
Exister à une date et être protégé sont deux choses. La preuve Sealway fixe la première ; l’originalité, elle, se démontre par les choix de conception du code, et c’est une autre discussion. Produire une archive datée ne dispense pas de la mener, mais évite qu’elle ne bute d’abord sur « quelle version existait quand ».
Le parcours est manuel et tient en quelques minutes : générer l’archive d’une version, la vérifier, créer la preuve, conserver l’archive. Il fonctionne avec n’importe quel outil de versionnement, ou sans.
Une version qui va quitter vos mains ou changer de nature : envoi à un client, livraison contractuelle, release, refonte. Pas chaque commit.
Export ou archive de la version depuis votre outil (une archive Git d’un tag, par exemple), en ZIP ou TAR. Avec ou sans le répertoire .git : s’il est inclus, son historique fait partie du contenu daté, sans que ses dates internes soient certifiées pour autant.
Ouvrez-la : elle contient bien les sources complètes, les notes de version, aucun secret. C’est cette archive exacte que vous produirez plus tard ; une archive régénérée ensuite aura une autre empreinte.
Depuis l’application, importez l’archive et, si utile, les notes de version ou un README à part. Donnez à la preuve un titre explicite, « lib-x v1.4.0 », et notez dans la description le tag et l’identifiant du commit : ce sont des repères pour vous, modifiables, hors de ce qui est horodaté.
Gardez l’archive telle quelle, dans un stockage à vous, avec le dossier de preuve : sans offre de stockage, Sealway conserve l’original 7 jours. Le dossier de preuve téléchargé reste vérifiable sans limite de durée, mais il ne vaut que face à l’archive.
Une preuve par version qui compte, dans un dossier au nom du projet : la chronologie des versions se lit dans le dossier, et chaque preuve se vérifie séparément.
Jusqu’à 10 fichiers et 250 Mo par preuve. Une archive dépasse rarement cela ; un projet plus volumineux se découpe en plusieurs archives, dans une même preuve ou dans un même dossier Sealway.
Il n’est pas nécessaire de créer une preuve à chaque commit. Il est plus pertinent de documenter les étapes importantes : release, livraison, transfert à un tiers, changement majeur.
Première archive du projet, avant tout envoi. Preuve « v0.1.0 ».
La version présentée puis livrée au client. Preuve créée le jour de l’envoi.
La version publiée ou mise en production. Preuve « v1.0.0 » avec les notes de version.
Nouvelle architecture, nouveaux composants : une preuve qui marque le changement.
Chaque preuve fixe une version et une date. Mises bout à bout dans le dossier du projet, elles racontent ce qui existait avant chaque étape, sans dépendre de l’historique de votre outil.
Sealway prouve l’existence de cette archive, historique compris, à la date de la preuve. Les dates des commits qu’elle contient existaient donc à cette date ; elles ne deviennent pas des faits certifiés.
L’hébergeur affiche des dates et des auteurs ; c’est une trace chez un tiers, utile, mais qui dépend de ses règles, de sa conservation et d’un historique qui peut être forcé. Ce n’est pas un horodatage qualifié.
Une signature établit que le contenu vient d’une clé donnée et n’a pas changé depuis la signature. Elle n’établit pas la date à laquelle elle a été apposée autrement que par déclaration.
Ils montrent qu’une construction a été lancée sur un contenu donné ; ce sont des traces d’exploitation, conservées un temps, sur une infrastructure que vous ou votre hébergeur contrôlez.
Une preuve datée sert quel que soit le régime, mais elle ne le change pas.
Les droits patrimoniaux sur les logiciels créés par des employés dans l’exercice de leurs fonctions ou d’après les instructions de l’employeur sont dévolus à l’employeur, sauf dispositions statutaires ou stipulations contraires (art. L. 113-9). L’employeur a intérêt à dater les versions ; le salarié reste l’auteur.
Le prestataire conserve ses droits sauf cession prévue au contrat. Dater ce qui existait avant la mission distingue le code préexistant du code écrit pour le client ; le contrat dit ce qui est cédé.
Le client qui reçoit une livraison a lui aussi intérêt à dater ce qu’il a reçu, et quand : une preuve de l’archive livrée, à la réception, complète le procès-verbal de recette.
Une licence libre organise les droits d’utilisation ; elle ne dispense pas de savoir qui a écrit quoi et quand. Dater les versions d’un projet ouvert documente son histoire indépendamment de la forge.
La preuve repose sur l’empreinte SHA-512 de l’archive, qui ne permet pas de la reconstituer. Vérifier la preuve demande l’archive ; la produire reste votre décision.
L’archive transite par une connexion chiffrée et est chiffrée côté serveur avant archivage. La page Sécurité détaille le dispositif.
Clés, jetons et mots de passe n’ont rien à faire dans une version datée : ils ne prouvent rien et créent un risque. Excluez-les avant de générer l’archive.
En cas de litige, vous choisissez ce que vous produisez : une preuve peut porter sur un module isolé plutôt que sur tout le projet, si c’est lui qui est discuté.
Le développeur archive la version v0.3.0 de sa librairie, avec ses notes, et crée une preuve. Le composant de synchronisation y figure déjà.
Le code est montré au client ; la collaboration commence. Le développeur archive et date la version présentée.
Livraison de la v1.0.0, archive datée le jour de l’envoi, email de remise avec Sealway en copie cachée.
Le client soutient que le composant de synchronisation a été développé pour lui. La preuve du 10 janvier montre qu’une version précise du composant existait avant la collaboration.
La preuve du 10 janvier établit qu’une archive contenant ce composant, sous cette forme, existait à cette date, avant la présentation au client. Elle peut contribuer à montrer que le composant préexistait à la collaboration ; elle ne détermine pas à elle seule qui détient les droits sur la version livrée, ce que le contrat, les cessions éventuelles et, à défaut d’accord, le juge décident.
Des outils différents pour des besoins différents : travailler, dater, déposer, séquestrer.
| Approche | Ce qu’elle apporte | Ses limites |
|---|---|---|
| Historique Git, dépôt hébergé | La chronologie de travail : commits, auteurs, messages, branches ; des traces chez l’hébergeur. | Dates déclarées par les machines, historique réécrivable ; pas de constatation indépendante de date. |
| e-Soleau (INPI) | Un récépissé de l’INPI avec la date de dépôt, la liste des pièces et leurs empreintes ; conservation par l’INPI. | Ne confère aucun droit ; volume limité par dépôt ; dépôt du contenu auprès d’un organisme. |
| Dépôt auprès de l’APP | Un archivage probatoire d’une version par un organisme spécialisé dans les logiciels, avec des options d’entiercement. | Ne confère aucun droit ; procédure et coût propres à l’organisme. |
| Entiercement (INPI, APP) | Un code source mis sous séquestre au profit d’un bénéficiaire, accessible à des conditions convenues : continuité d’exploitation. | Répond à un besoin de continuité, pas de datation d’une antériorité. |
| Sealway | Une archive datée par un horodatage électronique qualifié, vérifiable sans Sealway, sans dépôt du contenu auprès d’un organisme. 1,99 € par preuve. | Ne confère aucun droit ; n’établit ni l’originalité, ni l’auteur, ni la titularité ; ne certifie pas les dates internes de Git. |
Ces moyens ne s’excluent pas : un projet peut être daté à chaque version avec Sealway, déposé à une étape clé et mis sous séquestre pour un client. Aucun d’eux ne remplace un contrat clair sur les droits.
Le contrat, le statut de l’auteur, les licences et, en cas de désaccord, le juge décident du reste. La preuve leur apporte une version et une date qui ne dépendent pas de celui qui les produit.
Une archive de version est placée dans une preuve Sealway le jour où elle compte. Des mois plus tard, il est possible de vérifier que l’archive produite est bien celle rattachée à l’horodatage créé ce jour-là.
Ce que demandent les développeurs, les studios et leurs clients.
Textes, décisions et sources officielles cités sur cette page.
Sealway ne fournit pas de conseil juridique. La protection d’un logiciel, la titularité des droits et le respect des licences dépendent du droit applicable, des contrats et, en cas de désaccord, de l’appréciation du juge.
Une musique avant de l’envoyer, un livrable remis par email : une version datée avant qu’elle ne quitte vos mains.
Démo, master, beat, paroles ou stems : documentez une version avant de l’envoyer à un label, un producteur ou un collaborateur.
En savoir plus →Prouvez ce qui a été envoyé au client, avec quelle pièce jointe et quand, en ajoutant Sealway en copie cachée de l’email de remise.
En savoir plus →Une archive, une empreinte SHA-512, un horodatage électronique qualifié au sens d’eIDAS, un dossier de preuve vérifiable par un tiers. Rejoignez la liste d’attente pour être prévenu au lancement.
Merci ! Votre inscription est enregistrée. Nous reviendrons vers vous très prochainement.