Bitcoin Magazine : Open source contre source disponible : ce que l’échec de Coldcard révèle sur les incitations logicielles de Bitcoin

Le code source fermé et l’open source divisent l’industrie du Bitcoin et, plus largement, de la crypto depuis plus de dix ans. Les défenseurs de Bitcoin affirment depuis longtemps que l’infrastructure financière du monde devrait être construite en public, estimant que la transparence et l’auditabilité sont non négociables lorsque de l’argent réel est en jeu. Les couches applicatives et héritées de la finance ne sont souvent pas d’accord.

Le récent piratage de Coldcard, un portefeuille matériel populaire en auto-conservation, lors duquel des utilisateurs ont perdu plus de 100 millions de dollars en bitcoin, soit plus de 1,500 BTC, a soulevé des questions sur ce que signifie réellement « open source ». Il a aussi laissé entendre que beaucoup de personnes, y compris certains bitcoiners chevronnés, connaissent mal la philosophie du logiciel open source et les conditions dans lesquelles elle échoue.

Les principes et la terminologie

Le vocabulaire autour de l’open source peut prêter à confusion. Free and Open Source Software (FOSS) et Free/Libre and Open Source Software (FLOSS) décrivent des logiciels qui répondent à des définitions formelles de liberté de l’utilisateur.

La Free Software Foundation (FSF) définit le logiciel libre à travers quatre libertés essentielles :

Freedom 0 : la liberté d’exécuter le programme comme vous le souhaitez, pour n’importe quel usage.

Freedom 1 : la liberté d’étudier le fonctionnement du programme et de le modifier afin qu’il fasse ce que vous souhaitez. L’accès au code source est une condition préalable à cela.

Freedom 2 : la liberté de redistribuer des copies afin d’aider les autres.

Freedom 3 : la liberté de distribuer des copies de vos versions modifiées à d’autres. L’accès au code source est une condition préalable à cela.

La FSF souligne que « free » renvoie à la liberté, et non au prix, dans la formule bien connue des défenseurs du FOSS : « “free” as in “free speech,” not as in “free beer.” »

La définition de l’Open Source Initiative ajoute dix critères pratiques. Ils incluent la libre redistribution sans redevances, la mise à disposition du code source dans la forme préférée pour la modification, le droit de créer et de distribuer des œuvres dérivées, ainsi que l’absence de discrimination envers des personnes, des groupes ou des domaines d’activité, y compris l’usage commercial. Une licence doit satisfaire les dix critères pour être considérée comme open source selon la norme de l’OSI.

« Source available » ou « source viewable » est différent. Le code peut être lisible publiquement alors que la licence restreint toujours le droit de le vendre. Le firmware de Coldcard, par exemple, est publié sous les termes MIT plus la Commons Clause. Cette clause retire spécifiquement le droit de « Sell » le logiciel — défini comme le fait de le fournir à des tiers contre rémunération ou autre contrepartie dans un produit ou service dont la valeur provient entièrement ou substantiellement du logiciel lui-même. En d’autres termes, le firmware de Coldcard ne pouvait pas être utilisé commercialement.

La FAQ de la Commons Clause énonce clairement la distinction : « Is this ‘Open Source’? No. » Elle précise que l’application de la clause signifie que le logiciel remplit de nombreux éléments de la définition de l’open source, mais pas tous, et qu’il ne doit donc pas être qualifié d’open source.

Ces distinctions comptent. Publier le code source crée la possibilité d’un examen. Accorder l’ensemble des droits définis par la définition du logiciel libre ou de l’open source est ce qui fait d’un logiciel du FOSS ou du FLOSS. Mais l’obtention d’un label n’est pas le point central. Les critiques soutiennent que la liberté commerciale dans le FOSS déclenche des incitations pour des tiers à tester et examiner le code, incitations qui pourraient autrement ne pas exister.

Les quatre libertés constituent le cœur philosophique de l’open source, mais, en pratique, elles reposent sur une hypothèse économique : suffisamment de personnes motivées examineront effectivement le code. Lorsque cette hypothèse échoue, le système produit un classique problème des communs, une situation dans laquelle une ressource partagée est surutilisée ou négligée parce que les utilisateurs agissent selon leur intérêt personnel à court terme plutôt que selon l’intérêt collectif à long terme.

Chaque personne a intérêt à prendre davantage, ou à contribuer moins, que ce qui est soutenable, et la ressource se dégrade en conséquence. Cela se produit lorsqu’il existe un désalignement entre l’intérêt personnel à court terme de l’individu et l’intérêt collectif à long terme du groupe. Parfois, l’alignement existe ; parfois non.

