DADVSI

De fr.discu.org

DADVSI (droit d'auteur et droits voisins dans la société de l'i'nformation) est le sigle d'une loi française visant à mieux rémunérer des auteurs de contenus numériques.

Le présent document tente d'en éclairer les effets sur le logiciel libre (opensource) et expose les propositions correspondantes.

Nous montrerons que DADVSI:

  • est une arme destinée à pallier l'inefficacité technique de mesures anticopie grâce à une loi
  • pourrait porter atteinte à la vie privée
  • menace indûment le logiciel libre

Remerciements[modifier]

Note: les cités ne partagent pas nécessairement les opinions exprimées.

S. Blondeel, Muriel, BL, RA, membres de l'AFUL

Qu'est-ce qu'un contenu et un format ?[modifier]

Les contenus numériques sont des 'données' représentant une oeuvre sous forme d'une suite de chiffres rendant compte de certaines de ses caractéristiques. Un ordinateur offre moyen d'utiliser (copier, transférer, écouter, voir...) un 'contenu' de ce type, abrité dans un fichier informatique ou convoyé par le réseau. Le terme 'contenu' désigne ici une oeuvre n'intégrant pas de logiciel, donc par exemple un film ou morceau de musique plutôt qu'un jeu vidéo ou un programme éducatif.

Chaque description de format révèle la façon dont on décrit l'oeuvre, grâce à lui, sous forme numérique. Une description de format fournit donc les réponses à des questions pertinentes pour tout auteur de programme devant l'employer telles que: où sont, dans un ensemble de données stocké selon ce format, les données décrivant l'image et comment la décrivent-elles?. Les spécialistes appellent cette description une spécification de format mais, par une sorte de métonymie (car si un format décrit, sa spécification est la description d'une description), le terme format est souvent employé avec le sens 'description de format' comme avec celui de "structuration d'un ensemble de données".

Un format de numérisation de contenu est, pour ce qui nous concerne ici, un énoncé des conventions techniques rendant possible de réaliser un logiciel capable de lire l'oeuvre.

Format: aspects pratiques[modifier]

Voici, par exemple, un dessin représentant, au prix d'un effort d'imagination, une flèche verticale pointée vers le haut, vaguement empennée:

Fichier:fleche haut.png

Un format d'image statique en noir et blanc pourrait par exemple définir que chaque document décrira une image sous la forme de 8 lignes abritant chacune 8 points, chacun de ces derniers pouvant être ou non illuminé.

Tentons de représenter sous ce format la flèche ci-devant reproduite. Il impose des limitations, quant au nombre de lignes et au contenu de chacune d'elles (la résolution numérique), interdisant de représenter fidèlement le dessin grâce à lui.

Il nous faut donc simplifier la flèche afin d'en obtenir une représentation conforme au gabarit imposé (8 lignes comptant chacune 8 points). Dans la version ainsi simplifiée reproduite ci-dessous des points ('.') remplacent les points (pixels) éteints ('noirs') et des 'X' ceux qui sont allumés ('blancs'):

Image affichée

....X...
...XXX..
..X.X.X.
....X...
....X...
....X...
....X...
...XXX..

Voici de nouveau le dessin, flanqué de son encodage selon notre format. Chaque ligne est pour cela suivie de l'expression en code binaire de son contenu: un '0' y encode chaque point éteint, un '1' y encode tout point allumé.

Image affichée Bits du fichier

....X... 00001000
...XXX.. 00011100
..X.X.X. 00101010
....X... 00001000
....X... 00001000
....X... 00001000
....X... 00001000
...XXX.. 00011100

À ce stade notre mission semble accomplie car l'ordinateur peut stocker et traiter la série de bits représentant chaque ligne.

