Résumé

  • RFC 1602 demandait davantage qu’une promesse de bonne conduite : il imaginait un formulaire de licence exécutable, accessible en permanence aux implémenteurs, assorti d’une clause d’amélioration des conditions.
  • RFC 1915 autorisa une dérogation après une procédure publique et un Last Call prolongé. Cette autorisation remit en mouvement CCP et ECP, mais laissa les demandes, les prix et les délais dans des relations bilatérales difficiles à comparer.
  • La publication ultérieure de RFC 1962 et RFC 1968 prouve l’achèvement de textes de protocole. Elle ne prouve ni validité du brevet, ni licence obtenue, ni conformité d’un produit, ni déploiement, ni sécurité de bout en bout.

Deux documents qui ne font pas le même travail

Au milieu des années 1990, le groupe PPP avait transmis à l’IESG deux mécanismes de contrôle. CCP devait négocier la compression sur une liaison point à point ; ECP devait négocier son chiffrement. Leurs paquets décrivaient des capacités, des options et des remises à zéro. Ils ne pouvaient pas décrire le prix du droit d’utiliser un algorithme.

Motorola informa alors l’IETF que les brevets américains 5,245,614 et 5,130,993 pouvaient concerner ces travaux. RFC 1915 rapporte que la progression vers la normalisation s’arrêta. Cette pause est historiquement importante : un protocole peut être techniquement mûr tandis que son passage vers l’implémentation reste dépendant d’une autorisation extérieure au protocole.

Il faut donc conserver des colonnes séparées. Une revendication de brevet n’établit ni sa validité ni sa nécessité. Une assurance de licence n’est pas une offre reçue. Une offre n’est pas un contrat exécuté. Un contrat n’est pas la preuve qu’un produit est conforme ou qu’un réseau l’a déployé. Le mot « standard » ne peut absorber toute cette chaîne de décisions.

Ce que RFC 1602 voulait rendre commun

RFC 1602, alors en vigueur, proposait une architecture documentaire ambitieuse. Son modèle prévoyait des droits gratuits pour l’Internet Society dans le travail de normalisation et une licence accessible aux membres de la communauté qui souhaitaient mettre le standard en œuvre. Une clause devait améliorer les licences existantes si des conditions plus favorables étaient ensuite accordées à d’autres.

Surtout, le formulaire de licence devait demeurer disponible en ligne. L’implémenteur aurait pu lire le même texte de départ, le remplir et le remettre au titulaire pour qu’il prenne effet. Ce mécanisme ne décidait pas de la validité des brevets et n’abolissait pas tout désaccord. Il créait néanmoins un objet stable : une version, un périmètre, une voie d’exécution et une base de comparaison.

La stabilité d’un formulaire est une infrastructure discrète. Elle permet d’estimer un coût avant d’écrire trop de code, de détecter une nouvelle restriction et de demander pourquoi deux candidats ne semblent pas entrer par la même porte. Sans elle, le protocole demeure public mais l’accès économique à une technologie peut devenir une série de conversations privées.

La promesse acceptée par RFC 1915

Motorola ne souhaita pas publier le formulaire prévu. L’entreprise transmit plutôt une déclaration générale selon laquelle elle accorderait des licences à toute partie à des conditions raisonnables et susceptibles d’être démontrées comme exemptes de discrimination injuste. La déclaration nommait les brevets et un contact ; RFC 1915 la plaça dans le dossier public.

Ce geste avait une valeur réelle. Les responsables de la normalisation ne dépendaient plus d’une rumeur et les implémenteurs savaient à qui s’adresser. Mais sa portée était différente de celle d’un instrument exécutable. « Raisonnable » ne fournit aucun chiffre ; « non discriminatoire » ne peut être vérifié à partir d’une seule demande ; « disponible » ne fixe pas le temps de réponse.

RFC 1915 énonça lui-même la faiblesse. Des demandes différentes pouvaient recevoir des traitements différents : certaines accélérées, d’autres retardées. Une promesse publique avait donc remplacé une partie de la discipline du document commun, sans faire disparaître le risque que l’ouverture formelle du standard masque des accès pratiques inégaux.

Le détour technique n’était pas un consensus

