Navigation – Plan du site
Dossier thématique
Partie 2

Les standards ouverts et la normalisation comme conditions de l’interopérabilité logicielle

Ladislas Goffinet
p. 165-176

Résumé

Dans cette courte contribution, l’auteur aborde la question des standards techniques comme conditions à l’interopérabilité dans le domaine du logiciel. Dans une première partie, il précise la terminologie relative aux caractéristiques des formats et protocoles informatiques. Ces caractéristiques portent sur des questions de fait – plus ou moins d’information – et des questions juridiques – plus ou moins de droits – et influent sur l’interopérabilité. La portée du concept de standard ouvert est également précisée, au regard des textes réglementaires européens, français et belges. Dans une deuxième partie, les politiques des principaux organismes de normalisation en matière de propriété intellectuelle sont examinées. L’auteur y relève les convergences et les divergences de vue à ce sujet, et leur compatibilité avec l’exigence de standards ouverts.

Haut de page

Texte intégral

Introduction

1Le mot « interopérabilité » est devenu, ces dernières années, un mot magique. Chacun le découvre dans sa discipline propre : le droit de la concurrence voit apparaître l’interopérabilité comme un nouveau critère dans les affaires d’abus de position dominante ; les associations de défense du consommateur en font un nouveau droit du consommateur ; les systèmes d’e-government et d’e-justice le posent comme condition sine qua non aux fournisseurs ; les experts de la propriété intellectuelle voient se dérouler une lutte fascinante entre l’exercice des droits intellectuels et l’exigence croissante d’interopérabilité.

2Sans aucun doute, la notion est fondamentale, et participe au succès, pour prendre l’exemple le plus connu, d’Internet, plate-forme interopérable s’il en est, car basée sur des protocoles et des formats qui n’appartiennent à personne, et donc appartiennent à tous. Elle permet de lutter contre les avantages indus que peut obtenir le leader d’un marché en imposant son format ; elle donne à chacun l’accès à l’information et à la culture, sans discrimination.

3Ces formats et protocoles sont la pierre d’angle de l’existence, ou de l’absence, de cette interopérabilité : ils constitueront donc l’objet de cette étude. Nous tenterons tout d’abord de cerner les qualités diverses – factuelles et juridiques – que ces données techniques peuvent avoir et, en particulier, ce que sont les « standards ouverts », si nécessaires, semble-t-il, à l’interopérabilité. Ensuite, nous examinerons la politique des différents organismes de normalisation vis-à-vis de la propriété intellectuelle, et son implication dans la question des standards ouverts.

4Nous tenons à préciser que l’ensemble de notre propos porte sur l’interopérabilité logicielle, dont le régime semble bien distinct de celui de l’interopérabilité physique (chemins de fer, connectivité physique des réseaux…), en particulier du fait de la plus grande modularité du numérique.

1. Standards et formats ouverts

1.1 Concepts

  • 1 Comme exemples de protocole, citons : le HTTP (protocole web), le SMTP (protocole de courriel), l’I (...)
  • 2 Comme exemples de formats : HTML (page web), PDF (documents d’impression), MPEG, WMA/ WMV et Theora (...)

5La quête de l’interopérabilité nécessite l’accès à un certain nombre d’informations techniques. Ces informations sont souvent désignées sous le terme générique d’« interfaces », concept couvrant les zones d’interaction entre différents éléments (systèmes, données, machine physique, être humain…). Dans un réseau de communication, les interfaces logicielles (au-delà des interfaces physiques) sont appelées des « protocoles1 ». Lorsqu’il s’agit d’interfaces entre un programme et des données, on parle de « formats2 ». Ces protocoles et formats peuvent être ouverts ou fermés, propriétaires ou libres, normalisés ou non. Pour simplifier notre propos, nous utiliserons par la suite – de manière un peu abusive, il est vrai – le vocable format pour parler des deux types d’informations relatives aux interfaces.

Formats ouverts ou fermés

6Cette première distinction est initialement simple : un format est dit « ouvert » quand ses spécifications – les informations techniques nécessaires à sa mise en œuvre – sont publiquement disponibles, et « fermé » lorsque ces informations sont gardées secrètes par une ou plusieurs entreprises. Il s’agit avant tout d’une question de secret, et non de droit. Nous le verrons, l’appellation « standard ouvert » présente dans de nombreux textes règlementaires implique généralement des exigences plus grandes. Pour cette raison, on trouve parfois l’adjectif « documenté » pour qualifier un format ou un protocole ouvert au sens strict.