À chaque série de 8 bits (ligne) [correspond une valeur décimale plus explicite pour un humain. Voici la conversion:

Image affichée Bits du fichier Valeur décimale correspondante

....X... 00001000  8
...XXX.. 00011100 28
..X.X.X. 00101010 42
....X... 00001000  8
....X... 00001000  8
....X... 00001000  8
....X... 00001000  8
...XXX.. 00011100 28

Un fichier abritant une séquence d'octets dont les valeurs décimales successives sont "8, 28, 42, 8, 8, 8, 8 puis 28" abrite par conséquent l'image de la flèche selon le format considéré.

Nous décrirons ainsi le format employé: "Ce format encode une image en noir et blanc. Chacun des points de l'image peut être allumé ou non. Chaque ligne de points en compte 8. Chaque image contient 8 lignes. On prendra donc soin, avant d'encoder selon ce format, de réduire l'image à cette expression (8 lignes de 8 points, chacun allumé ou éteint). L'encodage est effectué en rendant compte de l'état de chaque point éteint par un 0 binaire et de chaque point allumé par un 1 binaire. L'encodage commence par le point situé en haut à gauche de l'image décrite. À chaque ligne de cette image correspondent 8 bits consécutifs (un octet) donc une image complète (matrice de 8x8 bits) sera encodable au moyen de 8 octets."

Pour explorer plus avant lire l'article Wikipedia 'Format des données'

Formats aujourd'hui employés[modifier]

Les formats d'ordinaire employés sont plus élaborés. On parle par exemple du format MP3 ('décrivant' du son), GIF (image), JPEG (image), MPEG (vidéo), DivX (vidéo)...

Leurs descriptions sont le plus souvent publiées donc tout un chacun peut en prendre connaissance. Lorsque ce n'est pas le cas une analyse portant le nom de génie inverse, qui vise à la découverte du format par l'analyse d'au moins un contenu ou logiciel capable de le lire, offre moyen d'en établir la spécification.

Par conséquent un contenu commercialisé (par exemple sur un CD ou un DVD) est aujourd'hui a priori utilisable sur n'importe quel ordinateur disposant des ressources matérielles requises à l'exécution du programme nécessaire (par exemple d'une certaine quantité donnée de mémoire vive), quel que soit le système d'exploitation employé.

Dans la pratique quasi tout contenu est aujourd'hui partout utilisable, y compris par une machine n'exécutant que des logiciels libres donc, par exemple mais pas exclusivement, animée par le système d'exploitation libre Linux.

Génie inverse: aspects pratiques[modifier]

Si le format numérique décrit ci-devant n'était nulle par dévoilé et si nous souhaitions développer un logiciel libre capable de lire sous Linux des documents encodés selon ses directives nous commencerions vraisemblablement par obtenir des documents ainsi qu'un logiciel de lecture propriétaire (au code source non disponible) existant.

Voici un rappel de l'image, de l'encodage binaire de chacune de ses lignes puis des valeurs décimales correspondantes:

Image affichée Bits du fichier Valeur décimale correspondante

....X... 00001000  8
...XXX.. 00011100 28
..X.X.X. 00101010 42
....X... 00001000  8
....X... 00001000  8
....X... 00001000  8
....X... 00001000  8
...XXX.. 00011100 28

Dans le cas du document abritant une image de flèche (déjà décrit ci-devant) nous trouverions, dans le fichier, la séquence d'octets (déjà exposée): 8, 28, 42, 8, 8, 8, 8, 28. Afin de découvrir le format nous pouvons effectuer une modification dans le fichier puis en observer l'effet en affichant l'image grâce au lecteur existant, émettre des hypothèses, modifier à nouveau afin de les valider, puis progresser ainsi jusqu'à obtenir une description complète du format.

Transformons par exemple le premier bit en 1. Nous obtenons (les éléments impactés par cette modification sont ici présentés en rouge):

Image affichée Bits du fichier Valeur décimale correspondante

X...X... 10001000 136
...XXX.. 00011100  28
..X.X.X. 00101010 42
....X... 00001000  8
....X... 00001000  8
....X... 00001000  8
....X... 00001000  8
...XXX.. 00011100 28

Afficher ce fichier modifié grâce au logiciel de lecture propriétaire révèle l'effet de la modification, donc laisse formuler diverses hypothèses quant au format employé, qui seront à leur tour éprouvées par de nouvelles modifcations du fichier... Le format sera ainsi exploré.

DADVSI: qui, pourquoi et quoi ?[modifier]

Revenus des auteurs de contenus[modifier]

Les ordinateurs et réseaux copient les contenus numériques à faible coût, facilement, rapidement, sans dégradation et si nécessaire à distance ou anonymement.

