Résumé

  • En octobre 2001, le groupe de travail du W3C sur les brevets n’avait pas tranché entre une voie sans redevance et une possibilité de licences RAND. Le désaccord portait sur les conditions d’implémentation d’un standard et sur le risque de voir des brevets bloquants surgir après des années de travail.
  • Approuvée le 21 mai 2003, la politique visait à rendre les Recommandations implémentables sous licence RF. L’engagement concernait les revendications essentielles liées au travail d’un groupe précis, pas tous les brevets d’un membre ni toutes les technologies du Web.
  • Le texte associait cet engagement à la divulgation, à des périodes limitées d’exclusion et à un groupe consultatif chargé des conflits. Une dérogation restait possible, mais seulement après examen des autres solutions et de nouvelles étapes de revue.

Le débat dépassait le seul titulaire du brevet

Un standard du Web doit pouvoir être repris par des équipes qui ne se connaissent pas et par des entreprises qui se concurrencent. Si une partie nécessaire de la spécification suppose de négocier un prix ou d’accepter des conditions incertaines, l’interopérabilité devient moins prévisible. Le W3C a donc cherché à traiter le risque de brevet avant qu’une Recommandation ne devienne un point de référence partagé.

Le débat n’opposait pas simplement les brevets à leur absence. Le projet de 2001 envisageait un mélange de licences RF et RAND. Lors de sa réunion d’octobre 2001, le groupe de travail a consigné deux positions. Les partisans d’une règle RF craignaient que des frais pèsent sur la distribution des logiciels, compliquent les implémentations libres et brouillent le statut des spécifications. Ceux qui voulaient garder une option RAND estimaient qu’écarter une technologie disponible seulement contre paiement pouvait forcer un groupe à abandonner une solution utile ou à déplacer son travail. Le groupe ne parvint pas à une position unanime.

Les comptes rendus relèvent aussi une inquiétude de la communauté des développeurs : une évolution de politique pouvait entamer la confiance envers le processus du W3C. Il s’agissait d’une question de gouvernance. Les membres et les participants publics débattaient de la règle adaptée aux futures Recommandations, tandis que le Directeur et les membres du W3C conservaient des rôles formels dans la décision.

En 2003, la licence RF devient la voie de référence

Le 21 mai 2003, le W3C annonça que son Directeur avait approuvé la politique après soutien des membres, accord du groupe de travail et commentaires publics favorables. Son objectif était de permettre l’implémentation sans redevance des Recommandations produites sous ce régime. Les participants aux groupes de travail s’engageaient à proposer sous licence RF les revendications essentielles liées aux travaux de leur groupe, dans les limites du texte.

L’adhésion au W3C ne suffisait pas à créer cet engagement : la politique exigeait de rejoindre un groupe de travail ou d’accepter autrement ses conditions. Il ne portait que sur les revendications détenues par le participant ou qu’il avait le droit de licencier sans devoir de paiement envers un tiers indépendant ; les experts invités n’étaient responsables que des revendications qu’ils contrôlaient. La définition d’une revendication essentielle était étroite. Elle devait nécessairement être enfreinte pour mettre en œuvre les parties normatives d’une Recommandation, sans solution alternative non contrefaisante.

Les éléments non normatifs, les technologies d’activation non spécifiées et les technologies incorporées par référence en étaient exclus.

La divulgation complétait l’engagement de licence. Une organisation membre devait signaler un brevet potentiellement essentiel lorsqu’une personne concernée en avait connaissance effective et recevait une demande dans le cadre de la politique. Le W3C n’exigeait pas de recherche de brevets. Les informations divulguées devaient devenir publiques au fil de la progression des documents vers une Recommandation. Cela créait une trace consultable, sans garantir que chaque revendication possible avait été découverte.

Les exclusions et les exceptions délimitaient la promesse

Le texte n’exigeait pas l’abandon d’un portefeuille entier. Un participant pouvait identifier et divulguer certaines revendications essentielles qu’il refusait de licencier, pendant une période liée à la publication du premier projet de travail public. Il pouvait rester dans le groupe après cette exclusion. Des fenêtres ultérieures couvraient, sous conditions, de nouveaux éléments. Le calendrier devenait ainsi un mécanisme de contrôle : le contributeur disposait d’un délai pour préciser ce qu’un projet rendait essentiel ; les autres pouvaient en évaluer les limites avant la publication de la Recommandation.

Si une revendication divulguée n’était pas disponible sous licence RF, un groupe consultatif sur les brevets pouvait examiner le conflit. Il pouvait demander une analyse, concevoir une solution de contournement, supprimer la fonction concernée ou arrêter les travaux. Ce n’est qu’après avoir essayé ces options qu’il pouvait proposer d’inclure une technologie identifiée sous d’autres conditions. Il devait justifier pourquoi les objectifs du groupe ne pouvaient être atteints autrement, détailler les revendications et les termes proposés, puis passer par une consultation publique, l’examen du Comité consultatif et une décision du Directeur.

Le W3C présentait cette voie comme étroite et réservée aux situations inattendues.

La promesse RF avait donc une limite et un chemin d’échec explicites. Un problème tardif pouvait encore entraîner une refonte, un retard, un retrait ou une exception rare. La procédure ne supprimait pas l’incertitude ; elle rendait davantage de ses éléments visibles avant que le standard ne devienne une infrastructure.

Ce que la politique ne réglait pas

La politique de 2003 encadrait les brevets dans la production de Recommandations du W3C relevant de ce régime. Elle n’établissait pas que toutes les technologies du Web étaient libres de brevets, ne garantissait pas l’absence de coûts pour chaque implémenteur et ne réglait pas les droits sans rapport avec la spécification. L’objectif déclaré par le W3C ne mesure pas non plus l’effet de la politique sur l’adoption.

La version du 5 février 2004 précise que les changements par rapport au texte du 20 mai 2003 concernaient les liens vers le Process Document et un détail administratif permettant d’envoyer des divulgations autrement que par courriel. Il faut donc distinguer la décision de 2003 des retouches ultérieures.

Cette histoire montre comment un organisme de normalisation a réparti l’autorité autour d’une règle technique partagée. L’engagement était lié à la participation à un groupe donné ; les revendications et exclusions devaient être plus visibles ; une voie exceptionnelle restait possible si le conflit menaçait les objectifs du groupe. La licence RF était une condition à poursuivre, pas une promesse effaçant tous les brevets et tous les désaccords.

Sources : annonce d’approbation du W3C en 2003 ; texte de la politique du 20 mai 2003 ; compte rendu du groupe de travail d’octobre 2001 ; projet de politique de 2001 ; FAQ du W3C de 2003 ; politique du 5 février 2004.