7L’avantage pour une entreprise de garder les spécifications secrètes réside dans la capacité à ne livrer qu’une partie des informations à ses concurrents, se réservant des fonctions clés qui lui permettront de faire de son produit ou de son service le mieux conçu aux yeux des utilisateurs

Formats libres ou propriétaires

  • 3 Nous n’entrerons pas ici dans le débat sur la brevetabilité des logiciels, tenant pour donnée cette (...)

8On entre avec la distinction libre/propriétaire dans le champ du droit. Les définitions traditionnelles du logiciel libre et de l’open source s’inscrivent dans le cadre du droit d’auteur, mais les protocoles et formats peuvent être aussi protégés par des brevets.3 Un format libre est, dans le sens général, un format librement implémentable par chacun, sans restrictions juridiques – soit que la protection au titre du droit d’auteur ou du brevet ne s’applique pas, soit qu’une licence générale et non exclusive soit accordée.

  • 4 Voy, par exemple le cas de la distribution GNU/Linux Ubuntu, logiciel libre, sur https://help. ubun (...)

9À l’inverse, un format propriétaire est un format sur lequel une ou plusieurs personnes, physiques ou morales, se réservent des droits de propriété intellectuelle, pour monnayer leur autorisation ou s’octroyer un monopole d’utilisation sur ces technologies. L’exigence de conditions RAND – pour reasonable and non discriminatory – posée par un certain nombre d’organismes de normalisation n’ôte pas le caractère propriétaire d’un format : tout au plus, le titulaire de droit voit sa marge de manœuvre restreinte, ne pouvant se réserver l’utilisation exclusive de l’œuvre ni privilégier quelques autres acteurs. Les conditions de licences, même RAND, demeurent bien souvent un frein au support de formats et protocoles dans des projets de logiciel gratuit ou libre4.

Standards et normes

10Le terme de « standard » est parfois utilisé de manière abusive, se référant à tout format ou protocole. Or, il nous semble important de signaler que la première caractéristique d’un standard est celle d’être largement utilisé dans un but précis, de manière à créer un référentiel commun, ce qui exclut un format utilisé de manière confidentielle. On peut distinguer parmi les standards deux principales catégories : les standards de fait et les standards de droit.

  • 5 Les spécifications de ces formats ont longtemps été secrètes, mais sont disponibles depuis février 2 (...)

11Un « standard de fait » est un référentiel s’imposant de manière spontanée dans un marché donné. Il n’est pas nécessairement ouvert, ni libre : si le logiciel l’implémentant est largement majoritaire, cela suffit à en faire un standard de facto. Un fameux exemple de standard de fait, bien que fermé, est l’ensemble des formats de document de la suite Microsoft Office, et en particulier le format Word (fichiers se terminant en. doc)5.

  • 6 En anglais, standard signifie tout à la fois norme et standard, ce qui conduit parfois à une confusi (...)
  • 7 Voy. A. Gupta, « Are open standards a prerequisite to open source?: a perspective in light of techn (...)

12Un « standard de droit », également appelé « norme6 », est un référentiel établi par une autorité de normalisation reconnue – publique ou privée, nationale ou internationale – comme l’ISO, l’IETF, le W3C ou la CEN, pour en citer quelques-unes des plus importantes.7

1.2 Interaction entre les différentes notions

13Comme déjà évoqué, un certain nombre de corrélations existent entre ces différentes caractéristiques : un format libre est nécessairement ouvert, un standard de droit l’est également, mais un format ouvert (au sens documenté) ou une norme peuvent être propriétaires et soumis à redevance. Un bel exemple d’évolution est le format PDF, visant au formatage de documents prêts pour l’impression et lisibles sur toutes les plates-formes en respectant la mise en page.

14La société américaine Adobe Systems a commencé à le développer au début des années 1990 ; progressivement, elle a fourni des spécifications permettant la prise en charge du format par des éditeurs tiers, faisant du PDF un format ouvert. De ce fait, le format s’est répandu comme référence pour la fourniture, l’échange et l’archivage de documents définitifs, devenant un standard de fait. Avec sa normalisation par l’ISO sous le numéro ISO 32000-1 en juillet 2008, il est devenu un standard de droit. Est-il libre ? Adobe détient un certain nombre de brevets liés au format, mais accorde une licence gratuite à tous les développeurs de logiciels visant à écrire ou à lire des documents PDF8.