Un développeur Bitcoin a formulé le problème sans détour : « Using mocks and stubs of Open Source code in tests is irresponsible and shortsighted. Open Source code is considered safe because anyone can verify it. If you aren’t willing to do the bare minimum of testing the features you actually depend on, then you are behaving like a leech. »

En conséquence, l’open source ne crée pas la sécurité à lui seul. Il crée la possibilité de vérification. La réalisation de cette vérification dépend des incitations, des compétences et de l’attention. On considère que le FOSS historique se durcit avec le temps à mesure que des vulnérabilités sont découvertes, divulguées puis corrigées, créant ainsi des bases solides sur lesquelles d’autres peuvent construire. Le noyau Linux est un excellent exemple de FOSS durci ; il alimente la grande majorité des serveurs, de l’infrastructure cloud, des appareils Android et des systèmes embarqués du monde, ce qui en fait l’un des logiciels les plus déployés de l’histoire.

L’open source démontré par Bitcoin Core

Bitcoin Core, l’implémentation de référence de Bitcoin, constitue un autre exemple à grande échelle d’un open source pur fonctionnant dans la pratique. Le logiciel, qui opère derrière la plupart des infrastructures liées à Bitcoin, est publié sous licence MIT. Son processus de développement est public par conception.

N’importe qui peut ouvrir une pull request. La revue de code est le principal filtre et le point d’entrée recommandé pour les nouveaux contributeurs. Les relecteurs utilisent un vocabulaire formel : Concept ACK, signifiant une reconnaissance et une adhésion à l’objectif ; Approach ACK, signifiant une adhésion à l’objectif et à la méthode ; ACK avec un hash de commit spécifique, signifiant testé et approuvé pour intégration ; ou NACK, signifiant un désaccord accompagné d’un raisonnement technique.

Les mainteneurs évaluent le consensus entre contributeurs et la valeur technique d’un changement avant de l’intégrer. Les modifications critiques pour le consensus font face à une barre encore plus haute et nécessitent généralement une Bitcoin Improvement Proposal, ainsi que de longues discussions pluriannuelles sur la mailing list bitcoin-dev et sur IRC.

Il n’existe pas de caste privilégiée de « Bitcoin Core developers ». La confiance s’acquiert avec le temps grâce à une compétence démontrée. Les mainteneurs existent pour des raisons pratiques : audit et fusion du code, gestion des versions et modération de base. Mais le résultat est un code open source pur que tout le monde peut inspecter, compiler, forker ou exécuter. Les développeurs dont les commits sont intégrés dans Bitcoin Core sont généralement appelés Bitcoin Core Contributors.

Calle, développeur Bitcoin open source de longue date, a résumé récemment la situation : « People who think that core is some sort of intransparent institution operating in the shadows are either too lazy or too dumb to go have a look for themselves. Literally everything they do is public, anyone can chime in, and the result of their work is pure Open Source code. »

Le financement de ce travail passe largement par des structures à but non lucratif et des subventions telles que Brink, OpenSats, Spiral et d’autres, plutôt que par une feuille de route produit traditionnelle d’entreprise. Les discussions techniques et les débats ont lieu publiquement sur la mailing list bitcoin-dev et dans le canal IRC #bitcoin-core-dev sur Libera Chat, où les propositions sont examinées avant et pendant le processus de pull request. Les issues et pull requests GitHub comportent souvent des historiques de commentaires remontant à dix ans. Le résultat est une culture de développement optimisée pour la justesse et l’auditabilité plutôt que pour la vitesse ou la rapidité d’ajout de fonctionnalités commerciales.

L’économie de l’open source

La plupart des utilisateurs de logiciels open source ou source available ne lisent jamais eux-mêmes le code. Ils s’appuient sur l’hypothèse que d’autres l’examinent. Dans le cas de Coldcard, une faille critique liée à l’entropie est restée dans un firmware publiquement disponible pendant environ cinq ans avant d’être exploitée et donc découverte.

Le bug est entré dans la base de code lors d’une importante réécriture en 2021 qui a également supprimé le code restant dérivé de la GPL de Trezor, le premier portefeuille matériel et désormais le deuxième plus grand dans l’industrie de l’auto-conservation. La bibliothèque au cœur de la défaillance d’entropie, qui a remplacé trezor-crypto, s’appelle libngu et a bénéficié d’un examen externe minimal, avec seulement 7 étoiles et moins de 20 forks en plus de cinq ans d’utilisation en production. Comparez cela aux 512 étoiles et 212 forks de la bibliothèque trezor-crypto, ou aux 793 forks et 1.8k étoiles de trezor-firmware, plus moderne. La simple disponibilité du code source n’a pas produit la revue qui comptait, parce que d’autres entreprises à but lucratif, bien financées, en étaient empêchées, selon les critiques.