Le groupe examina la possibilité de modifier les protocoles afin d’éviter les brevets allégués. Le détour était techniquement possible, mais plusieurs participants le jugeaient sensiblement inférieur. Certains annoncèrent même qu’ils implémenteraient la proposition CCP originale, quelle que soit la solution finalement normalisée. D’autres acceptaient le remplacement faute d’issue, et non parce qu’il représentait le meilleur choix d’ingénierie.

Une telle situation menaçait de séparer le standard écrit du code réellement utilisé. Conserver la règle de RFC 1602 gelait les documents ; contourner à tout prix la revendication pouvait produire une spécification sans adhésion opérationnelle. RFC 1915 choisit une troisième réponse : ne pas prétendre résoudre le litige technique ou juridique, mais autoriser la progression de la proposition originale sur la base de l’assurance datée du 5 juin 1995.

La dérogation comme discipline publique

RFC 1871 avait ajouté à RFC 1602 une procédure de variance pour les cas où les règles ne donnaient pas d’issue raisonnable. Le groupe responsable exposait le problème, l’IESG avançait une solution et un Last Call prolongé donnait à la communauté le temps de la contester. L’IESG devait évaluer le bénéfice pour Internet, le coût de la déviation, les solutions de rechange, le précédent créé et la possibilité de limiter l’exception. L’IAB pouvait entendre un appel.

Cette procédure empêchait que l’exception devienne une porte dérobée. RFC 1915 identifia la règle non respectée, publia l’assurance de remplacement et décrivit le risque résiduel. Elle constitue donc une excellente preuve de l’autorité effectivement exercée : l’IESG pouvait décider comment le processus IETF avancerait.

Elle ne donne pas à cette autorité une portée illimitée. L’IESG ne pouvait valider un brevet, négocier au nom d’une entreprise, comparer tous les contrats futurs ou garantir que le titulaire répondrait à chaque candidat dans le même délai. Le reçu procédural est précis justement parce qu’il ne se fait pas passer pour un reçu commercial.

La sortie du processus n’est pas la sortie du risque

En juin 1996, CCP parut sous le numéro RFC 1962 et ECP sous le numéro RFC 1968. Les textes définissaient la négociation, les états et les options. Ils prévoyaient aussi que des mécanismes propriétaires puissent être identifiés par une organisation. Une option publiée pouvait encore être soumise à des restrictions de licence ou d’exportation.

CCP pouvait continuer sans compression si aucune méthode commune n’était trouvée. Pour ECP, l’absence d’un chiffrement acceptable des deux côtés pouvait conduire à fermer la liaison. Les deux directions pouvaient même négocier des choix différents. La publication achevait un artefact de normalisation ; elle ne constatait pas que chaque chemin opérationnel était disponible.

RFC 1968 formulait en outre une limite de sécurité. La protection dépendait de l’algorithme choisi et de la garde des secrets, et une sécurité complète exigeait encore des mécanismes de bout en bout entre hôtes. Un protocole de chiffrement de liaison ne devait donc pas être présenté comme un verdict sur la sécurité d’un système entier.

Après RFC 1915, une autre politique

RFC 2026 remplaça RFC 1602 en octobre 1996. Il demanda toujours au Secrétariat de chercher une assurance écrite permettant à tous d’implémenter, d’utiliser et de distribuer la technologie selon des conditions publiées, raisonnables et non discriminatoires. Toutefois, le résultat de cette démarche ne devait généralement plus bloquer le standard. Le mécanisme détaillé du formulaire exécutable en ligne ne fut pas repris.

Le nouveau texte indiquait également que l’IESG ne déterminerait pas explicitement si le caractère non discriminatoire avait été réalisé en pratique. L’existence d’implémentations indépendantes et l’expérience opérationnelle pouvaient soutenir une présomption, toujours contestable pendant le Last Call.

La succession des dates établit un changement de politique ; elle ne prouve pas que RFC 1915 causa RFC 2026. Elle révèle plutôt une limite durable de la gouvernance technique : une institution peut demander une divulgation, publier une assurance, encadrer une exception et choisir l’état d’une spécification. Elle ne peut pas transformer par ce seul acte les négociations privées à venir en faits déjà observés.

Sources et limites de la preuve

Ces sources attestent les règles, les déclarations et les textes de protocole publiés. Elles n’attestent pas la validité ou la nécessité des brevets, ne révèlent pas les conditions de chaque négociation et ne prouvent pas qu’un produit précis fut licencié, conforme, interopérable, déployé ou sûr de bout en bout.