Label 309 est-il open source ?

Oui. Label 309 est un standard ouvert, et non le fossé concurrentiel d'un produit privé. Le code est publié sous licence Apache-2.0, la prose de la spécification sous Creative Commons Attribution 4.0 (CC-BY-4.0), et l'ensemble réside dans des dépôts publics sur github.com/cardanowall. Les développeurs, les entreprises, les chercheurs et l'ensemble de la communauté Cardano peuvent l'implémenter, l'auditer, le forker, en faire des produits et exploiter leur propre infrastructure sans rien demander à CardanoWall.

C'est précisément là tout l'enjeu. CardanoWall est le premier produit abouti construit autour du standard. Il n'est délibérément pas le seul produit qui puisse s'en servir.

Peut-on vraiment parler de standard quand un seul produit l'a créé ?

Oui, mais à une seule condition : que le travail soit utilisable en dehors de ce produit.

Un standard de preuve d'existence doit survivre à l'entreprise qui en livre la première une interface soignée. Si un record ne peut être produit que par un seul site web, vérifié que par un seul serveur ou compris que par un seul backend privé, ce n'est pas un standard public. C'est une fonctionnalité.

Label 309 emprunte la voie inverse :

• le format de record est entièrement documenté ;
• la preuve réside dans les métadonnées de transaction Cardano, sous le label de métadonnées 309 ;
• la vérification s'effectue à partir des données publiques de la chaîne et des clés locales, sans qu'aucun serveur d'émetteur n'intervienne ;
• l'outillage — SDK, outil en ligne de commande, application de bureau et gateway — est diffusé sous forme de logiciel open source ;
• les gateways peuvent être exploités par quiconque, pas seulement par CardanoWall ;
• les clients peuvent être des applications web, des applications de bureau, des outils en ligne de commande, des intégrations de SDK ou des systèmes internes d'entreprise.

CardanoWall peut malgré tout proposer l'expérience hébergée la plus simple. Mais la preuve elle-même ne dépend pas du fait que CardanoWall soit de confiance, en ligne ou impliqué commercialement. Pour une démonstration pas à pas de cette indépendance, voyez comment vérifier un record Label 309.

S'agit-il de CIP-309 ?

La formulation exacte a son importance ici ; mieux vaut donc être précis.

La proposition de preuve d'existence a été soumise au processus CIP de Cardano et fait actuellement l'objet d'un examen par les éditeurs CIP, au titre d'une proposition de catégorie Metadata. Comme le record utilise le label de métadonnées 309 de Cardano, on l'appelle parfois informellement « CIP-309 » — mais le label de métadonnées n'est pas le numéro de CIP. Ce sont deux identifiants distincts. Dans la pull request ouverte, la proposition apparaît pour l'instant sous un numéro provisoire, listée comme « CIP-0190? | Proof of Existence Transaction Metadata ». Vous pouvez suivre la discussion dans la pull request CIP.

Tant que l'examen n'est pas conclu, les appellations exactes sont Label 309, label de métadonnées 309 ou la proposition CIP de preuve d'existence. Ce n'est pas encore un standard Cardano accepté ni officiel, et il n'existe aucun « CIP-309 » attribué.

L'engagement open source ne dépend pas du numéro de CIP final. Le principe sous-jacent est plus simple : la communauté doit pouvoir lire, implémenter, tester et réutiliser le standard sans l'aval privé de l'auteur d'origine.

Qu'apporte l'open source aux développeurs ?

Il fait passer le standard du statut de promesse à celui d'un objet que vous pouvez inspecter et exécuter vous-même.

Pour les développeurs, le code public signifie que vous pouvez :

• lire l'implémentation plutôt que d'en déduire le comportement à partir d'un discours marketing ;
• voir exactement comment les records sont encodés, signés, scellés et vérifiés ;
• réutiliser les SDK (TypeScript, Python et Rust) dans vos propres applications ;
• bâtir sur eux des outils en ligne de commande, des tableaux de bord, des vérificateurs et des utilitaires de téléversement sur mesure ;
• intégrer la publication de preuves dans des chaînes CI/CD, des systèmes de conformité, des flux juridiques ou des pipelines de contenu IA ;
• exécuter des tests de conformité sur votre propre implémentation, validés au regard de vecteurs de test canoniques partagés ;
• signaler des problèmes ou proposer des changements au grand jour ;
• forker le code si vous avez besoin d'une autre forme de produit.

C'est important, car la preuve d'existence est une infrastructure, et une infrastructure gagne en crédibilité lorsque d'autres peuvent bâtir dessus sans accord privé préalable. S'intégrer au niveau le plus bas — exploiter votre propre gateway — est une voie prise en charge, pas un contournement.

