Note: Mise à jour permanente, rédaction en cours jusqu’à ce que cette notice disparaisse. Je me permets aussi de mettre hors ligne les commentaires au fur et à mesure qu’ils deviennent obsolètes (c’est à dire ceux qui aident à la construction et qui ont été pris en compte, ou ceux qui ciblent un point ayant évolué depuis leur rédaction).
Le document en cours de finalisation est en attente de relecture avant envoi. Merci à ceux qui peuvent faire une passe sur le fond ou sur la forme et remonter des correctifs.
À destination de la Hadopi, via M. Fabrice Aubert,
Le présent document est une contribution à la consultation publique de la Hadopi dans le cadre de la saisine de l’association VideoLAN, éditrice du logiciel VLC media player, elle-même dans le cadre de sa mission de régulation des mesures techniques de protection prévues aux articles L.331–31 et suivants du code de la propriété intellectuelle.[i]
La question posée est de « savoir si ‹ la documentation technique et les interfaces de programmation › visés à l’article L.331–32 intègrent les clefs de déchiffrement d’un contenu protégé et plus généralement les secrets nécessaires ».
La clef de (dé)chiffrement (et plus généralement les secrets) fait-elle partie des éléments prévus par L.331–32[ii] ?
La loi décrit les informations essentielles à fournir dans le cadre qui nous occupe comme « la documentation technique et les interfaces de programmation nécessaires pour permettre à un dispositif technique d’accéder […] à une œuvre ou à un objet protégé par une mesure technique et aux informations sous forme électronique jointes […]. »
Pour répondre à la question titre je propose de découper ce texte en trois critères objectifs et plus facilement vérifiables.
- Qu’est-ce qu’un élément « nécessaire » [pour permettre l’accès…] ?
- Qu’est-ce qu’une « documentation » et comment définit-on « la documentation nécessaire » ?
- Qu’est-ce qu’un élément « technique » ? Comment précise-t-on le terme « documentation » avec ce qualificatif ?
Pour déterminer si la clef de déchiffrement appartient aux données à transmettre via la documentation technique, quand elle est nécessaire à un accès effectif aux œuvres protégées, il convient et suffit de vérifier qu’elle vérifie objectivement chacun de ces trois critères délimités et strictement interprétés.
1– Qu’est-ce qu’un élément « nécessaire » ?
Cette première question est la plus simple. Un élément est nécessaire pour permettre l’accès à une œuvre celui-ci est impossible en son absence.
La clef de déchiffrement est un élément nécessaire en ce que la description de fonctionnement de la mesure technique, des interfaces ou de l’algorithme utilisé ne sont pas suffisants à déchiffrer l’œuvre et donc à y donner accès. Il s’agit de l’élément central, un peu comme la clef d’un coffre fort : La documentation sur la forme générale de la clef et sur le fonctionnement de la serrure ne sont pas suffisants à l’ouverture du coffre.
2– Qu’est-ce qu’une « documentation » ?
En l’absence de définition légale il nous faut regarder la définition linguistique. Le dictionnaire de l’Académie Française nous est de peu d’aide en ce qu’il la définit comme un ensemble de documents et nous renvoie à l’action de documenter. Nous ne pouvons donc pour l’instant que conclure sur le fait que la documentation ne peut se résumer à un unique document (par exemple la description de fonctionnement).
L’action de documenter est définie, toujours dans le dictionnaire officiel, par l’action de fournir à quelqu’un des documents, des informations. Cela rejoint la définition du Larousse qui définit documentation par l’unité d’information correspondant à un contenu singulier.
La clef de déchiffrement étant un élément immatériel à usage utilitaire, il s’agit bien d’une information (i.e. renseignement qu’on donne ou qu’on obtient). Si cette information est nécessaire pour permettre l’accès à l’œuvre, elle fait de fait partie de « la documentation nécessaire pour permettre l’accès à l’œuvre ».
Il est utile de noter que le législateur n’a pas fait référence à « la documentation existante », « la documentation de fonctionnement » ou « la documentation » de façon générique et ambiguë. Il s’agit de « la documentation […] nécessaire ». Le fait que la clef soit actuellement ou non présente dans une unité reconnue par les éditeurs comme étant « la documentation » n’est donc pas un critère de réponse. C’est le caractère informatif et nécessaire qui implique la présence dans la documentation, ou son éventuel ajout s’il était besoin.
3– Qu’est-ce qu’un élément « technique » ?
Pour répondre à cette question, le plus simple est de qualifier à qui et pour quoi un élément est utilisé. S’il est conçu et utilisé par du personnel technique, ou s’il ne sert que lors d’une procédure elle-même technique, l’élément peut sans contestation être qualifié de technique.
Ici la clef de déchiffrement n’est intelligible que pour des techniciens. Elle est de plus inutilisable directement par un humain et n’est destinée qu’à un programme informatique, technique de nature. Il s’agit de plus d’un élément interne à ce programme informatique en ce qu’il n’est pas l’objet du programme (l’œuvre, chiffrée ou non, et l’accès à cette œuvre). Il s’agit donc d’un élément purement technique.
Conclusion
Oui, après analyse de ces trois critères suffisants de par la loi, interprétés strictement et objectivement, sans aborder les questions tierces non requises par la loi, la clef de déchiffrement fait partie de la documentation technique nécessaire pour permettre l’accès aux œuvres protégées, tel que prévu par l’article L.331–32.
Confirmation par l’éclairage de L.331–5[iii]
Cette analyse doit aussi être renforcée par l’éclairage de l’article maître, c’est à dire le L.331–5, qui permet de mieux comprendre le sens souhaité par le législateur. Ce dernier, avant de faire référence aux détails du L.331–32 pour définir ce que sont les « informations essentielles », explicite ce qui suit :
« Les mesures techniques ne doivent pas avoir pour effet d’empêcher la mise en œuvre effective de l’interopérabilité, dans le respect du droit d’auteur. Les fournisseurs de mesures techniques donnent l’accès aux informations essentielles à l’interopérabilité dans les conditions définies au 1° de l’article L.331–31 et à l’article L.331–32. »
Notion de secret
Il est utile de noter que l’ensemble de la procédure citée a pour objectif de communiquer à un demandeur l’ensemble des informations essentielles à l’interopérabilité qui autrement auraient été gardées secrètes.
Toutes les informations visées sont par nature initialement des secrets. C’est parce qu’elles sont traitées comme des secrets par les détenteurs de la mesure technique de protection et pour y répondre qu’ont justement été établis les articles L.331-* et notamment L.331–5, L.331–31 et suivants qui concernent la Hadopi.
Par nature, non seulement les secrets ne sont pas exclus de la procédure, mais ce sont même spécifiquement eux qui la motivent et qui en sont l’objet. La volonté du détenteur de la mesure technique de protection de considérer certains éléments comme « plus secrets » n’est aucunement un critère d’exclusion prévu par la loi.
Intention du législateur
Par la lecture de la citation du L.331–5, il devient explicite que l’ensemble constitué par « les informations essentielles », défini plus loin par le L.331–32, est prévu comme devant permettre une mise en œuvre effective de l’interopérabilité.
Considérant que l’essentiel des mesures de protection techniques existantes à ce jour ou à celui de l’écriture de la loi reposent sur un secret partagé (qui est souvent une clef de déchiffrement, mais pas forcément), il n’est pas envisageable que le législateur ait exclu ce secret (ou la clef de déchiffrement) au sens qu’il donne à la documentation à fournir au sens du L.331–32.
Ceci est renforcé par le passage indiquant que « Un protocole, un format, une méthode de cryptage, de brouillage ou de transformation ne constitue pas en tant que tel une mesure technique au sens du présent article ». Il est alors clair que dans l’intention du législateur, les informations essentielles couvertes par L.331–32 n’incluent donc pas que les descriptions des protocoles, formats, méthodes cryptage ou de transformation, mais bien aussi les processus et informations permettant l’accès, ce y compris les informations secrètes comme la clef de déchiffrement, et même les processus supplémentaires comme l’accès aux services éventuels de renouvellement des clefs ou de vérification/certification par un serveur tiers. La restriction à la simple documentation de fonctionnement serait explicitement contraire à la définition partielle posée en L.331–5 et citée en haut du présent paragraphe.
Cohérence du texte
L’assemblage des intentions explicitement exprimées en L.331-* n’est cohérent avec L.331–32 qu’à la condition de l’analyse précédente : la documentation inclut toutes les informations nécessaires, y compris les secrets comme la clef de déchiffrement et les moyens d’accéder aux processus contrôlés par des services tiers.
Si ce dernier point n’est pas un élément emportant en lui-même la réponse à la problématique posée par la Hadopi, il doit être perçu comme un élément appuyant les analyses menées jusqu’alors dans la présente contribution et les confirmant.
Une interprétation (erronée) contraire serait bien à mal de dégager un sens utile et cohérent à la procédure définie par la loi. Si l’incohérence de la loi n’est pas impossible en soi, quand une interprétation stricte de la loi permet de respecter à la fois l’intention du législateur et la cohérence globale du texte, elle ne peut que s’imposer au détriment d’une interprétation tierce n’ayant aucune de ces deux caractéristiques.
Conclusion
Oui, par les analyses ci-dessus, il apparaît confirmé que les informations essentielles, via la notion de documentation technique, incluent l’ensemble des secrets nécessaires à une interopérabilité effective, ce qui inclut aussi l’éventuelle clef de déchiffrement, mais pas uniquement.
Conclusion générale à la consultation
Par les analyses précédentes, nous pouvons répondre :
- OUI, les clefs de déchiffrement font partie des informations essentielles de l’article L.331–5 et détaillées à l’article L.331–32, faisant partie intégrante de la documentation technique nécessaire à un dispositif technique d’accéder à une œuvre ou à un objet protégé par une mesure technique.
- OUI, plus généralement, les secrets ne sauraient être exclus des informations essentielles de l’article L.331–5 et détaillées à l’article L.331–32, faisant partie intégrante de la documentation technique nécessaire à un dispositif technique d’accéder à une œuvre ou à un objet protégé par une mesure technique.
- OUI, la transmission de ces clefs et secrets peut et doit être exigée par la Hadopi dans le cadre de la mission de régulation des mesures techniques de protection prévues aux articles L.331–31 et suivants, en ce qu’elle est nécessaire à l’interopérabilité visée par les articles L.331–5 ainsi que L.331–31 du code de la propriété intellectuelle.
[i] Consultation publique ouverte et publiée via le document à l’adresse http://www.hadopi.fr/sites/default/files/page/pdf/saisineVideoLAN_consultation-1.pdf
[ii] L.331–32 du code de la propriété intellectuelle : http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006069414&idArticle=LEGIARTI000020738177
[iii] L.331–5 du code de la propriété intellectuelle : http://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI000021212283&cidTexte=LEGITEXT000006069414
Annexe – Respect de la mesure technique de protection par VideoLAN
Il est toutefois prévu par les textes que VideoLAN doit respecter la mesure de protection – et donc désactiver les fonctions qui sont censées être bridées pour respecter la « protection » de l’œuvre.
Il appartient aussi à VideoLAN de protéger la mesure de protection elle même, et donc d’éviter que les éventuelles clefs ou documentations ne deviennent publiques. Il est légitime de demander à ce que cette protection de la MTP soit de même niveau que ce qui est implémenté par le reste des intervenants. Il est toutefois important de ne pas exiger de contrainte non subie par des tiers, et en particulier un niveau d’efficacité plus important que les autres logiciels ayant la même fonction. Considérant l’historique de tels logiciels et la complexité technique de masquer les informations secrètes au public expert, il ne peut y avoir qu’une obligation de moyen et non une obligation de résultat sur cet aspect.
Dans le même esprit, et ainsi que pour les autres intervenants, la fourniture des clefs doit inclure l’accès aux éventuels services de renouvellement, voire la délivrance de nouvelles clefs en cas de désactivation des premières (par exemple en cas de divulgation, comme cela s’est passé pour d’autres logiciels).
Annexe – Contexte de la contribution – compétence et pertinence
Afin de compléter le cadre d’une réponse formelle à la consultation de la Hadopi et éclairer sur ma compétence – quand bien même j’insiste sur le caractère non-technique de la question posée : Ingénieur de formation, tour à tour expert technique en ingénierie logicielle, responsable innovation puis consultant en architecture de système d’information, je suis directeur technique et co-fondateur d’une startup qui travaille dans la distribution de contenus culturels – une majorité de ces contenus étant protégés par des mesures techniques, que pour partie nous appliquons nous-même sur les œuvres. Sans prétendre être expert sur chaque aspect individuel, je m’estime donc à la fois suffisamment pertinent et suffisamment compétent sur la question.
Cette contribution est toutefois réalisée à titre uniquement personnel et privé. Elle n’engage nullement ma société, ses actionnaires, sa direction, ses clients, ses fournisseurs, ou une quelconque entité autre que ma personne privée.
Pour discuter du fond, hors de la question posée par la Hadopi, ce qui suit ne fait pas partie de ma réponse formelle à la consultation de la Hadopi :
Les non-questions
La démarche utilisée se veut volontairement précise et délimitée. Elle a pour objectif d’éviter ce que j’appelle les non-questions. Ces non-questions sont des enjeux potentiellement sérieux et importants mais qui ne sont pas posées par les textes législatifs ou réglementaires nationaux dans le cadre de la présente procédures. Elles ont de plus tendance à faire dériver le débat sur des positions bloquantes, clivantes, émotives ou idéologiques, de nature à ralentir voire ajouter une pression non souhaitable sur la prise de décision actuelle.
Parmi ces non-questions on peut par exemple trouver ce qu’est une clef de chiffrement, comment on s’en sert, comment elle s’intègre dans le logiciel ou comment on la détermine, pourquoi il est dangereux d’en risquer la divulgation publique ou si l’open source est adéquat à pour l’accès à des oeuvres protégées. Malgré l’intérêt important à débattre de ces questions, et le fait qu’elles soient toutes liées à la situation actuelle, aucune n’apparait posée comme un critère dans le cadre de la procédure, et aucune de ces questions ne devrait donc influer sur l’action qui en résultera.
Le risque de confusion des compétences
La non-question la plus dangereuse à ce titre est celle qui tente de pondérer ou relativiser la question de l’intéropérabilité vis à vis de l’importance de la confidentialité des données techniques qui protègent les oeuvres. Une telle non-question serait de nature à se substituer au législateur et à remettre en cause son choix d’imposer une interopérabilité effective.
Je ne peux que recommander à la Haute Autorité de ne pas prêter voix à ce potentiel débat de fond et d’en refuser l’expression ou l’évaluation dans le cadre de la consultation en cours ou de la prise de décision sur la procédure en cours. Un tel débat et les pressions importantes qui en découlent risquent de l’emmener à devoir prendre parti, au risque de se positionner en juge du législateur ou à remettre en cause l’article le sens et l’intention très claire du L331–5.
La problématique sous-jacente
Au dela de la procédure actuelle et de la consultation qui en découle, il existe en effet un débat de fond sur l’équilibre entre l’interopérabilité et la protection des mesures techniques. Le propre de ces mesures techniques est de se baser sur un secret partagé entre acteurs de confiances mais dont le public est exclu.
Le système peut fonctionner avec des acteurs identifiés et en nombre restreint. La démocratisation du logiciel fait exploser cette vision, surtout cumulé à l’avènement du logiciel en sources ouvertes. L’interopérabilité, si elle doit être exercée par tous, ce qui est le cas si « tous » s’approprient la dimension logicielle, met fin à la notion de secret, et donc aux mesures de protection techniques qui sont justement basées sur cette notion de secret. Il y aura un choix à faire à l’avenir, qui ne fait que commencer avec VideoLAN mais qui ne fera que grandir quelle que soit la réponse apportée à la présente procédure.
C’est un sujet important qui devra occuper le législateur dans les années qui viennent. Ne faisons toutefois pas l’erreur d’usurper le rôle de la représentation nationale en négociant sur ce que nous devons faire aujourd’hui : appliquer la loi et les choix déjà pris.
10 réponses à “Réponse (publique) à la consultation de la Hadopi concernant VideoLAN”
Eric, si je peux me permettre, Je pense que ce billet mérite d’être porté à l’attention de l’Hadopi, et ne suis pas sûr qu’il soit acceptable pour eux sous ce format. Tu as vérifié auprès d’eux quelles procédures étaient applicables pour leur faire part de ce genre de contributions ?
C’est une prépublication pour finaliser (et pour ça j’ai besoin de feedback). La réponse formelle sera envoyée par mail, comme demandé sur le document lié.
Pour faire le lien avec le domaine que tu couvres habituellement, il n’est pas difficile de transposer la réflexion actuelle au livre. La question ne tardera probablement pas à se poser.
Une très courte intervention.
Je ne pense pas qu on puisse intégrer la clé de chiffrement ni dans la documentation ni dans les API. La documentation explique comment fonctionne le systeme, alors que les API permettent de s interfacer avec un matériel ou logiciel.
Une cle est un moyen d authentification, et relève de la preuve d un droit acquis. Or le texte de loi ne contient aucune disposition qui, interprétée strictement, obligerait le concepteur d un MTP d accorder un droit d usage au requérant et donc de fournir des clés.
L acquisition de tels droits relève du domaine contractuel. or si VIdeo Lan était en mesure de satisfaire a ses besoins en rentrant dans le programme de partenariat « classique », la requête auprès de la Hadopi n aurait pas été nécessaire.
On arrive donc a la conclusion que l’interprétation stricte de la liste d éléments a fournir ne permet pas d atteindre la necessite clairement défini de prêtre l accès a l œuvre protégée.
Dux solution s ouvrent alors:
-avoir une interprétation large des éléments a fournir en partant du principe que le législateur a fourni une liste non exhaustive, l intention était par ailleurs nettement définie et impérieuse
– conclure que le texte de loi dans sa rédaction actuelle est un vœux pieux, mais d aucun intérêt pratique
J ai peur que la deuxième solution soit la bonne juridiquement
Attention au affirmations dues à l’habitude. Une documentation peut être une documentation de description de fonctionnement du système, mais aussi une documentation d’installation, de mise en oeuvre, d’architecture, d’interface entrée/sortie, d’utilisation par les équipes techniques, de mise à jour, … et là je ne cite que quelques documentations techniques possibles. La documentation de fonctionnement du système n’est qu’un élément parmi tous les possibles. Il est d’ailleurs intéressant de noter que les API ne sont qu’un élément de documentation parmi d’autres, on a juste souhaité particulièrement sur celui ci en le nommant explicitement.
Ici rien n’identifie que le législateur ait ciblé particulièrement une description du fonctionnement du système. Il n’est pas précisé « la documentation de fonctionnement » mais « la documentation nécessaire ». Les seules questions sont donc de savoir ce qu’est une documentation au sens large, et ce que recoupent les éléments nécessaires.
J’avais fait un passage complet sur la définition d’une documentation, je ne l’ai pas laissé car il me semblait inutile, je vais peut être le rajouter.
**
Le reste du commentaire aborde pour moi justement des non-questions, par exemple « qu’est-ce que la clef ? ». Tu la vois comme une preuve d’un droit acquis mais techniquement c’est un élément permettant l’accès. La preuve d’un droit acquis est éventuellement l’usage secondaire qui en est fait, mais pas ce que c’est en soi. Le texte ne s’intéresse nullement au rôle des éléments à fournir, donc c’est hors contexte. Je note juste que si c’était une preuve de droit acquis, quiconque recopierait la clef aurait la preuve d’avoir acquis un droit.
« Or le texte de loi ne contient aucune disposition qui, interprétée strictement, obligerait le concepteur d un MTP d accorder un droit d usage au requérant et donc de fournir des clés. »
Pour la première partie, si, la disposition oblige justement à permettre l’accès effectif aux oeuvres. C’est l’objet même du L331-5. Quant à savoir si, interprétée strictement, cela inclut les clefs, c’est bien toute la question débattue. Par « interprétée strictement » tu sembles entendre « en donnant un sens restreint aux termes ». Or strictement c’est « le terme et rien que le terme ». La notion de « documentation de fonctionnement » est justement une interprétation et pas une lecture strict du texte.
Ma réponse est forcément orienté par ma connaissance du fonctionnement de ces systèmes.
La clé est à la base de l’authentification du système de lecture. Elle est fournie une fois que le producteur du système s’est engagé contractuellement à respecter toutes les restriction qui garantissent l’efficacité du système anticopie. Il ne s’agit pas d’une documentation, ni même d’une donnée, il s’agit d’un certificat. Le même contrat est aussi accompagné de la fourniture d’une série de documentations. Les jugements de kaleidescape sont éclairants sur le sujet.
VideoLan n’a pas de probleme de documentation ou d’API. ils savent tout. Ils ont même une clé, voire plusieurs. La question c’est d’avoir un certificat légalement pour pouvoir le distribuer. Hadopi peut elle demander à AACS-LA de fournir à video lan un certificat qui est normalement livré en échange d’engagements forts de procédure et de secret que video lan n’est pas à meme de respecter.
On en arrive en fait au point sous jacent crucial. les systemes de protection ne verifient pas les droits de l’utilisateur sur l’oeuvre, mais verifient que le fabricant materiel ou logiciel a bien les droits de license et respecte donc bien les restrictions d’usage imposées contracttuellement.
Et ça, la loi ne le traite pas…
La loi se centente d’imposer de donner un accès effectif. Elle ne se préoccupe justement pas de savoir si cela convient ou satisfait l’éditeur de la mesure de protection. C’est important, mais c’est une non-question pour la procédure en cours.
« Il ne s’agit pas d’une documentation, ni même d’une donnée, il s’agit d’un certificat. »
Les deux (les trois) ne sont pas exclusifs. Tu es dans l’affirmation. Tu pourrais aussi dire qu’une API n’est pas une documentation, c’est une API ; qu’une procédure n’est pas une documentation, c’est une procédure ; etc. J’ai réécrit pas mal le passage en question. Pour dire que ça ne fait pas partie de la documentation il faut avancer avec un argument ou une contradiction avec la définition de ce qu’est une documentation.
Et il s’agit bien de « la documentation nécessaire », pas de « la documentation existante ou habituelle dans le cadre de contrats d’intégration de DRM ». Le fait que les éditeurs de MTP incluent ou pas le certificat habituellement dans leurs documentations n’entre pas en ligne de compte. Ceci dit, de par la définition de ce qu’est une documentation, ça fait bien partie des informations transmises habituellement, donc de la documentation
« Hadopi peut elle demander à AACS-LA de fournir à video lan un certificat qui est normalement livré en échange d’engagements forts de procédure et de secret que video lan n’est pas à meme de respecter. »
Voilà la non-question. Tu te places du point de vue moral ou « réaliste ». Ce choix a déjà été fait par le législateur. C’est même tout l’objet de la procédure : imposer à l’éditeur de la MTP de fournir les informations essentielles pour que VLC (et d’autres) puissent accéder aux oeuvres protégées. Tu es en train de rediscuter, négocier ou remettre en question le choix fait au niveau de la loi. Ce n’est pas ce qu’on demande ni à toi ni à la Hadopi, c’est la compétence unique du législateur.
Document en relecture en vue d’un envoi : https://www.dropbox.com/s/nxkm8hapu27ygle/contribution%20hadopi%20-%20ericd%20-%20v1.pdf
[…] rédigé un billet il y a quelques temps pour envoyer une contribution à propos d’une consultation de la Hadopi concernant VLC. Le billet n’a pas forcément été mis à jour avec la toute dernière version qui a […]