En pratique, cela fait des choix de licence plus qu’une note juridique de bas de page : ils influencent qui peut participer à la revue, qui a intérêt à le faire, et à quelle vitesse les failles peuvent être repérées dans des logiciels qui protègent des fonds réels. Les enjeux sont plus élevés dans Bitcoin que dans la plupart des domaines logiciels. Une faille critique peut être transformée directement en liquidités sur le marché libre. Alors que la première moitié des fonds Coldcard volés est toujours détenue dans quelques adresses et que le pirate pourrait un jour être arrêté, les imitateurs qui ont suivi ont été plus prudents, et certains ont volé davantage de bitcoin et l’ont blanchi avec succès, selon Galaxy Research. La résistance à la censure et la capacité de transaction immuable de Bitcoin créent à la fois une forte incitation pour les attaquants et un filtre darwinien : seuls les projets qui attirent en continu des revues compétentes, ainsi que les utilisateurs et entreprises qui prennent des précautions sérieuses, tendent à survivre à long terme.

Les choix de licence façonnent ces incitations, selon les défenseurs du FOSS qui ont critiqué pendant des années les décisions de licence de Coinkite. Les licences open source pures maximisent le vivier de relecteurs potentiels et de forks. Les licences « source available » restreintes peuvent réduire le parasitisme commercial, mais elles peuvent aussi réduire le cercle des personnes ayant à la fois le droit légal et la motivation économique d’y consacrer une attention soutenue. En ce sens, la charge de la revue de code retombe sur l’entreprise sous licence restrictive, la rapprochant davantage du code fermé que de l’open source.

Comment l’IA modifie le développement open et closed source

L’intelligence artificielle modifie désormais aussi l’équilibre entre FOSS et source fermé.

Après l’incident Coldcard, une initiative bénévole connue sous le nom de Bitcoin Red Team — menée par des développeurs dont Calle et Rob Hamilton d’AnchorWatch, et soutenue par OpenSats — a utilisé des modèles d’IA de pointe pour analyser des centaines de dépôts Bitcoin open source. Au cours d’une période intensive, l’équipe a soumis des milliers de constats, dont des dizaines classés critiques ou de gravité élevée, sur des centaines de projets. Des divulgations responsables ont été faites aux mainteneurs avant une publication plus large. L’exercice a montré qu’une revue systématique assistée par l’IA peut faire émerger des problèmes à une échelle et à une vitesse auparavant impraticables pour des équipes purement humaines.

Sur ce point, l’équipe Red Team a constaté que les modèles chinois open-weight étaient bien plus fiables que les modèles américains fermés, lesquels, même avec des autorisations cyber et un accès de premier plan, refusaient de répondre aux requêtes de la Red Team, une tendance que les développeurs américains déplorent.

Dans le même temps, l’afflux de code généré par l’IA a créé une nouvelle pression de déni de service sur les mainteneurs du FOSS. Examiner la sortie de l’IA prend souvent plus de temps que la générer. Certains projets open source en dehors de Bitcoin ont restreint leurs issue trackers ou imposé des règles strictes anti-contributions IA simplement pour rester fonctionnels.

Du côté du code fermé, l’avantage traditionnel de la sécurité par l’obscurité s’érode. Les modèles d’IA modernes peuvent lire, dé-obfusquer, sonder des endpoints et raisonner sur le code à très grande vitesse. La différence pratique entre open source et code fermé se limite désormais principalement au code back-end qui n’est jamais partagé en ligne. Le code fermé repose donc sur la qualité des audits professionnels, la vitesse de déploiement des correctifs et la structure d’incitation qui maintient l’attention des personnes compétentes ayant accès au code.

Bitcoin et l’industrie crypto au sens large exercent une pression inhabituelle sur les logiciels libres et open source. La combinaison de valeur monétaire réelle en jeu, d’une économie adverse et d’une analyse à l’échelle de l’IA oblige les modèles logiciels à évoluer. Revenir à des systèmes analogiques pré-numériques est à peine envisageable pour une infrastructure qui soutient la société moderne. Seuls les projets les plus audités sont susceptibles de survivre à la pression des hackers assistés par l’IA et au poids de la finance numérique d’abord.

Cet article, « Open Source vs. Source-Available: What the Coldcard Failure Teaches About Bitcoin Software Incentives », est apparu pour la première fois sur Bitcoin Magazine et a été rédigé par Juan Galt.