1.3 « Standard ouvert » dans les textes réglementaires

15Avec l’avènement de l’e-government, les pouvoirs publics se sont attachés ces dernières années à prévoir l’utilisation de standards ouverts. Dans les différents textes officiels – lois, arrêtés, cadres d’interopérabilité –, cette dénomination désigne le plus souvent un format ouvert, normalisé, mais également libre.

  • 9 Loi du 10 août 2005 instituant le système d’information Phenix, M.B., 1er septembre 2005, art. 30.

16Par exemple, la loi belge Phenix du 10 août 2005 définit en son article 30 les concepts de standard – qui est ici synonyme de norme – et de standard ouvert : « Par standard ouvert, on entend un standard qui soit gratuitement disponible sur l’internet et sans restriction juridique quant à sa diffusion et son utilisation9. »

  • 10 Loi n° 2004-575 du 21 juin 2004 pour la confiance dans l’économie numérique, art. 4.

17De même, la loi française pour la confiance dans l’économie numérique donne une définition similaire en son article 4 : « On entend par standard ouvert tout protocole de communication, d’interconnexion ou d’échange et tout format de données interopérable et dont les spécifications techniques sont publiques et sans restriction d’accès ni de mise en œuvre10 . »

18Dans le cadre de son programme IDABC (pour Interoperable Delivery of european e-government services to public Administrations, Businesses and Citizens)11, la Commission européenne a publié un cadre européen d’interopérabilité12, encourageant l’utilisation de standards ouverts, et établissant les conditions minimales exigées pour mériter cette appellation :

  • Le standard a été adopté et sera maintenu par une organisation sans but lucratif, avec la participation de toutes les parties intéressées (on parle donc bien d’une norme).

  • Le standard a été publié et est disponible de manière gratuite ou en payant une redevance minimale, et peut être librement copié ou redistribué.

  • Les droits intellectuels relatifs à l’utilisation du standard sont accordés gratuitement de manière irrévocable.

    • 13 European Interoperability Framework, p. 9.

    Aucune contrainte ne doit exister quant à la réutilisation du standard.13

19Comme dans les lois françaises et belges, la notion d’absence de restrictions d’utilisation, sur le plan de la propriété intellectuelle en particulier, est centrale : les standards ouverts doivent avant tout être des standards libres.

1.4 Les standards ouverts, voie royale vers l’interopérabilité

20L’interopérabilité peut se réaliser de différentes manières : soit par le biais d’une collaboration suffisante de la part de l’acteur premier ou dominant, qui donne une information complète sur les interfaces de ses systèmes ; soit par la définition commune de ces interfaces, à travers des formats et protocoles ouverts et normalisés. Si l’utilisation de formats ouverts n’est pas la seule voie à l’interopérabilité, elle est sans conteste la meilleure.

21Une telle solution permet une transparence complète ; on a donc la certitude qu’aucune information ne manque, et la garantie d’une bonne implémentation repose intégralement sur chaque développeur vis-à-vis de son propre logiciel. Ceci correspond à l’attente des utilisateurs, qui imputent tout défaut au développeur du logiciel défectueux : leur jugement ne sera pas trompé.

22En outre, un tel processus annule en principe toute discrimination. Aucun acteur ne se retrouve en position de force vis-à-vis des autres, du fait d’être l’inventeur unique de l’interface ou d’être le seul à pouvoir y apporter des modifications. Ces situations existent parfois, qui voient des spécifications dites ouvertes être modifiées unilatéralement par l’entreprise détenant des droits de propriété intellectuelle et relatifs, plongeant les concurrents dans un retard considérable.

23Enfin, le fait que les améliorations du format ou du protocole en question soient proposées et approuvées collégialement entraîne un avantage et un inconvénient. Grâce à cela, toute amélioration a priori bonne pour le public a de grandes chances d’être proposée, car la diversité des acteurs participant au processus garantit une diversité des idées – lorsqu’une entreprise seule fait évoluer un produit, une avancée qui ne relève pas de son orientation industrielle sera absente des améliorations apportées.

