Mon blog

L'appropriation intellectuelle est partout aujourd'hui (je recommande d'ailleurs l'excellent article du Monde Diplomatique pour une analyse en profondeur de ce phénomène) et donc logiquement aussi dans les organismes de normalisation. Même l'IETF, traditionnellement un rassemblement de gros barbus qui savent programmer en assembleur mais ne connaissent rien au droit, a dû évoluer. C'était l'objet de ce RFC, qui mettait à jour le RFC 2026 sur les questions de brevets (nommées, à tort, questions de « propriété intellectuelle », alors que les brevets ne sont pas la même chose que les copyrights, traités dans le RFC 5378). Lui-même a été remplacé depuis par le RFC 8179.

Donc, sur quels principes repose la politique de l'IETF au sujet des brevets ? L'idée de base est de s'assurer que l'IETF disposera d'information sur les brevets pouvant s'appliquer à une norme donnée, de façon à pouvoir prendre une décision en toute connaissance de cause. Il n'y a par contre pas de mécanisme automatique de décision, par exemple « Ne jamais normaliser des technologies brevetées ». En effet, compte-tenu du fait que l'écrasante majorité des brevets logiciels est futile, enregistrée uniquement parce que les organismes de brevetage ont un intérêt financier à accepter tout et n'importe quoi, une telle politique mènerait à ne rien pouvoir normaliser.

En pratique, tout ce RFC 3979 pourrait donc se résumer à « Tout participant à l'IETF qui connait ou devrait connaitre un brevet pouvant s'appliquer à une technique en cours de discussion doit en informer l'IETF ». C'est tout. Mais il y a quelques détails pratiques.

D'abord, il faut rappeler que ce sont officiellement des individus qui participent à l'IETF, pas des sociétés. Donc l'obligation s'applique à ces individus et ils ne peuvent pas y échapper en prétendant que leur compagnie leur interdit de réveler un brevet sous-marin (brevet sur lequel on fait peu de publicité, pour le ressortir une fois que la technique brevetée a été largement adoptée). Ensuite, le RFC définit ce que signifie contribuer à l'IETF (section 1). Par exemple, écrire sur une liste de diffusion d'un groupe de travail est une contribution. Cette règle est régulièrement rappelée par le fameux Note Well.

La section 1 définit formellement bien d'autres choses. Un concept essentiel mais souvent oublié est le Reasonably and personally known. Il désigne une information que le participant connait ou devrait connaitre, vue sa position dans l'entreprise qui l'emploie. L'idée est que le participant IETF n'est pas obligé de chercher activement dans le portefeuille de brevets de son entreprise, que l'obligation ne s'applique qu'à ce qu'il connait forcément, depuis son poste. Le but de l'ajout reasonably est d'éviter qu'une entreprise ne dissimule un brevet à ses propres employés.

Le RFC sur le mécanisme de l'IETF, le RFC 2026, dans sa section 10, exposait déjà les principes de gestion des brevets. Le RFC 3979 le met à jour uniquement en clarification, les principes restent les mêmes :

• L'IETF ne va pas chercher à déterminer si un brevet est futile ou pas (cela peut être un très gros travail, la plupart des brevets étant rédigés en termes incompréhensibles),
• L'IETF peut normaliser ou pas une technique brevetée, il n'y a pas de refus systématique,
• Pour pouvoir néanmoins savoir où on va, l'IETF a besoin d'information et c'est de là que découle l'exigence de divulgation des brevets.

La section 3 rentre dans le concret, même si elle commence par un bel exercice de langue de bois (« The intent is to benefit the Internet community and the public at large, while respecting the legitimate rights of others. »). C'est elle qui impose que le contributeur à l'IETF ait bien divulgué tous les brevets qu'il connaissait « raisonnablement ». La section 4 indique ce que l'IETF va en faire, de ces divulgations : indication dans le RFC du fait qu'il existe des brevets pouvant s'y appliquer et publication de ces divulgations en http://www.ietf.org/ipr/. L'IETF n'ajoutera aucune appréciation sur la validité du brevet, ou sur les conditions de licence (section 4.1). Une telle appréciation nécessiterait en effet un long et coûteux travail juridique. Cette section 4 a fait l'objet d'une légère clarification ultérieure dans le RFC 4879.

La note à inclure dans le RFC est précisée en section 5. Tirée d'un RFC réel, le RFC 5336, voici un exemple :

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; 
...

Quel est exactement le brevet que pourrait enfreindre ce RFC ? Le moteur de recherche des divulgations nous apprend qu'il n'y a pas de divulgations directement liées à ce RFC mais qu'il en existe pour des RFC dont il dépend (comme la #1000, futile et due à un patent troll connu). Autre exemple, plus grave, la divulgation #1154 se réclame d'un brevet sur les courbes elliptiques qui s'appliquerait à tous les RFC parlant d'un protocole qui peut utiliser ces courbes, comme le RFC 5246.

Les divulgations ne sont pas incluses dans les RFC eux-mêmes (section 11) car elles peuvent évoluer dans le temps alors que le RFC est stable. Il faut donc aller voir sur http://www.ietf.org/ipr/.

Les divulgations sont-elles spécifiées plus en détail ? Oui, en section 6. La 6.1 précise qui doit faire la divulgation (le participant, en tant que personne physique), la section 6.2 donne les délais (« aussi vite que possible »), la section 6.4.3 rappelle que la divulgation doit être précise et qu'un contributeur ne peut pas se contenter de vagues généralités. Le tout est aussi mis en ligne, en http://www.ietf.org/ipr-instructions.

Et si un tricheur, comme la société RIM, ne respecte pas cette obligation de divulgation ? La section 7 ne prévoit aucune dérogation : si, par exemple, une société empêche ses employés de divulguer les brevets, ces employés ne doivent pas participer à l'IETF. Le RFC 6701 liste les sanctions possibles contre les tricheurs et le RFC 6702 expose comment encourager le respect des règles.

Bien, donc, arrivé là, l'IETF a ses informations et peut prendre ses décisions. Sur la base de quelles règles ? La section 8 rappelle le vieux principe qu'une technique sans brevets est meilleure ou, sinon, à la rigueur, une technique où le titulaire des brevets a promis des licences gratuites. Mais ce n'est pas une obligation, l'IETF peut choisir une technologie brevetée, même sans promesses sur la licence, si cette technologie en vaut la peine.

La seule exception concerne les techniques de sécurité obligatoires : comme tout en dépend, elles ne doivent être normalisées que s'il n'existe pas de brevet ou bien si la licence est gratuite.

Je rappelle que ce RFC n'est plus d'actualité, il a été remplacé par le RFC 8179.