Mon blog

Pendant longtemps, l'IETF a vécu avec l'illusion qu'elle était une organisation purement technique, vouée uniquement à produire les meilleures normes possibles, sans considération pour les questions « vulgaires » comme le droit. Désormais, l'IETF est rattrapée par la judiciarisation croissante de la société, surtout aux ÉUA, où se trouve la majorité des structures formelles qui comptent pour l'IETF (notamment l'ISOC, l'IETF elle-même restant informelle et non enregistrée). Avec l'enthousiasme des néophytes, une partie de l'IETF s'est donc engagée dans la voie d'un travail sur les questions de propriété intellectuelle (un terme d'ailleurs très contestable, puisque mêlant des choses aussi différentes que le droit d'auteur, les brevets et le droit des marques). Ce RFC décrit les « droits entrants », c'est-à-dire ceux dont l'IETF a besoin, et qui doivent lui être accordés par les participants aux travaux et notamment par les auteurs de RFC (la convention de Berne faisant que les auteurs ont automatiquement certains droits sur leur œuvre).

Si des notions de « propriété intellectuelle » apparaissaient déjà dans le RFC 2026 en octobre 1996, le premier RFC fournissant un cadre complet à ces questions a été le RFC 3667 en février 2004, remplacé par le RFC 3978 puis par notre RFC 5378. Le principal changement (section 10) est la séparation plus claire entre les droits « entrants » (ce que le contributeur donne à l'IETF) et les droits « sortants » (ce que l'IETF donne aux utilisateurs), décrits dans le RFC 8721.

Ce dernier RFC, écrit par un « grand ancien » de l'IETF (dont l'activité récente est essentiellement consacrée aux questions de propriété intellectuelle) et un avocat (qui, logiquement, pousse toujours l'IETF vers davantage de judiciarisation), est donc la version actuelle de la politique de l'IETF. Il détaille les droits que les contributeurs (participants au processus IETF) doivent transmettre à l'IETF trust, l'organisme (largement indépendant de l'IETF et étroitement contrôlé par l'ISOC et CNRI) qui est censé administrer la propriété intellectuelle de l'IETF (voir RFC 4748).

L'IETF trust ne peut en effet pas donner aux utilisateurs des RFC des droits qu'il n'a pas lui-même reçu. Pour pouvoir distribuer un RFC, le traduire, ou en extraire des parties, les droits automatiquement donnés par l'auteur (comme le droit de citation ou comme le fair use) ne suffisent pas. Il faut que les auteurs donnent explicitement davantage de droits.

La section 5 décrit les droits en question. 5.3 porte sur les droits donnés à l'IETF trust : droits de publication (évidemment), de traduction, d'utilisation des marques que contient le document, etc. 5.5 explique que ces droits n'impliquent pas de licence d'utilisation des technologies présentées dans le RFC (l'IETF, contrairement au W3C ou, dans certains cas, à OASIS, accepte de normaliser des technologies brevetées).

Pour que tout le monde puisse connaître ses droits, la section 6 explique le mécanisme de publication de ceux-ci par le biais d'un boilerplate, officiellement appelé legend. Ce boilerplate, un texte légal attaché à chaque RFC, ne figure pas dans notre RFC 5378. En effet, l'évolution des lois états-uniennes, les changements d'interprétation, peuvent nécessiter une évolution du texte, alors qu'un RFC n'est pas facile à changer. L'IETF trust reçoit donc un quasi-chèque en blanc pour rédiger le texte en question et le tenir à jour sur son site Web (c'est le second grand changement par rapport au RFC 3978).

La section 3 du RFC explique le raisonnement derrière les choix effectués (on peut aussi consulter la FAQ du trust). Par exemple, 3.3 explique que l'auteur doit donner le droit de faire certaines modifications (derivative works) car l'IETF doit pouvoir faire évoluer le RFC suivant l'évolution de la technologie. Elle explique aussi pourquoi cette règle peut comporter des exceptions, par exemple lorsque l'IETF re-publie sous forme de RFC une norme d'une autre organisation.

Comme le travail a été plutôt bâclé, un gros problème n'est survenu que plus tard lorsque des auteurs se sont aperçus que le nouveau texte interdisait de réutiliser du texte d'anciens RFC... La chasse aux auteurs de ces anciens RFC a donc commencé, pour les convaincre d'abandonner leurs droits (voir l'article IETF Shoots Itself in the Foot).