Des ayants-droit (en pratique les maisons d'édition se chargent de tout cela et il est difficile de démêler si ceux des auteurs qui apprécient les DRM y lisent un mal nécessaire ou une bénédiction, mais peu nous importe ici) affirment que ces possibilités offrent moyen à certains de publier 'illégalement' des contenus de sorte que d'autres les obtiennent sans bourse délier.

Un nombre croissant d'utilisateurs bénéficie ainsi de contenus (par exemple en voyant un film ou en écoutant un morceau de musique) sans les payer et que cette augmentation de la proportion de copies illicites réduit trop leurs revenus. Selon de nombreux tenants de ces thèses les réseaux P2P véhiculeraient le gros de ces copies illicites.

Les ayants-droit, ou ceux censés les représenter, employèrent au fil des ans diverses astuces techniques destinées à rendre l'oeuvre inaccessible à qui ne paie pas. Mais toutes restèrent inefficaces car furent contournées et aucune mesure légale n'interdit de les circonvenir.

Droit à la copie privée[modifier]

Nous sommes hostiles à l'idée qu'un créateur ou producteur puisse ne pas être rémunéré pour ses oeuvres ou son travail. Ainsi nous ne soutenons pas l'appropriation d'oeuvres par copie qui soit non rémunératrice pour ses créateurs et producteurs. La question de la capacité financière de chacun à acquérir ces biens par les voies traditionnelles mérite toutefois d'être abordée.

Par ailleurs nous souhaitons éviter l'habituel amalgame entre « copie illicite » et copie privée, laquelle doit rester un droit.

Toutefois le sens de copie privée semble aujourd'hui indistinct.

Copie privée[modifier]

Note: S. Blondeel a contribué au plus gros de cette section mais ne partage pas nécessairement les opinions exprimés.

La copie privée *est* une activité légale (CPI, 122-5 2º) quelle que soit l'origine de l'original utilisé (P2P, copie d'un copain, original personnel ou emprunté...), du moins tant qu'elle ne bénéficie pas au 'public', donc à des inconnus. Ce fut confirmé en appel à Montpellier en mars 2005.

Les majors mènent un bourrage de crâne impressionnant pour faire croire le contraire, toutefois le mot «piratage», «piraterie», «contrefaçon» ou des mots de leur famille, en France, ne s'applique pas en cas de copie privée.

Toutefois les tribunaux eux-mêmes ne parviennent à trancher clairement et facilement (cas de moyens de verrouillage limitant le droit à la copie privée), au point que la Cour de Cassation interpréta une loi, peut-être indûment.

Par ailleurs droit à la copie est ambigu car s'agit-il:

  1. d'interdiction à autrui de nous interdire de (tenter de) le faire?
  2. de la possibillité d'exiger d'autrui le moyen de le faire?

Comparer: liberté d'expression / de circulation

La formulation de l'article du CPI semble aller dans le sens 1 mais en pratique ce droit à la copie privée ne serait qu'une exception accordée tant qu'elle ne réduit pas les prérogatives des ayant-droits.

DRM et MTP[modifier]

Des auteurs, éditeurs, producteurs et distributeurs de contenus jugent nécessaire de limiter ce que les utilisateurs peuvent faire des contenus numériques. Ils forgent pour cela un ensemble de dispositions appelées DRM (Digital Rights Management, pour 'ménagement (gestion) des droits numériques').

Le DRM verrouille les contenus grâce à ses constituants:

des Mesures Techniques de Protection, dites MTP
Il s'agit de dispositifs (le plus souvent des logiciels) s'assurant que l'utilisateur paie ce que les ayants-droit exigent. Ils sont strictement nécessaires pour accéder aux contenus et intangibles pour l'utilisateur, donc 'blindés' et mis en place de façon à interdire toute intervention de l'utilisateur, ce qui implique que des ayants-droit gèrent une part de son ordinateur.
des lois
Elles protègent juridiquement les MTP en punissant celui qui:
  • les contourne,
  • tente de le faire
  • ou communique les informations pour cela nécessaires

Depuis décembre 2005 un projet appelé DADVSI (Droit d'Auteur et Droits Voisins dans la Société de l'Information) élabore des lois relatives, entre autres, au DRM.

DADVSI menace le logiciel libre[modifier]

Résumé[modifier]

Le projet DADVSI, en l'état, causerait une asphyxie culturelle des utilisateurs de logiciel libre qui pourraient alors se trouver dans l'incapacité d'accéder à certains contenus même s'ils acceptent de payer pour cela. L'emploi d'un environnement logiciel libre causerait donc un isolement culturel qui réduirait son intérêt au point, peut-être, de le condamner.

Utilité du logiciel libre[modifier]

Quasi nul n'ignore aujourd'hui l'utilité, entre autres sur le plan citoyen, du logiciel libre, donc l'intérêt (voire la nécessité) de le ménager. La majorité des favorables à DADVSI reconnut d'ailleurs cela. Une nouvelle disposition le menaçant nécessite un examen attentif.

Le logiciel libre serait isolé et sans recours[modifier]

Le DRM proposé menace le logiciel libre car:

  • rien ne garantit ni ne laisse seulement espérer que les MTP limitant l'accès à certaines oeuvres seront utilisables dans les environnement de l'informatique libre. Les maisons d'édition ne forgeront vraisemblablement pas ces versions adaptées, ne serait-ce que parce que le marché semble aujourd'hui trop restreint et fractionné (de nombreux environnements libres techniquement distincts coexistent), voire à cause d'accords les liant aux éditeurs de logiciels propriétaires souhaitant éliminer ces programmes libres concurrents de leurs produits.
  • l'adoption des textes de loi constituant aujourd'hui (mars 2006) le projet DADVSI interdirait l'analyse des MTP par génie inverse.

Après l'adoption du projet DADVSI les utilisateurs de logiciels libres ne pourraient par conséquent très vraisemblablement plus accéder aux contenus, même s'ils acceptent de payer pour cela.

Par conséquent le DRM aujourd'hui proposé réduit voire annihile la capacité d'un utilisateur de logiciel libre d'accéder aux oeuvres. Il menace en cela une part de l'intérêt des logiciels libres.

Le droit d'auteur, respectueux des intérêts de tous, serait dévoyé[modifier]

On pourrait lire dans ce verrouillage l'exercice, par l'auteur, de son droit de propriété sur son oeuvre. Mais on négligerait ainsi la nature particulière du droit d'auteur qui ménage le patrimoine de l'auteur comme la capacité accordée à tous d'accéder au savoir, celle-là même dont il bénéficia pour créer. Une oeuvre diffère d'un objet en cela qu'interdire d'y accéder enraye la propagation des idées (lire à ce propos 'Internet et droits d'auteur', de Valérie Sédallian).

Laurent Chemla et Pascale Lemoigne l'expriment bien:


Aujourd'hui tout est en place pour qu'Internet soit transformé en gigantesque galerie marchande ultralibérale dans laquelle seuls quelques rares privilégiés pourront continuer à échanger librement du savoir et de l'information:

  • Par le biais de lois complètement déséquilibrées en faveur du droit d'auteur (qui fut créé comme un droit d'équilibre entre l'accès au savoir pour tous et la juste rémunération des auteurs mais qui au fil du temps se transforme au seul profit des ayants-droit).

[ ... ]

  • Enfin par l'adoption par les acteurs les plus importants du marché de la culture (qui souvent cumulent leurs activités de production avec celle de distribution de contenus) de normes permettant de contrôler tout usage qui serait fait de leurs oeuvres, et interdisant la diffusion de toute oeuvre qui ne respecteraient pas ces normes dont ils réservent l'usage à leurs pairs par le jeu des brevets.

DADVSI facilite l'espionnage de l'utilisateur[modifier]

Par ailleurs les MTP recèlent potentiellement des atteintes à la vie privée, par exemple sous forme de sous-programmes espionnant l'utilisateur pour le compte de l'ayant-droit du contenu. Ces sous-programmes indiscrets glaneraient des informations puis les expédiraient lors de l'acquittement de l'octroi, effectué via l'Internet.

délibéré ou pas. pas le cas de tous les softs car, à terme TCPA sans clé pour l'user + filtrage par code opaque d'affluents culturels et informationnels...

DADVSI est une mauvaise réponse technique à une bonne question[modifier]

DADVSI est, sur le plan technique, une mauvaise réponse à une bonne question car l'histoire a prouvé l'inefficacité des MTP, jamais exemptes de défauts de conception ou d'implémentation. DADVSI, d'un même coup, étaye la légalité des MTP et prohibe le génie inverse.

Solution proposée[modifier]

Seule une spécification publique de MTP est vraisemblablement adéquate.

TODO: Le paradoxe à décrire de façon normative et publique des techniques de verrouillage n'est qu'apparent. Le prouvent de façon éclatante les normes RSA et SSL, spécifications ouvertes de chiffrement les plus répandues et considérées comme fiables par les professionnels. Penser aux cadenas.

Contraindre à décrire de façon normative et publique le principe du DRM et un mode d'implémentation est sain car:

  1. cela réduit le risque d'atteinte à l'intégrité de la machine de l'utilisateur (cf. l'affaire du 'rootkit' de Sony, qui incluait tout un dispositif logiciel pour espionner le comportement de l'utilisateur), qu'il soit réalisé de façon délibérée ou non, et réduit par là le risque d'atteinte à la vie privée
  2. Jamais l'opacité n'a été synonyme de sécurité informatique, au contraire (there is no security through obscurity)

Les DRM proposés ne sont pas acceptables. D'autres types de DRM pourraient ménager le logiciel libre mais ceux qu'étayerait l'adoption de DADVSI menacent directement la capacité de logiciels libres à accéder aux oeuvres, et par là leur intérêt et diffusion.

Le logiciel libre ne survivra qu'avec une garantie d'existence d'une implémentation libre des mesures techniques (MTP) employées, qui ne sera elle-même certaine que si les auteurs des MTP doivent la publier.

Il ne s'agit pas ici d'_obtenir_ mais de _résister_ à une menace.

Une 'négociation' s'instaure lorsque chaque partie souhaite obtenir quelque chose. En tant que libristes nous ne voulons rien des DADVSIstes.

Luttons sans merci contre ce qui nous menace et ne composons pas face à une analyse (il semble que ... le gouvernement ne puisse renoncer à cette loi) non étayée et participant surtout d'un jugement émis pas les premiers concernés (des ministres poussant DADVSI and co).

Pour ailleurs nous ne devons pas céder car n'avons pas à endosser les effets de la bêtise ou de la malhonnêteté de qui que ce soit (gouvernants ou administrés). Surtout compte-tenu du fait que nous leur offririons ainsi un moyen de continuer à 'passer en force'.

les contraintes:

  • préserver droits auteurs (ce qui implique des MTP efficaces, pas comme par le passé)
  • préserver le droit d'un auteur, donc la capacité d'un créateur à préserver son patrimoine, sans aménagement du concept de propriété
  • préserver le logiciel libre

Solution proposée: publier, clamer et expliquer partout: "le logiciel libre ne survivra au DRM qu'avec une garantie d'existence d'une implémentation libre des MTP employées, qui ne sera elle-même certaine que si les auteurs des MTP doivent la publier".

faiblesse: MTP correspondante pas encore mise au point (DReaM ??) Extension: TCPA (user maître à bord)

Avec un rien d'optimisme cela ne m'effraie pas car les contenus seront ainsi mieux décantés (? pas de Timisoara pour les libristes ?)

D'autre part, sur le plan du simple génie technique, un principe relevant de la sûreté tout comme son implémentation gagnent à être publiés (there is no security through obscurity). Cette exigence de publication est unanimement reconnue comme la seule réaliste en matière de sécurité informatique et procède du fait qu'un principe (démontration, algorithme) sur lequel repose un solide système de défense est publiable et que le fait même de le faire le renforce car l'expose à la critique donc aux améliorations voire, au pire, à une nécessaire réforme.

En résumé: ne pas publier le principe sur lequel repose un système de défense le rend moins sûr qu'il pourrait l'être.

Par conséquent le principe de MTP doit, pour ménager le logiciel libre mais également la liberté de tous les utilisateurs d'informatique (même propriétaire) ainsi que son efficacité même, être adéquatement et ouvertement documenté. Par 'adéquatement' nous entendons que la spécification doit permettre de développer un logiciel libre de lecture.

Réflexion des DADVSIstes: puisqu'il n'est pas possible de verrouiller de façon techniquement efficace: la loi doit servir de verrou en interdisant de contourner des protections techniques peu efficaces. Le nombre d'agissements illégaux augmentera, or la loi suit l'usage ...?

Ce qui vaut pour les principes reste vrai pour les implémentations.

embarras: implique connexion au réseau voire authentification, mais comment faire payer autrement?

Toutefois même le fait d'exiger ainsi une documentation présente une faille. Elle réside dans une possible 'latence' que cultiveraient les DRMistes en publiant, avec leur implémentation propriétaire, des spécifications insuffisantes ... afin de bénéficier, sur le marché, d'une exclusivité correspondant au délai d'expertise (délai et coût de l'arbitrage de la question "les DRMistes ont-ils publié une documentation adéquate ?", tandis que les utilisateurs de libre ne pourraient accéder au contenu placé sous DRM).

Le moyen le plus efficace de s'assurer qu'une MTP donnée est solide mais sans danger pour le citoyen comme pour le logiciel libre consiste à obtenir publication d'une implémentation correcte sous forme d'un logiciel libre.

TODO: qu'est-ce qu'une implémentation de réf et pourquoi nécessaire (seul moyen de vérifier l'adéquation des spécs publiées)

C'est pourquoi contraindre à documenter le principe de toute MTP ainsi qu'une implémentation de référence est nécessaire.

Or nul ne peut contraindre les tenants du DRM à diffuser une telle "implémentation de référence" de leurs MTP sous forme de logiciel libre.

C'est pourquoi, aujourd'hui, libre et DRM ne sont pas miscibles (tant que les MTP causeront les embarras ici décrits).

(rappel: "le contournement ponctuel pour un usage personnel (passible d'une amende ..."), rendrait tout cela incohérent car chacun aurait alors le droit de tenter de casser (exception d'interopérabilité: droit au génie inverse pour des raisons d'interopérabilité hors de tout contexte économique) mais pas d'employer ou de diffuser le résultat (DADVSI).

Le fait que le code de franchissement de MTP (implémentation du résultat d'un génie inverse) soit ou non baptisé 'logiciel libre' importe peu si DADVSI interdit de l'employer et de le diffuser.

Concurrence du logiciel libre[modifier]

Un communiqué de presse publié par l'éditeur de la distribution Linux nommé 'Linspire':


Linspire is unable to play content that is encoded with Microsoft's Digital Rights Management (DRM) software. Since most online commercial music stores like Napster, Musicmatch and Buy.com implement DRM on all of their files, it is impossible for desktop Linux users to use these sites. Linspire requested a DRM license to complete their support of Windows Media, but was rebuffed by Microsoft, who said they will not license a general computing platform.

"It's disappointing that Linux users are barred from popular music services by Microsoft's unwillingness to license DRM to Linux companies," Robertson said. "Microsoft is clearly trying to use their operating system monopoly to strong-arm control of the music industry and lock out competing Linux companies."


Documents pertinents:

Cela créera des cas difficiles à trancher.

Laisser le conseil de la concurrence démêler tout cela nous desservira car ses membres maîtrisent et (voire 'donc') s'inquiètent beaucoup plus de l'esprit de la loi que des aspects techniques. La plus récente loi (DADVSI) interdira alors d'utiliser et de diffuser du code de franchissement de MTP. Ils statueront "ceux qui tiennent à l'interopérabilité doivent se débrouiller pour ne pas enfreindre la loi, DADVSI compris. La difficulté de l'entreprise ne nous concerne pas." Et hop ! La difficulté majeure passera de notre côté (franchir MTP sans enfreindre loi) alors que, pour le moment, elle se trouve dans l'escarcelle des DADVSIstes (tout le monde leur demande de ménager le logiciel libre, mais ils ne savent comment faire.

Pis: DADVSI descend de l'Europe où la cause de l'incohérence (exception d'interopérabilité) n'est pas reconnue (c'est encore une 'exception française'). L'étape suivante, pour les DADVSIstes, consistera donc, face aux affaires difficiles à juger, à grasseyer "c'est incohérent, DADVSI est récent et aligné sur l'Europe, c'est le sens de l'histoire, zappons la cause de l'incohérence". Il nous faudra alors adopter la 'ligne dure' que je prône, mais il sera trop tard. Adieu l'exception.

Par conséquent DADVSI ne serait OK pour toutes les parties que si ses tenants devaient forger et diffuser une implémentation libre de toute MTP. Le fait qu'ils ne sachent honorer cette exigence (voire que nul ne le puisse, encore que je n'en sois pas convaincu) ne leur permet à mon sens pas de balayer aujourd'hui le libre, de nous contraindre à trouver une solution à leur problème, de négocier notre survie.

la loi doit au mini autoriser les implémentations libres de MTP. Mais ce n'est pas suffisant si les moyens d'obtenir ces implémentations sont illégaux. pour le moment ces moyens ne sont pas illégaux les DRMistes:

  1. développeront les MTP de sorte que leur reverse engineering soit difficile. Ils n'y excelleront pas d'emblée mais peaufineront peu à peu, par exemple en offrant des ponts d'or aux 'casseurs' de leurs codes (success fees: tant que leur code ne sera pas cassé le casseur devenu auteur de MTP touchera)
  2. bouleront celui qui demandera des informations (spécs) afin d'implémenter une version libre, car je ne perçois pas en quoi ce que tu proposes les contraint à l'assister
  3. querelleront ceux qui parviendront à 'casser' et seront confondus, car la décompilation n'est pas autorisée (sauf motif légitime, en pratique laissé à l'appréciation du juge et de l'expert) + DADVSI interdit explicitement le contournement des MTP. Le fait qu'une "application devant légalement comporter des DRM/MTP peut être implémentée en logiciel libre" n'implique nullement que celui qui tentera de le faire outrepassera pour cela impunément d'autres lois.

De toutes façons "ce n'est pas notre problème" car, si nous devons combattre toute implémentation de DRM gênante pour le libre, nous n'avons pas à modifier cette dernière de sorte qu'elle ne le soit plus. Il appartient aux proposants d'une nouvelle disposition (exemple: DRM) de montrer qu'elle ne casse rien d'apprécié (exemple: logiciel libre). Pour le moment ils se contentèrent de déclarer, en substance, "bah, il n'y aura plus de logiciel libre" avant, face aux protestations, de tenter de brouiller le débat sans renoncer aux DRM.

    • autorisation de diffusion du code source
    • specs mises à disposition

Certains proposent qu'une loi (à venir) pose qu'un DRM peut être implémenté sous forme libre. J'ai exposé pourquoi le fait de poser ainsi que c'est possible n'est pas suffisant. Contraindre à publier les spécifications du DRM ne l'est pas davantage. Dans le pire des cas un roublard trouvera peut-être moyen de publier des informations 'permettant' implémentation ... mais à un coût élevé C/ querelleront ceux qui parviendront à 'casser' et seront confondus, car la décompilation n'est pas autorisée (sauf motif légitime, en pratique laissé à l'appréciation du juge et de l'expert) + DADVSI interdit explicitement le contournement des MTP. Le fait qu'une "application devant légalement comporter des DRM/MTP peut être implémentée en logiciel libre" n'implique nullement que celui qui tentera de le faire outrepassera pour cela impunément d'autres lois. Ben si ... il est déjà dans la loi que l'exception d'interoperabilité s'applique (directive de 91) Je doute qu'elle perdure (lire ci-après). Les points A/ et B/ sont acquis mais insuffisants. Grâce à C/ ils le deviendront. C/ dépend de l'adoption de DADVSI. Penses-tu à l'amendement 144 rectifié (http://tinyurl.com/78o22) ? il protège l'étude de ces choses (documentation, recherche). Mais je ne vois pas ce qu'il protège d'autre. En effet. Dans quelle mesure l'amendement 253 (http://tinyurl.com/9vbea), selon lequel l'interopérabilité ne doit pas porter "atteinte aux conditions d'utilisation" ne fait-il déjà pas voler le 144 and co en éclats, surtout en confiant au conseil de la concurrence le soin d'apprécier et de démêler tout cela (en "garantissant la sécurité du fonctionnement des mesures techniques") ? Les DADVSIStes n'auront qu'à attendre les procès, exhiber l'incohérence (droit de diffuser une implémentation de MTP libre, mais pas de la réaliser), souligner que la disposition qui autorise à la réaliser (exception interopérabilité) est plus ancienne et qu'elle n'autorise le génie inverse que pour des raisons économiques, donc qu'il est tout à la fois nécessaire et facile d'assainir tout cela. Une faille, à mon sens, réside toutefois dans une possible 'latence' que cultiveraient les DRMistes en publiant, avec leur implémentation propriétaire, des spécs merdiques ... afin de bénéficier, sur le marché, d'une avance correspondant au délai d'expertise (délai et coût de l'arbitrage de la question "les DRMistes ont-ils publié une documentation adéquate ?", tandis que les utilisateurs de libre ne peuvent accéder au contenu). Avec un rien d'optimisme cela ne m'effraie pas car les contenus seront ainsi mieux décantés (? pas de Timisoara pour les libristes ?) - garantie d'une interopérabilité à 100% - garantir la possibilité d'accéder à *tous* les contenus par tous les moyens connus (ordi, lecteur, etc) sur *toutes* plateformes (OS) Ce que cette garantie rend nécessaire est difficile à énoncer et exiger. Le principe de DRM doit être ouvertement documenté, sinon la capacité à en implémenter (relativement facilement et légalement) une version libre est très menacée. Ta proposition ne préserve à mon sens pas la place du logiciel libre car, mise en pratique, lui interdirait vraisemblablement certains contenus. "on implemente les DRM en logiciel libre" impossible à mon sens car qui pourrait nous empécher de modifier le programme en question pour détourner le flux au moment où il est en clair pour le stocker en clair ? Du hard, qui: - 'marquerait' à mesure le flux afin de pister les fautifs - s'accorderait avec le périphérique de restitution de sorte que le détournement du signal communiqué implique expertise et hard onéreux

Qui est propriétaire d'une machine sous DRM?[modifier]

comparatif des licences logicielles


L'intégration de la gestion des droits numériques (DRM) dans Windows implique que la société Microsoft peut à tout moment révoquer votre droit d'accés aux contenus sécurisés si elle considère votre logiciel compatible-DRM compromis. Une liste de logiciels révoqués est automatiquement installée sur votre ordinateur à chaque téléchargement de contenus sécurisés. Une mise à jour de votre logiciel compatible-DRM est alors nécessaire pour continuer à accéder à vos fichiers sécurisés. Cette révocation n'empêche cependant pas l'accès à des contenus non protégés par les DRM.


Lire à ce propos À qui obéit votre ordinateur ? (Laurent Bloch)

Ressources et points de vues complémentaires[modifier]

  1. DReaM
  2. DADVSI, le film
  3. Lessig, Stallman on 'Open Source' DRM
  4. DRMS et logiciels libres / DRMs and free software (P. Aigrain)
  5. EUCD.info
  6. formats-ouverts.org
  7. Framasoft
  8. Complément d'enquête sur DADVSI: pressions anti républicaines et amalgames pervers (F. Couchet)
  9. DRM is a complete lie
  10. Le dadvsi pour les nuls (ODEBI)
  11. Dadvsi: les défenseurs du logiciel libre s'inquiètent des amendements du Sénat
  12. L'amphibologie fondamentale du droit"
  13. DADVSI v2.0 - Toujours autant de risques pour les logiciels libres (Gilles Gravier)
  14. The big DRM mistake
  15. DRM More Important Than Life or Security?
  16. Nouveau jugement P2P explosif
  17. Post Scriptum à Monsieur Eddy Mitchell (R. Di Cosmo)
  18. Comment j'ai perdu ma musique légale (J. Colombain)
  19. La Cour de cassation française restreint le droit à la copie privée de DVD
  20. Interassociation Archives-Bibliothèques-Documentation
  21. Licence globale : le paradoxe démocratique !
  22. DRM, 'Trusted Computing', and the Future of Our Children
  23. À qui obéit votre ordinateur ? (Laurent Bloch)
  24. Dangers des DRM (T. Nitot)
  25. lestelechargements.fr : blog indépendant d'information sur la loi DADvSI, les DRM et les téléchargements
  26. A conversation with Cory Doctorow
  27. National Consumer Council (UK) submission to The All Party Internet Group inquiry into Digital Rights Management
  28. DADVSI bientôt...
  29. DADVSI, DRM, logiciel libre : quelques explications
  30. Le problème est purement économique
  31. Communiqué de presse d'acteurs du logiciel libre
  32. A New French Revolution?
  33. prise de position de la Conférence des Présidents d'Université et des Directeurs de Bibliothèques Universitaires sur l'"exception pédagogique"
  34. Dossier DADVSI
  35. DRM on Linux
  36. DReAM
  37. DRM sous Linux
  38. Is DRM Just a Consumer Rights Issue?, DRM and Democracy
  39. Loi DADVSI : Le conseil constitutionnel a rendu sa décision