24En revanche, cette collégialité peut être un frein à l’innovation : selon la procédure à suivre pour améliorer un format, un éventuel consensus ou une approbation largement majoritaire peut être exigé, générant de fait un veto pour chaque membre ou un petit nombre d’entre eux réunis. Ainsi, on peut constater le retard qu’a pris le développement des standards du web au sein du W3C, issu de désaccords trop grands entre les acteurs participants : l’évolution du langage HTML, par exemple, n’a pas bénéficié d’avancée significative pendant plus de dix ans, ce qui a suscité l’adoption massive de solutions fermées palliant les principaux manques (contenu riche, vidéo, streaming…), comme le format Macromedia Flash, devenu propriété de la société Adobe.

25Toutefois, ces difficultés ne remettent pas fondamentalement en cause le modèle de la normalisation : tout au plus, elles appellent à un perfectionnement des différents processus, en particulier en direction d’un assouplissement. Dans le domaine des TIC, les évolutions vont si vite que la normalisation ne peut se permettre tout retard dû à une procédure trop lourde ou contraignante.

  • 14 Algorithme logiciel réalisant le codage et le décodage du contenu multimédia.
  • 15 À propos de cet exemple, voyez T. Nitot, « Les codecs de HTML 5 », sur Standblog, 30 juin 2009, htt (...)

26En vérité, le principal écueil demeure la crainte de standardiser des technologies se révélant l’objet de brevets onéreux. En témoignent les derniers soubresauts de la normalisation de la cinquième version du langage HTML par le W3C (consortium chargé d’émettre des recommandations dans le domaine du web) : alors que l’apparition d’une balise <video> allait enfin permettre l’insertion native et standardisée de vidéos dans une page web, des craintes en matière de brevets ont abouti à l’absence de recommandation en ce qui concerne le codec14 à utiliser. Une balise vidéo commune, mais un codec à la discrétion des acteurs : c’est l’interopérabilité qui en ressort perdante.15

2. Politique des organismes de normalisation : quelle « ouverture » pour les standards ?

27Dans cette section, nous porterons notre attention sur les processus de normalisation et en particulier la façon dont les organismes attelés à cette tâche prennent en compte la question des restrictions légales. En effet, de manière générale – c’est là le but de la normalisation –, les standards sont documentés.

  • 16 Étant acquis que la seule sanction est la non-normalisation ; le titulaire de droit reste seul mait (...)

28L’enjeu fondamental des organismes de normalisation consiste à garantir une sécurité juridique suffisante, compte tenu des droits des entreprises détentrices de brevets. De manière constante, elles s’attachent à identifier, tant que cela est possible, les brevets existants, afin de prendre ses décisions en connaissance de cause et d’éviter tout patent ambush (ou piège à brevet). Leurs positions divergent en revanche sur la liberté plus ou moins grande laissée au titulaire de droit.16

29Les organismes de normalisation principaux, en matière de TIC, sont l’ISO (organisme international de normalisation), l’Ecma (organisation européenne de normalisation en matière informatique), le W3C (World Wide Web consortium, encadrant la standardisation du web par ses recommandations), l’IETF (Internet Engineering Task Force, attachée aux normes du réseau Internet, tels les protocoles HTTP, SMTP…) et la CEN (organe européen de normalisation).

2.1 Les organismes généralistes : l’ISO et la CEN

30La CEN partage17 depuis 2008 la patent policy de l’ISO18. Cette policy – que partagent également l’ITU et l’IEC – est très simple : la seule exigence formulée est celle, pour les acteurs concernés, dans la mesure de leur propre information, de signaler l’existence de brevets ou d’un litige relatif à un ou plusieurs brevets portant sur la norme en cours d’élaboration.

31Au-delà, la policy laisse le titulaire de droit libre de négocier une licence gratuite, de négocier une licence sous conditions RAND – éventuellement payante) ou de ne pas accorder de licence, auquel cas la norme n’inclura pas les techniques brevetées. Les organismes concernés se gardent de toute appréciation de la validité des droits (nouveauté et non-trivialité du brevet, principalement), et renvoient la négociation éventuelle aux parties concernées, hors du processus de normalisation en tant que tel.

32Une licence sous des termes RAND peut-elle être considérée comme un standard ouvert tel que défini dans l’European Interoperability Framework ? De toute évidence, non, puisque l’EIF pose la gratuité comme critère. Il convient dès lors d’être attentifs aux conditions de licence, puisqu’une norme ISO ou CEN ne constitue pas automatiquement un standard ouvert.

