Mon blog

Les règles de l'IETF concernant la publication des brevets sur les techniques en cours de normalisation ont déjà été violées plusieurs fois, par exemple par RIM. Deux RFC viennent donc d'être publiés pour traiter ce problème : un répressif, le RFC 6701, qui dresse la liste des sanctions possibles contre les tricheurs. Et un préventif, ce RFC 6702, qui expose tous les mécanismes à mettre en œuvre pour encourager tout le monde à respecter les règles. Pour le résumer : la principale (voire unique) méthode envisagée est de rappeler les règles au bon moment, de façon à augmenter les chances qu'elles soient lues.

Que disent ces règles, au juste ? Formulées dans le RFC 8179 et répétées en ligne, elles imposent, en substance, qu'un participant à l'IETF qui connait des revendications de propriété intellectuelle (typiquement des brevets) sur une technique en cours de normalisation doit en informer l'IETF (cela se fait en ligne), qui publiera alors ces revendications. C'est tout. L'IETF n'impose que cette transparence, qui permet ensuite aux groupes de travail de prendre des décisions en toute connaissance de cause (RFC 2026, section 10.4). Le but est d'éviter les brevets sous-marins, où une entreprise fait normaliser une technologie sur laquelle elle a des brevets, qu'elle ne révèle qu'après la publication de la norme, lorsqu'il est trop tard pour chercher une alternative. Pas étonnant que cette obligation de divulgation déplaise aux maneuvriers de l'appropriation intellectuelle. Au moins deux tricheries ont été détectées, une de RIM et l'autre de Huawei (dans le RFC 6468). La seconde a été la goutte d'eau qui a fait déborder le buffer et mené à ces deux RFC qui essaient de redresser la barre. Ils ne définissent pas de nouvelles règles : les anciennes s'appliquent comme avant, ces deux nouveaux RFC disent juste comment le faire.

À noter que, comme l'ont montré l'analyse de ces deux cas, il s'agissait de tricheries délibérées. Mais il y a aussi eu des cas où la négligence ou l'ignorance ont fait que les brevets n'étaient pas annoncés à l'IETF, ou bien l'étaient en retard. Ces deux RFC vont aussi servir pour le cas où la violation des règles s'est faite de bonne foi. Car, même commis de bonne foi, ce manque de divulgation d'un brevet peut avoir des conséquences fâcheuses : un groupe de travail qui ne connaissait pas un brevet risque de négliger une piste alternative, non plombée par des brevets.

En pratique, les méthodes suggérées dans ce RFC concernent surtout les personnes ayant un rôle dirigeant à l'IETF (RFC 2418 et RFC 3669) : président de groupe de travail, directeur de zone (ceux qui forment l'IESG), etc. Ce sont ces personnes qui ont la responsabilité de faire avancer proprement le processus.

La section 3 du RFC décrit les stratégies disponibles. Il s'agit essentiellement de mieux informer les participants à l'IETF pour éviter toute inattention... ou toute fausse excuse. S'appuyant sur les conseils du RFC 3669, les responsables peuvent :

• Rappeler les règles lorsqu'un Internet-Draft va être présenté à une réunion (le président d'un groupe de travail peut refuser la discussion si le présentateur ne confirme pas que les divulgations nécessaires n'ont pas été faites),
• Rappeler les règles au moment où un Internet-Draft va être adopté par un groupe de travail,
• Rappeler les règles avant de lancer des demandes solennelles comme le Working Group Last Call (le dernier tour de table avant qu'un Internet-Draft ne soit transmis par le groupe de travail à l'IESG) ou l'IETF Last Call (les outils qui génèrent le message envoyé à la liste ietf-announce@ietf.org incluent automatiquement un URL vers les divulgations de brevet pertinentes pour ce document),
• Au moment où le document est transmis à un Directeur de Zone, pour examen, le texte standard inclus une question sur les divulgations de brevet.

L'idée est qu'on a plus de chance de capter l'attention des distraits si on envoie le rappel au moment où les auteurs travaillent activement sur le document, pour lui faire franchir une étape. Quant aux gens de mauvaise foi, ils auront moins de possibilités de faire croire à une erreur (« je n'avais pas vu le rappel »). Voici un exemple d'un appel à un IETF Last Call (pour le document « TCP Extensions for Multipath Operation with Multiple Addresses ») :

Date: Wed, 01 Aug 2012 09:43:18 -0700
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Last Call: ...
...
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.
...
The following IPR Declarations may be related to this I-D:

   http://datatracker.ietf.org/ipr/1842/
   http://datatracker.ietf.org/ipr/1843/

La même chose s'applique aux soumissions individuelles (section 4).

Un petit piège : les règles de divulgation précisent que la divulgation doit être tenue à jour. Par exemple, si un brevet qui avait simplement été déposé est accepté, le texte de la divulgation doit être modifié (section 6). Ne pas mettre à jour une divulgation est aussi sérieux que de ne pas en faire.

Si jamais vous accédez à des responsabilités à l'IETF et que vous avez à procéder vous-même à ces rappels, vous pourrez être aidé par l'annexe A de ce RFC, qui contient des messages-types qu'il n'y a qu'à copier-coller.