R. Braden (ISI)J. Halpern (Ericsson)December20092009-12-18
L'infrastructure juridique des « nouveaux »
RFC, désormais répartis en plusieurs voies selon
leur source, continue à se mettre en place. Ce
décrit les procédures pour les droits liés aux RFC soumis par la voie
« indépendante » (RFC soumis par un individu, ni
l'IAB, ni un groupe de travail de
l'IETF). Actuellement, il existe des dizaines
de documents approuvés techniquement, qui attendent dans la file du
RFC
Editor car ils ont été soumis par cette voie et son
statut n'a pas été clarifié depuis le déploiement des « nouveaux » RFC
(). Sans doute vont-ils enfin être
publiés mais on ne sait pas encore quand.
C'est que la publication d'un RFC, acte essentiellement technique
au début, est devenue une grosse affaire juridico-politique. Des
centaines de pages de discussions juridiques ont été noircies sur les
problèmes de droits donnés par les auteurs (incoming
rights, cf. ) et les droits
(forcément inférieurs ou égaux) que reçoivent les lecteurs
(outgoing rights, cf.). Ces deux derniers RFC ne concernaient que les
documents produits par l'IETF et, depuis, les documents produits par
des individus languissaient sans statut et ne pouvaient être publiés.
Après tant de débats, il est ironique de constater que la procédure
pour les RFC « indépendants » est
finalement très proche de celle des RFC « IETF ».
Pour se saisir du contexte, la section 2 de notre
rappelle que le systèmes des voies (streams) a été
défini dans les (et ,
spécifiquement pour la voie indépendante). Cette dernière est une
vieille tradition, et permet de publier des RFC qui sont proposés par
des individus isolés, ou bien qui ont rencontré le veto de certaines
parties à l'IETF (comme le ). Tout RFC
n'est donc pas le produit d'un groupe de travail IETF.
Depuis le , qui « éclatait »
l'ancienne fonction de RFC Editor, la responsabilité des RFC
soumis par voie indépendante revient au Independent Stream
Editor, qui ne sera finalement désigné qu'en février 2010.
La section 3 pose les buts des nouvelles règles. Reprenant la
politique traditionnelle, suivie informellement depuis l'époque de
Jon Postel, elle pose comme principe que
l'utilisation des RFC doit être la plus libre possible
(« Unlimited derivative works »). Toutefois, tous
les RFC de la voie indépendante ne sont pas équivalents. Certains sont
des republications de documents édités ailleurs (par exemple par
d'autres SDO) et les auteurs ont donc la
possibilité de demander des restrictions supplémentaires. À noter que
ces principes s'appliquent également au code
inclus dans les RFC.
Enfin, les règles formelles elle-mêmes, en section 4. La procédure
est proche de celle des autres RFC, l'auteur devant donner certains
droits pour permettre la publication (par défaut, il donne presque
tous les droits, en gardant évidemment l'attribution de son
travail). Les termes exacts (le boilerplate) seront fixés par l'IETF Trust.
Le respect de la procédure par l'auteur ne préjuge pas de
l'adoption du RFC. L'éditeur de la voie indépendante, l'ISE, reste
seul juge de l'intérêt de publier le RFC. Le choix d'un auteur de ne
pas permettre la réutilisation du RFC
(« no derivative worlks ») peut, par exemple, être
motif de rejet.
L'implémentation de cette politique nécessite une action de la part
de l'IETF Trust, décrite en section 5. Celui-ci
devra accepter la responsabilité de la gestion des
droits de propriété intellectuelle pour ces RFC « indépendants » et
devra écrire les termes exacts qui seront inclus dans
chaque RFC.
Quant aux questions de brevets et de
marques déposées, elles sont réglées dans la
section 6. Les règles des et s'appliquent aux RFC de la voie indépendante
comme aux autres : toute prétention de propriété intellectuelle
doit être déclarée, de façon à ce que l'ISE
puisse décider en toute connaissance de cause (notez bien qu'en
pratique, cette règle est parfois
violée). Comme d'habitude à l'IETF, il n'y a pas d'a priori sur
les conditions de licence des brevets (tout est théoriquement
possible) mais notre RFC précise que les termes de licence les plus
favorables possibles seront privilégiés, notamment des licenses
gratuites, voire implicites.