L'appropriation intellectuelle est partout
et donc logiquement aussi dans
les organismes de
normalisation comme l'IETF.
C'est l'objet de ce RFC, qui remplace
les RFC 3979 et RFC 4879 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).
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 8179 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, vu 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.
Les principes sont donc :
- 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 délibérement 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 principale obligation
concrète de ce RFC 8179.
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 ». Outre le brevet
lui-même, il peut y avoir une licence associée (un droit d'utiliser la
technologie brevetée, sous certaines conditions). Si le détenteur du
brevet n'indique pas de licence, l'IETF peut poliment lui demander. La
licence (RAND, FRAND,
RANDZ - c'est-à-dire gratuite
…) sera évidemment un des éléments sur
lesquels les participants à l'IETF fonderont leur position (cf. RFC 6410).
La section 4
indique ce que l'IETF va en faire, de ces divulgations (nommées
« IPR [Intellectual Property Rights] disclosures ») : indication
du fait qu'il existe des brevets pouvant s'y appliquer et
publication de ces divulgations en http://www.ietf.org/ipr/. Par exemple,
Verisign a un brevet (brevet
états-unien 8,880,686,
et la
promesse de licence de Verisign)
qu'ils prétendent valable,
et dont ils affirment qu'il couvre la technique décrite dans le RFC 7816. (Sur la page officielle du
RCF, c'est le lien « Find IPR Disclosures from the IETF ».) L'IETF (ou
l'IAB, ou l'ISOC ou
autre) n'ajoutera aucune
appréciation sur la validité du brevet, ou sur les conditions de
licence. Une telle appréciation nécessiterait en effet
un long et coûteux travail juridique.
La note d'information n'est plus à inclure dans chaque RFC comme
c'était autrefois le cas. Elle est désormais dans le IETF Trust Legal Provisions
(version de
2015 : « The IETF Trust 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 any IETF Document or the extent to
which any license under such rights might or might not be available;
nor does it represent that it has made any independent effort to
identify any such rights. »). Comme exemple d'un brevet
abusif, on peut citer
la divulgation #1154, qui 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 10) car elles peuvent évoluer dans le temps alors que le RFC
est stable. Il faut donc aller voir ces « IPR
disclosures » en ligne sur http://www.ietf.org/ipr/.
Les divulgations sont-elles spécifiées plus en détail ? Oui, en
section 5. La 5.1 précise qui doit faire la
divulgation (le participant, en tant que personne physique), la
section 5.2 donne les délais (« aussi vite que possible »), la section
5.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
(« blanket disclosure »). 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 6 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 (« tu suis les
règles, ou bien tu ne joues pas »). Tout participant
à l'IETF est censé connaitre cette règle (section 3.3). 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 7 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.
Les règles de bon sens s'appliquent également : s'il s'agit de
faire une nouvelle version normalisée d'un protocole très répandu, on
évitera de choisir une technologie trop encombrée de brevets, s'il
s'agit d'un tout nouveau protocole expérimental, on pourra être moins regardant.
Les changements depuis les RFC précédents, les RFC 3979 et RFC 4879, sont décrits dans la
section 13. Pas de révolution, les principes restent les mêmes. Parmi
les changements :
- Texte modifié pour permettre l'utilisation de ces règles en
dehors de la voie IETF classique (par exemple par
l'IRTF).
- La définition d'une « contribution IETF » a été élargie pour
inclure, par exemple, les interventions dans les salles
XMPP de l'IETF.
- Meilleure séparation des questions de brevets (traitées dans
notre RFC) avec celles de droit d'auteur
(traitées dans le RFC 5378). Le terme de
« propriété intellectuelle » a plusieurs défauts, dont celui de
mêler des choses très différentes (brevets,
marques, droit d'auteur…)
- Il n'y a plus de
boilerplate (qui était en section 5 du RFC 3979) à inclure dans les documents, il est
désormais en ligne.