Que permet la licence Apache-2.0 ?

Apache-2.0 est une licence open source permissive, et elle couvre le code : les SDK, l'outil en ligne de commande, le gateway, le vérificateur et les schémas.

Concrètement, elle vous autorise à utiliser, modifier, distribuer le code sous licence et à bâtir dessus — y compris dans des produits commerciaux — dès lors que vous en respectez les termes. Elle accorde également une licence de brevet explicite de la part des contributeurs, l'une des raisons pour lesquelles elle est un choix courant pour l'infrastructure et l'outillage destiné aux développeurs. Vous pouvez en lire le texte intégral sur apache.org/licenses/LICENSE-2.0.

Cela convient bien aux logiciels Label 309 :

• les SDK doivent être faciles à intégrer ;
• les outils en ligne de commande doivent être faciles à empaqueter ;
• le code du gateway doit être facile à auto-héberger ;
• les vérificateurs doivent être faciles à exécuter de façon indépendante ;
• les entreprises doivent pouvoir livrer des produits sans négocier une autorisation sur mesure.

Open source ne veut pas dire « sans conditions ». Les mentions de licence, les fichiers d'attribution et les termes relatifs aux brevets continuent de s'appliquer. Cela signifie que l'autorisation découle de la licence elle-même, et non d'une conversation privée avec CardanoWall.

Pourquoi la spécification est-elle sous licence Creative Commons ?

La licence du code et celle de la spécification sont deux décisions distinctes, et Label 309 rend les deux explicites.

Le code, les schémas, la grammaire CDDL et les vecteurs de test de conformité sont sous Apache-2.0. La prose lisible de la spécification est, elle, placée sous Creative Commons Attribution 4.0 (CC-BY-4.0). Une licence de documentation convient mieux au texte d'une spécification, car l'objectif est une réutilisation large — par les implémenteurs, les enseignants, les auteurs de portefeuilles, les opérateurs de gateway, les auditeurs, les entreprises et d'autres rédacteurs de standards. CC-BY-4.0 préserve l'attribution tout en autorisant cette large réutilisation.

Cette séparation est intentionnelle et déjà tranchée dans le dépôt ; ce n'est pas une question ouverte en attente de résolution avant le lancement. Les droits sont cédés à la communauté afin que bâtir sur Label 309 ne requière jamais d'autorisation privée. Si l'on attend de la communauté qu'elle implémente le standard, il lui faut une licence qui le permette clairement.

Quelqu'un peut-il construire un produit concurrent ?

Oui — et ce n'est pas un échec du standard. C'est la preuve qu'il est suffisamment ouvert pour compter.

On pourrait construire :

• un autre gateway hébergé ;
• un gateway local à usage interne d'entreprise ;
• un gestionnaire de preuves d'abord pensé pour le bureau ;
• un vérificateur Label 309 intégré à un portefeuille ;
• un tableau de bord de preuves juridiques ;
• un pipeline de provenance IA ;
• un pont d'attestation CI/CD ;
• une archive de conformité ;
• un explorateur public de records Label 309 ;
• un client mobile pour recevoir des records scellés.

Certains de ces projets concurrenceraient CardanoWall. D'autres le compléteraient. D'autres encore serviraient des secteurs sur lesquels CardanoWall ne se concentre jamais. Tout cela est sain : un standard de preuve gagne en robustesse lorsque de nombreux outils indépendants peuvent produire et vérifier le même type de record.

Qu'est-ce qui reste spécifique à CardanoWall ?

L'open source n'efface pas la frontière entre un standard et un produit.

Le format de record Label 309, les SDK, l'outil en ligne de commande, le code du gateway et la logique de vérification sont ouverts à l'usage de tous. CardanoWall conserve néanmoins son propre service hébergé, son interface utilisateur, sa tarification, son support, ses politiques opérationnelles, sa marque, son domaine et sa feuille de route produit — et tout cela lui reste propre.

Cette distinction protège les deux camps :

• les utilisateurs disposent d'un produit hébergé pratique ;
• les développeurs disposent d'une infrastructure réutilisable ;
• les entreprises peuvent auto-héberger lorsqu'elles ont besoin de maîtrise ;
• la communauté peut vérifier et étendre le standard ;
• CardanoWall continue de construire un produit sans faire dépendre le protocole d'une seule entreprise.

La marque n'est pas le standard. Le service hébergé n'est pas le standard. Le standard, c'est le format de record et l'outillage interopérable qui l'entoure.

Pourquoi l'open source compte-t-il pour la confiance ?

