Considérations sur la licence du code source

L'acquisition du code source d'une plateforme d'échange est souvent présentée comme le moment où un opérateur prend le contrôle de sa propre technologie. En pratique, ce qui est acquis dépend bien moins du code lui-même que de la licence qui l'accompagne. Les mêmes fichiers peuvent être livrés selon des termes qui accordent une véritable propriété et une liberté d'exploitation, ou selon des termes qui laissent l'opérateur dépendant du fournisseur d'origine pour chaque changement significatif. Lire la licence avec attention, avant la signature d'un contrat, est donc l'une des décisions les plus lourdes de conséquences dans un achat de code source.

Le sujet se lit différemment selon le lecteur. Pour une direction générale, il touche à la valeur et à la durabilité d'un actif que l'entreprise paie, et au risque d'une dépendance qui survit à la relation. Pour une direction technique, il touche à ce qui peut être modifié, reconstruit et redéployé sans autorisation, et aux obligations de tiers qui voyagent avec le code. Pour une fonction conformité ou juridique, il touche à la clarté de la propriété intellectuelle, à la continuité de la plateforme en cas de défaillance d'un fournisseur, et à la manière dont les termes s'articulent avec les attentes réglementaires que l'échange doit satisfaire. Cet article expose des considérations sur la licence du code source à un niveau conceptuel. Il ne constitue pas un avis juridique, et les termes de tout accord précis devraient être examinés par un conseil qualifié.

Ce que couvre une licence de code source

Une licence de code source est l'accord qui définit ce qu'un opérateur peut et ne peut pas faire du code reçu. Elle établit si le code est détenu en pleine propriété ou concédé pour usage, quels droits sont transférés à la livraison et lesquels sont conservés par le fournisseur. Elle traite généralement du droit d'exploiter la plateforme, de la modifier, de la reconstruire et de la déployer, de confier des travaux à d'autres parties, et dans certains cas de la redistribuer ou de la revendre. La présence du code sur les propres serveurs d'un opérateur ne tranche à elle seule aucune de ces questions ; la licence, si.

Définir ces termes de manière délibérée importe parce qu'un achat de code source vise habituellement à sécuriser l'indépendance, et qu'une licence ambiguë ou restrictive sape précisément cela en silence. Un opérateur qui peut lire et détenir le code mais ne peut le modifier ni le reconstruire sans l'intervention du fournisseur a acquis moins qu'il ne le croit peut-être. Les considérations exposées ci-dessous existent pour rendre la différence explicite tant qu'elle relève encore de la négociation, plutôt que de la voir surgir comme une limite après la mise en production de la plateforme, une fois le rapport de force passé.

Pourquoi les termes de la licence comptent autant que le code

Deux livraisons de code source peuvent être identiques fichier par fichier et représenter pourtant des actifs très différents, car la licence détermine ce que l'opérateur est réellement libre de faire. Les termes régissent si les modifications peuvent être réalisées en interne ou par un tiers choisi, si la plateforme peut être déployée sur plusieurs entités ou une seule, si le code peut être transféré vers un autre hébergement, et si une partie peut être réutilisée dans d'autres projets. Ce sont ces termes qui décident si un achat procure un contrôle durable ou une forme plus confortable de dépendance.

La distinction devient déterminante précisément aux moments contre lesquels l'indépendance est censée protéger : un fournisseur qui cesse de répondre, change de cap, augmente ses prix ou cesse son activité. Un opérateur dont la licence lui permet de maintenir et de faire évoluer la plateforme par sa propre équipe ou une équipe choisie est protégé de tels événements ; un opérateur dont la licence lie chaque changement significatif au fournisseur d'origine ne l'est pas, quoi que puisse suggérer le code présent sur ses serveurs. C'est la licence, non la livraison, qui fixe la position de l'opérateur à long terme.

Propriété, modification et redistribution