2.2 L’Ecma

33Ecma International19 est une organisation privée visant à regrouper les acteurs de l’industrie des TIC et du commerce électronique pour définir des standards dans ces domaines à un rythme plus en phase avec l’évolution rapide des nouvelles technologies que l’ISO ou la CEN. Son credo, à l’inverse de l’IETF (cf. infra) est la simplicité des procédures.

34Au niveau de leur politique en matière de brevets, l’Ecma a publié un code de conduite20 simple, et relativement contraignant pour le titulaire du brevet. En effet, dans les différents cas de figure prévus par ce texte – brevets détenus par des membres de l’Ecma ou par des tiers, demande de brevets en attente, etc. – l’Ecma poursuit l’objectif d’obtenir une licence RAND, sous peine d’écarter la technologie concernée par le brevet en cause. Même dans le cas où ce brevet n’était pas connu lors de l’élaboration de la norme, le code de conduite de l’Ecma prévoit que tout soit mis en œuvre, une fois la menace connue, pour obtenir une licence RAND, sous peine d’annulation de la norme.

2.3 Le World Wide Web consortium

35Le W3C s’est doté de sa propre patent policy depuis quelques années.21 Celle-ci est beaucoup plus élaborée que le texte de l’ISO. La W3C Patent Policy du 5 février 2004 – la dernière version en date – pose comme principe de base la licence gratuite (royalty-free)22 ; sans cette garantie, aucune recommandation ne sera approuvée.23

  • 24 W3C Patent Policy, art. 3.1.

36Cette obligation de licencier en royalty-free tous droits de propriété intellectuelle détenu s’applique dès son entrée à tout participant à un working group, lorsque ces droits portent sur une recommandation discutée dans le working group en question.24 L’article 4 de la policy prévoit les cas d’exonération, en particulier dans des circonstances d’entrées et sorties de certains participants aux working groups.

37Les exigences minimum d’une licence royalty-free de la W3C sont expressément prévues à l’article 5, uniformisant ainsi les autorisations et garantissant une certaine sécurité juridique. Retenons quelques éléments-clés :

  • La licence est valable pour tous, membres ou non du W3C (art. 5.1).

  • La licence peut être conditionnée à une réciprocité (art. 5.4) et peut-être suspendue vis-à-vis d’un bénéficiaire en cas de rupture de cette réciprocité (action en justice pour violation de brevet… – art. 5.6).

  • La licence ne peut être conditionnée par un paiement de charge, royalties ou autre (art. 5.5).

  • La licence peut être restreinte au champ d’application de la recommandation (art. 5.3).

  • 25 Voy. sur ce débat : Free Software Foundation, Position de la FSF sur la politique de brevets « libr (...)

38Cette dernière condition trace une frontière entre un standard ouvert, sans restrictions légales de mise en œuvre, et un standard libre ou open source, qui ne tolérerait, selon les définitions respectives de la Free Software Foundation et de l’Open Source Initiative, aucune restriction d’utilisation, y compris dans son champ d’application : le standard devrait, dans cette logique, pouvoir être modifié et utilisé à d’autres fins que le seul cadre de la recommandation W3C25.

39L’article 7 de la W3C Patent Policy prévoit la mise en place d’un groupe de médiation en cas de révélation tardive de l’existence d’un brevet non disponible sous une licence respectant les conditions de l’article 5. Enfin, l’article 8 définit les essential claims qui, seuls, sont soumis à la policy : il s’agit des brevets ou revendications portant sur tout élément indispensable à l’implémentation de la recommandation, auquel il n’existe pas d’alternative.

2.4 L’Internet Engineering Task Force

  • 26 Intellectual Property Rights in IETF Technology, RFC 3979, mars 2005, disponible à l’adresse http:/ (...)
  • 27 Voy. A. Gupta, op. cit., p. 5.
  • 28 Request for Comments, documents de travail de l’IETF.
  • 29 IP in IETF Technology, n° 4.1.
  • 30 IP in IETF Technology, n° 8.

40L’IETF prévoit une patent policy26 très développée, vu la nature complexe et particulière du processus de décision propre à l’IETF. Les conditions de licence, cependant, sont très souples27 : elle prévoit que les normes issues des RFC28 doivent être licenciées sous des conditions raisonnables et non discriminatoires, mais en excluant explicitement tout contrôle de ce caractère RAND29 et, bien qu’affichant une préférence pour les licences royaltyfree, accordent aux working groups toute latitude pour choisir une technologie sous licence RAND, voire sans licence, s’ils pensent que cette technologie est supérieure.30