Les systèmes de preuve sont faciles à affaiblir par des dépendances cachées.

S'il vous faut faire confiance à la base de données d'un fournisseur pour savoir qu'une preuve existe, le système est plus fragile. Si un record ne peut être vérifié sans compte hébergé, la preuve est moins portable. Si un autre développeur ne peut pas implémenter le même format, l'écosystème ne peut pas tester de façon indépendante la solidité de ce format. L'open source supprime ces pièges.

Avec Label 309, n'importe qui peut partir des données publiques de Cardano, récupérer le record, en valider la structure, recalculer les empreintes, vérifier les signatures, ouvrir localement les contenus scellés lorsqu'on en est un destinataire prévu, et confirmer les preuves d'inclusion Merkle lorsqu'un seul record tient lieu de nombreux fichiers. CardanoWall peut rendre ce flux agréable ; le standard ouvert le rend indépendant.

Qu'est-ce que cela signifie pour les entreprises ?

Pour les entreprises, une licence ouverte réduit le risque d'adoption.

Une entreprise pourrait commencer par le gateway hébergé de CardanoWall parce qu'il est rapide. Plus tard, cette même entreprise pourrait avoir besoin d'exploiter un gateway dans son propre cloud, de connecter des systèmes d'identité internes, d'archiver des pièces sous une politique de conservation légale, ou de publier des milliers d'engagements Merkle depuis un pipeline privé. Un standard ouvert rend cette trajectoire réaliste.

Le choix ne se résume pas à « rester pour toujours sur l'interface hébergée » contre « tout réécrire de zéro ». Une entreprise peut commencer avec CardanoWall, ajouter de l'automatisation via SDK ou API, déplacer certains flux vers l'outil en ligne de commande, et finalement exploiter son propre gateway si la politique ou l'échelle l'exigent. C'est ce parcours progressif qu'exige une infrastructure sérieuse.

Qu'est-ce que cela signifie pour les utilisateurs au quotidien ?

Pour la plupart des gens, l'open source ne consiste pas à lire du code tous les jours.

Cela signifie que les outils qui entourent vos preuves sont moins fragiles. Si vous publiez une preuve aujourd'hui, vous ne devriez pas avoir besoin qu'un site web précis reste en ligne pour qu'elle ait un sens demain. D'autres outils peuvent vérifier le record. D'autres clients peuvent ouvrir les records scellés lorsque vous détenez la bonne identité. D'autres gateways peuvent publier des preuves compatibles. En pratique, vous pouvez déjà utiliser CardanoWall sans le site web grâce à l'outil en ligne de commande open source et aux SDK.

L'expérience peut être simple parce que le produit est soigné. La confiance à long terme vient du fait que le format n'est pas prisonnier de ce produit.

Avec quoi ne faut-il pas confondre l'open source ?

L'open source est utile, mais ce n'est pas magique, et il ne règle pas à lui seul toutes les questions.

Il ne signifie pas que tout service hébergé est gratuit : un gateway paie toujours les frais de réseau Cardano, le stockage Arweave, l'infrastructure et les coûts d'exploitation. Il ne signifie pas que la marque ou les marques déposées de CardanoWall peuvent être utilisées de façon trompeuse. Il ne signifie pas que toute pull request est acceptée. Et il ne signifie pas qu'une implémentation est sûre du simple fait qu'elle suit le même standard.

Il ne remplace pas non plus la diligence requise. Avant de vous reposer sur une implémentation de production — la vôtre ou celle d'un tiers — il vaut la peine de vérifier :

• les fichiers de licence réellement présents dans le dépôt ;
• la licence de la spécification ;
• le statut de la proposition CIP ;
• l'état de publication des SDK et du gateway ;
• le modèle de sécurité des identités, du scellement et des clés de destinataire ;
• les tests de conformité au regard desquels l'implémentation est validée.

La promesse de l'open source n'est pas que personne n'a besoin de rien vérifier. La promesse, c'est que la vérification est possible.

En bref

Label 309 est ouvert à chaque couche qui compte pour l'interopérabilité. Le code est sous Apache-2.0. La spécification est sous CC-BY-4.0. Le gateway est auto-hébergeable. La vérification fonctionne sans faire confiance à CardanoWall. Les développeurs sont libres de construire leurs propres outils et produits.

CardanoWall est le premier produit complet. Le standard appartient à l'écosystème.

Pour aller plus loin

• Le site du standard : label309.org
• Le code open source, les SDK et l'outil en ligne de commande : github.com/cardanowall
• La pull request CIP de Cardano : github.com/cardano-foundation/CIPs/pull/1205
• Licence Apache 2.0
• Creative Commons Attribution 4.0