Trois droits se trouvent au cœur de la plupart des négociations de code source. Le premier est la propriété : la propriété intellectuelle du code livré est-elle transférée à l'opérateur, ou celui-ci reçoit-il une licence d'usage d'un code que le fournisseur continue de détenir ? Le deuxième est le droit de modification : l'opérateur peut-il modifier le code librement, en interne ou par un tiers, ou seulement dans les limites fixées par le fournisseur ? Le troisième est la redistribution : l'opérateur peut-il revendre, sous-licencier ou redéployer le code au-delà de son propre usage, ce que la plupart des fournisseurs restreignent et dont la plupart des opérateurs n'ont en réalité pas besoin.

Aucun de ces droits n'est en soi bon ou mauvais ; ce qui compte, c'est que chacun soit compris et aligné sur l'intention de l'opérateur. Un opérateur en quête de pleine indépendance pèsera fortement la propriété et la modification sans restriction, tandis qu'un opérateur satisfait d'une plateforme supportée pourra accepter une licence d'usage assortie de droits de modification définis en échange d'autres avantages. L'erreur consiste à supposer que recevoir le code source règle ces droits automatiquement. Il n'en est rien, et la différence entre une cession de propriété et une licence d'usage est l'une des distinctions les plus importantes de tout l'accord.

Composants tiers et open source

Rares sont les plateformes écrites entièrement de zéro, et une base de code d'échange incorpore presque toujours des bibliothèques tierces et des composants open source, chacun porteur de sa propre licence. Ces obligations voyagent avec le code, qu'elles soient ou non détaillées dans l'accord principal, et elles peuvent imposer des conditions sur la façon dont le logiciel est utilisé, modifié et distribué. Un opérateur qui prend la propriété d'une base de code hérite de la responsabilité des licences de tout ce qu'elle contient, et un fournisseur incapable de rendre compte de ses propres dépendances constitue en soi un signal d'alerte.

L'approche réfléchie consiste à demander, avant l'achat, une clarté sur les composants tiers et open source dont dépend la plateforme et selon quels termes. Certaines licences open source sont permissives et n'imposent guère plus que l'attribution ; d'autres portent des conditions qui comptent beaucoup pour une entreprise entendant garder sa plateforme propriétaire. Le point n'est pas qu'un composant particulier soit disqualifiant, mais que l'opérateur sache ce qu'il acquiert et accepte ces obligations en connaissance de cause, plutôt que de les découvrir lors d'un audit ou d'un litige ultérieur.

Séquestre, support et maintenance

Lorsque la pleine propriété du code source n'est pas transférée, le séquestre de code source est une voie intermédiaire courante. Dans un accord de séquestre, une copie du code est détenue par un tiers indépendant et remise à l'opérateur uniquement si des événements définis surviennent, tels que la cessation d'activité du fournisseur ou son manquement à des obligations convenues. Le séquestre ne donne pas un accès quotidien au code, mais il protège la continuité : la plateforme ne devient pas impossible à maintenir du seul fait que le fournisseur n'est plus en mesure ou désireux de la supporter.

Les termes de support et de maintenance méritent le même examen que la concession de licence. Un opérateur qui possède le code mais n'a ni documentation, ni instructions de construction, ni aucun transfert de connaissances peut détenir un actif qu'il ne peut pratiquement pas maintenir. L'arrangement mûr traite la licence, la documentation et une période de support définie comme les parties d'une même acquisition, afin que l'opérateur puisse réellement faire avancer la plateforme plutôt que de posséder nominalement une chose qu'il reste incapable de modifier sans l'équipe d'origine.

Modèles de licence et périmètre d'usage

Les licences diffèrent aussi par leur structure et par le périmètre d'usage qu'elles autorisent. Une licence perpétuelle accorde le droit d'utiliser le code indéfiniment, généralement contre un paiement unique, tandis qu'une licence par abonnement ou à durée déterminée accorde l'usage pour une période définie contre un paiement récurrent. Au-delà de la durée, les licences fixent le périmètre de déploiement : combien d'environnements ou d'entités le code peut servir, s'il peut être utilisé pour une seule marque ou plusieurs, et si l'usage est confiné à l'opérateur ou s'étend aux sociétés qu'il pourrait ensuite acquérir ou créer.