41Comme dans le cas de l’ISO, la politique de l’IETF en matière de brevet présente le risque d’aboutir à une certaine confusion entre les standards ouverts « à l’européenne » et les standards de l’IETF. Il y a plus délicat : l’IETF elle-même, dans sa RFC 202631 visant les apports extérieurs, définit les standards ouverts, selon une définition plus large – et incluant les normes sous licences RAND.

42De manière générale, on remarquera que les licences royalty-free sont d’autant plus facilement acceptées dans des domaines de normalisation très spécifiques, caractérisés par leur grande immatérialité et la gratuité des logiciels eux-mêmes, comme le web. L’IETF, quant à elle, comme l’Ecma, couvre un domaine très large, impliquant parfois des solutions logicielles complexes et coûteuses (cryptographie…). De même, les références aux standards ouverts dans les politiques nationales et européennes d’interopérabilité concernent généralement des services simples, basés sur le web ou des logiciels d’usage courant, auxquels une définition orientée sur la gratuité convient aisément.

Conclusion

43Arrivés au terme de cet aperçu, que pouvons-nous dire ? L’interopérabilité, appelée à jouer un rôle-clé dans une société et une économie toujours davantage basées sur des réseaux, a, plus que jamais, besoins de standards : la voie la plus simple et la plus rapide pour parvenir à cette interopérabilité demeure la définition et l’adoption de standards communs, ouverts et, si possible, libres.

44Les organismes de normalisation réalisent un travail capital à cet égard : en permettant le dialogue et l’élaboration de solutions communes, en réglant, avec des hauts et des bas, les questions de propriété intellectuelle, ils participent à la construction de cette société interopérable souhaitée par le plus grand nombre.

45Les autorités publiques également, par l’utilisation systématique de standards ouverts, montrent la voie à un public souvent perdu lorsqu’il doit faire des choix dans le domaine informatique. Il convient de ne pas relâcher cet effort sous la pression de certains acteurs de l’industrie qui rechignent parfois à s’adapter à cette nouvelle donne – et ce, bien qu’une majorité des entreprises ait tout intérêt à l’utilisation de standards ouverts.

46On l’a dit et redit, le choc de la révolution numérique s’apparente, sur le plan de la circulation de l’information, à celui de l’invention de l’imprimerie voire, pour certains, de l’écriture. Il est fondamental que les données numériques soient aussi aisément accessibles que nos livres papier. Qu’une entreprise ou une autorité publique puisse contrôler la lecture et la conservation des données ou les moyens de communication semble inconcevable dans une société démocratique. L’avenir nous en préservera : l’adoption massive des standards ouverts croît inexorablement.

Haut de page

Notes

1 Comme exemples de protocole, citons : le HTTP (protocole web), le SMTP (protocole de courriel), l’IP (protocole du réseau Internet) ou le XMPP (protocole de messagerie instantanée) pour des protocoles ouverts ; OSCAR, MSNP (protocoles de messagerie instantanée) ou Skype (protocole de téléphonie sur IP ou VoIP) comme protocoles fermés.

2 Comme exemples de formats : HTML (page web), PDF (documents d’impression), MPEG, WMA/ WMV et Theora/Vorbis (données audio/vidéo), ODF et OXML (documents de bureautique). Si les conditions d’utilisation de ces formats sont définies par des licences diverses et plus ou moins libres, leurs spécifications sont en général ouvertes. Les formats Microsoft Office jusqu’à la version 2003 ont longtemps fait exception à cette règle.

3 Nous n’entrerons pas ici dans le débat sur la brevetabilité des logiciels, tenant pour donnée cette protection dans de nombreux pays à travers le monde.

4 Voy, par exemple le cas de la distribution GNU/Linux Ubuntu, logiciel libre, sur https://help. ubuntu.com/community/FreeFormats ; dans ce sens également, Ph. Gilliéron, Open Source et droit des brevets, in R.L.D.I., n° 24, 2007, pp. 69 – 72.

5 Les spécifications de ces formats ont longtemps été secrètes, mais sont disponibles depuis février 2008 sur le site internet de Microsoft, dans le cadre de sa politique d’interopérabilité. Voy. http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx

6 En anglais, standard signifie tout à la fois norme et standard, ce qui conduit parfois à une confusion. En particulier, il convient d’être vigilant face à l’utilisation du mot standardisation, qui devrait se traduire en français par normalisation.

7 Voy. A. Gupta, « Are open standards a prerequisite to open source?: a perspective in light of technical and legal developments », in C.T.L.R., n° 1, 2009, p. 3.

8 Voy. la licence sur le site d’Adobe à l’adresse http://partners.adobe.com/public/developer/support/topic_legal_notices.html

9 Loi du 10 août 2005 instituant le système d’information Phenix, M.B., 1er septembre 2005, art. 30.

10 Loi n° 2004-575 du 21 juin 2004 pour la confiance dans l’économie numérique, art. 4.

11 Voy. le site http://ec.europa.eu/idabc/

12 European Interoperability Framework, 2004, disponible sur http://ec.europa.eu/idabc/en/document/3473/5887

13 European Interoperability Framework, p. 9.

14 Algorithme logiciel réalisant le codage et le décodage du contenu multimédia.

15 À propos de cet exemple, voyez T. Nitot, « Les codecs de HTML 5 », sur Standblog, 30 juin 2009, http://standblog.org/blog/post/2009/06/30/Les-codecs-de-HTML-5; R. Paul, « Decoding the HTML 5 video codec debate », sur Ars Technica, 5 juillet 2009, http://arstechnica.com/open-source/ news/2009/07/decoding-the-html-5-video-codec-debate.ars ; D. Meyer, « HTML 5 drops open-source video codec », sur ZDN et News, 6 juillet 2009, http://news.zdnet.com/2100-9595_22-318208.html

16 Étant acquis que la seule sanction est la non-normalisation ; le titulaire de droit reste seul maitre de sa propriété intellectuelle.

17 Voy. la huitième guideline CEN/CENELEC à l’adresse http://www.cen.eu/boss/supporting/reference+documents/reference+documents.asp

18 Disponible à l’adresse http://isotc.iso.org/livelink/livelink/fetch/2000/2122/3770791/Common_Policy.htm

19 http://www.ecma-international.org

20 Disponible à l’adresse http://www.ecma-international.org/memento/codeofconduct.htm

21 Disponible à l’adresse http://www.w3.org/Consortium/Patent-Policy/

22 Voy. A. Gupta, op. cit., pp. 4-5.

23 W3C Patent Policy, art. 2.

24 W3C Patent Policy, art. 3.1.

25 Voy. sur ce débat : Free Software Foundation, Position de la FSF sur la politique de brevets « libres de droits » (royalty-free) du W3 Consortium, 1er juin 2003, trad. fr. C. Corazza, disponible à l’adresse http://www.gnu.org/philosophy/w3c-patent.fr.html  ; contra, D.J. Weitzner, Standards, Patents and the Dynamics of Innovation on the World Wide Web, 1er novembre 2004, disponible à l’adresse http://www.w3.org/2004/10/patents-standards-innovation.html

26 Intellectual Property Rights in IETF Technology, RFC 3979, mars 2005, disponible à l’adresse http://www.ietf.org/rfc/rfc3979.txt

27 Voy. A. Gupta, op. cit., p. 5.

28 Request for Comments, documents de travail de l’IETF.

29 IP in IETF Technology, n° 4.1.

30 IP in IETF Technology, n° 8.

31 http://tools.ietf.org/html/rfc2026

Haut de page

Pour citer cet article

Référence papier

Ladislas Goffinet, « Les standards ouverts et la normalisation comme conditions de l’interopérabilité logicielle », Cahiers Droit, Sciences & Technologies, 3 | 2010, 165-176.

Référence électronique

Ladislas Goffinet, « Les standards ouverts et la normalisation comme conditions de l’interopérabilité logicielle », Cahiers Droit, Sciences & Technologies [En ligne], 3 | 2010, mis en ligne le 01 novembre 2015, consulté le 26 mai 2018. URL : http://journals.openedition.org/cdst/231 ; DOI : 10.4000/cdst.231

Haut de page

Auteur

Ladislas Goffinet

Avocat au barreau de Namur

Haut de page

Droits d’auteur

Tous droits réservés

Haut de page
  • Logo Réseau Droit, Scences et techniques
  • Logo CNRS
  • Logo AMU
  • OpenEdition Journals