Résumé

  • Depuis la RFC 2026 en 1996, la politique de l’IETF a traité les informations relatives à la propriété intellectuelle comme une donnée d’entrée pour un choix technique éclairé, sans demander à l’IETF de déterminer la validité des brevets. La BCP 79 actuelle, RFC 8179, exige les divulgations pertinentes dès que raisonnablement possible, lie les obligations aux entités, employeurs et sponsors, et encourage une divulgation préliminaire avant qu’une contribution ne soit formellement faite.
  • Le moment change la substance. Une revendication divulguée avant l’adoption par un groupe de travail peut être comparée à des alternatives; la même revendication divulguée après le dernier appel ou le déploiement peut bloquer les travaux de conception, les implémentations, les achats, la formation et les engagements d’interopérabilité. Les RFC 3669, 6701 et 6702 reconnaissent explicitement qu’une divulgation tardive peut forcer une refonte, retarder la publication, faire dérailler les travaux et menacer les équipements déployés.
  • Une publication formelle ne suffit pas. Les implémenteurs ont besoin d’un enregistrement consultable par projet et version, RFC, titulaire du brevet et filiales contrôlées, famille de brevets, section concernée, date de divulgation et de mise à jour, posture de licence et historique de remplacement. L’absence de résultat ne doit jamais être présentée comme une assurance qu’aucun droit pertinent n’existe, car l’IETF n’effectue aucune recherche de brevet et des tiers peuvent divulguer ultérieurement.

Le consensus est aussi un calendrier d’investissement

Le consensus approché est généralement décrit comme une méthode pour résoudre les objections techniques. C’est aussi une séquence d’investissements. Avant qu’un groupe adopte un projet, les entités passent du temps à comparer les énoncés de problèmes et les architectures. Après l’adoption, les éditeurs intègrent le texte et les relecteurs se concentrent sur une seule direction. Les implémenteurs écrivent du code, les événements d’interopérabilité testent les hypothèses et les opérateurs commencent à anticiper le déploiement.

Les équipes produit peuvent affecter du personnel, réserver du matériel, négocier des dépendances et définir des plans de publication.

Chaque étape réduit la liberté pratique de choisir à nouveau. Une alternative rejetée tôt peut encore exister sur le papier, mais ses auteurs peuvent être partis. L’infrastructure de test peut maintenant supposer la conception choisie. Les interfaces de code se solidifient autour des formats de paquets et des machines d’état. L’analyse de sécurité s’accumule. D’autres groupes de travail créent des dépendances. La supériorité technique apparente de la proposition sélectionnée devient en partie un produit de l’investissement réalisé après la sélection.

... (the rest of the article)