Ces choix structurels portent des conséquences qui survivent à l'achat initial. Un opérateur prévoyant d'exploiter plusieurs marques, ou de s'étendre à de nouveaux marchés et entités, a besoin d'une licence dont le périmètre anticipe cette croissance plutôt que d'une licence tarifée et rédigée autour d'un déploiement unique. Aligner le modèle de licence et son périmètre sur les plans de l'opérateur, au moment de la négociation, évite l'alternative plus coûteuse d'une renégociation en position de faiblesse une fois la plateforme en production et centrale pour l'activité.

Attentes au Royaume-Uni et dans l'UE

Une licence ne se tient pas à l'écart des attentes réglementaires qui s'appliquent à l'échange. Au Royaume-Uni, les entreprises manipulant des cryptoactifs sont censées maintenir une résilience opérationnelle et démontrer qu'elles peuvent poursuivre leur activité malgré la défaillance d'un fournisseur, ce qui fait des clauses de continuité d'une licence, y compris tout séquestre, une question de résilience autant que de commerce. L'enregistrement au titre des Money Laundering Regulations est une porte d'entrée en matière de criminalité financière et non une autorisation complète, et le futur régime FSMA pour les cryptoactifs relève encore ces attentes.

Dans l'Union européenne, le cadre est stabilisé. La transition MiCA est terminée. Les nouveaux projets de cryptoactifs de l'UE doivent être conçus dès le départ pour un modèle d'exploitation de CASP agréé, et DORA fixe des attentes autour des dépendances technologiques envers des tiers qui touchent directement à la façon dont un accord de code source et de support est structuré. Nous ne fournissons pas d'avis juridiques et ne garantissons aucun agrément. Nous mettons en œuvre les exigences réglementaires et d'audit dans la technologie, l'infrastructure et l'exploitation. Une licence bien rédigée soutient la résilience opérationnelle et une propriété claire de la plateforme, mais elle ne satisfait aucune de ces obligations à elle seule ; la gouvernance, les enregistrements et la planification de la continuité qui l'entourent font d'une licence la preuve d'une exploitation maîtrisée.

Évaluer une licence

Les bons termes découlent de ce que l'opérateur entend obtenir de l'achat. Un opérateur en quête d'une véritable indépendance privilégiera la propriété ou une large licence perpétuelle, la modification sans restriction, un état clair des composants tiers et une protection de la continuité par séquestre ou transfert. Un opérateur satisfait d'une plateforme supportée pourra raisonnablement accepter des termes plus étroits en échange d'un engagement de support plus fort. L'erreur commune aux deux consiste à se concentrer sur la livraison du code et à traiter la licence comme une formalité type, alors que c'est dans la licence que se décide réellement la valeur de l'achat.

Les questions à poser à tout fournisseur en découlent. La propriété est-elle transférée, ou s'agit-il d'une licence d'usage, et si tel est le cas, est-elle perpétuelle ? Le code peut-il être modifié en interne ou par un tiers sans autorisation supplémentaire ? Quels composants tiers et open source sont inclus, et selon quels termes ? Un séquestre est-il disponible lorsque la propriété n'est pas transférée, et qu'est-ce qui en déclenche la remise ? Quelle documentation, quel support et quel transfert de connaissances accompagnent le code ? Pour une vue plus large de la façon dont ces questions s'inscrivent dans la décision de plateforme, les pages logiciel de plateforme d'échange crypto et conseil en architecture fintech offrent le contexte environnant.

Résumé et prochaines étapes

Les considérations sur la licence du code source déterminent ce qu'un opérateur acquiert réellement lorsqu'il achète le code d'une plateforme d'échange : propriété transférée ou usage concédé, ce qui peut être modifié et redistribué, quelles obligations tierces et open source voyagent avec le code, et comment la continuité est protégée par séquestre, support et transfert de connaissances. Deux livraisons identiques peuvent représenter des actifs très différents, et la différence se joue dans la licence plutôt que dans les fichiers. Lue et négociée de manière délibérée, avant la mise en production, la licence transforme un achat de code source en le contrôle durable qu'il est censé procurer. Les attentes propres à chaque région sont exposées sur les pages de préparation pour le Royaume-Uni et l'Union européenne.