Page 7 sur 8Précédent 1 ... 4, 5, 6, 7, 8 SuivantALERTE! SNEP SCPP SACEM veulent interdire le libre carrément

[desesperatly]

Ce n'est pas parce qu'un DRM est incompatible avec une divulgation du code source qu'il ne peut pas exister de DRM ouvert, dont les spécifications sont publiques (cf. le projet DREAM de Sun).

Des développeurs de logiciel libre pourront accéder à l'ensemble des infos sur le fonctionnement du logiciel... à condition d'accepter l'obligation d'assurer la sécurité du système (et donc de fermer le code source aux utilisateurs).

Peu importe. Je vous laisse vous bercer d'illusions...

[Téthis]

Des développeurs de logiciel libre pourront accéder à l'ensemble des infos sur le fonctionnement du logiciel... à condition d'accepter l'obligation d'assurer la sécurité du système (et donc de fermer le code source aux utilisateurs).

Il faut que tu révises ta conception d'un logiciel libre, ainsi que celle liée à la sécurité du système en utilisant l'obscurantisme.

On pourra patcher le kernel ou les libs liées afin qu'ils agissent différement et fassent sauter les limitations des licences de ces DRMs. On pourra donc agir sur ces DRM en modifiant le code quelque part ailleurs. Ce serait, devant ce projet de loi, la même chose que de modifier le source du programme : on détourne la protection. Alors il est où l'intérêt d'ajouter du code obscure afin de préserver "la sécurité du système" ? Les DRMs sont en grande partie inefficaces sans implémentation hardware. Aucun tour de magie ne pourra transformer un programme en un programme anti-DRM proof de façon software.

Mettre du code non libre (sous forme binaire) dans un logiciel libre afin de preserver un système de gestion de droit est une connerie sans nom car on détruit petit à petit ce qu'est le Libre sans rien assurer du tout dans la sécurité du système.

Je te laisse à ta réflexion.

[desesperatly]

Des développeurs de logiciel libre pourront accéder à l'ensemble des infos sur le fonctionnement du logiciel... à condition d'accepter l'obligation d'assurer la sécurité du système (et donc de fermer le code source aux utilisateurs).

Il faut que tu révises ta conception d'un logiciel libre, ainsi que celle liée à la sécurité du système en utilisant l'obscurantisme.

Justement, le principe de Kerckhoffs est parfaitement compatible avec un DRM ouvert (mais pas avec un DRM open source).

On pourra patcher le kernel ou les libs liées afin qu'ils agissent différement et fassent sauter les limitations des licences de ces DRMs. On pourra donc agir sur ces DRM en modifiant le code quelque part ailleurs. Ce serait, devant ce projet de loi, la même chose que de modifier le source du programme : on détourne la protection. Alors il est où l'intérêt d'ajouter du code obscure afin de préserver "la sécurité du système" ? Les DRMs sont en grande partie inefficaces sans implémentation hardware. Aucun tour de magie ne pourra transformer un programme en un programme anti-DRM proof de façon software.

Personne ne doute que la technique est faillible (surtout en soft). C'est d'ailleurs pour cela que le projet de loi, en transposition de l'article 6 de la directive DADVSI, interdit le contournement d'une mesure technique de protection et le sanctionne pénalement, de même que la mise à disposition de moyens de contournement. Mais c'est un débat qui n'a rien à voir.

[Téthis]

Justement, le principe de Kerckhoffs est parfaitement compatible avec un DRM ouvert (mais pas avec un DRM open source).

J'ai du mal à saisir ce que tu veux dire. Si un système est ouvert, il y a possibilité de l'implémenter de façon open-source, sauf si un accord doit être passé restreignant son usage (cf adobe, ses spécifications flash et, entre autre, son interdiction de faire un player flash).
En finalité, on se retrouve toujours avec un morceau de papier qui va protéger un système de gestion de droit. Alors pourquoi casser (tainted) le Libre avec du non Libre ?

Personne ne doute que la technique est faillible (surtout en soft). C'est d'ailleurs pour cela que le projet de loi, en transposition de l'article 6 de la directive DADVSI, interdit le contournement d'une mesure technique de protection et le sanctionne pénalement, de même que la mise à disposition de moyens de contournement. Mais c'est un débat qui n'a rien à voir.

Si la loi est bien faite, et qu'elle protège le système qui protège les intérêts des ayant-droits, pourquoi ne pas faire un système DRM à code ouvert mais avec des restrictions (par exemple interdiction de le modifier). Libre à nous d'ajouter ces programmes DRMisés en sachant qu'ils ne vont pas nous faire des bébés dans le dos en fricotant avec des majors. Cette solution est la moins pire des solutions.

Fais la différence entre Libre et Open Source.

[desesperatly]

Justement, le principe de Kerckhoffs est parfaitement compatible avec un DRM ouvert (mais pas avec un DRM open source).

J'ai du mal à saisir ce que tu veux dire. Si un système est ouvert, il y a possibilité de l'implémenter de façon open-source, sauf si un accord doit être passé restreignant son usage (cf adobe, ses spécifications flash et, entre autre, son interdiction de faire un player flash).

ça passe effectivement par des accords. Si le système est ouverts, les licences sont accordées dans des conditions équitables et non discriminatoires (ce qui n'est pas le cas, par ex, de Fairplay).

En finalité, on se retrouve toujours avec un morceau de papier qui va protéger un système de gestion de droit. Alors pourquoi casser (tainted) le Libre avec du non Libre ?

C'est au cas où l'amendement passerait. Ce serait une parade à mon sens acceptable.

Si la loi est bien faite, et qu'elle protège le système qui protège les intérêts des ayant-droits, pourquoi ne pas faire un système DRM à code ouvert mais avec des restrictions (par exemple interdiction de le modifier). Libre à nous d'ajouter ces programmes DRMisés en sachant qu'ils ne vont pas nous faire des bébés dans le dos en fricotant avec des majors. Cette solution est la moins pire des solutions.

Des systèmes de DRM avec un code ouvert seront très facilement contournables (même si ceux à code fermé le sont aussi; mais ils le sont quand même moins facilement). Le problème est que certains auteurs ne voudront pas que leurs oeuvres soient distribuées sur ces logiciels avec ce type de DRM qui, au fond, ne sera efficace qu'autant que les utilisateurs s'autocontrôleront et joueront le jeu. Et je ne crois pas que l'on ait à imposer cela aux auteurs qui ne le souhaitent pas.

L'amendement pose effectivement des problèmes pour les logiciels libres "communiquants" (mais pas pour les autres, comme on le lit beaucoup ici).

[dana]

dana a écrit:
mais faudra retaguer tous nos fichiers avec des DRM "libres"


Mon dieu ! Il y a de quoi faire une révolution ! On veut nous obliger à retaguer nos fichiers !
Jamais l'atteinte aux libertés individuelles n'avait atteint un tel sommet...

heu
est-ce que j'ai dit ça ?
le "mon dieu" c'est pour le boulot que ça va occasionner de retaguer et de reuploader environ 500 fichiers
en espérant que ça ne coûte rien
(je m'occupe d'un label si tu veux savoir)
enfin bon
restons calme...

[joshua]

Ce n'est pas parce qu'un DRM est incompatible avec une divulgation du code source qu'il ne peut pas exister de DRM ouvert, dont les spécifications sont publiques (cf. le projet DREAM de Sun).

Des développeurs de logiciel libre pourront accéder à l'ensemble des infos sur le fonctionnement du logiciel... à condition d'accepter l'obligation d'assurer la sécurité du système (et donc de fermer le code source aux utilisateurs).

Peu importe. Je vous laisse vous bercer d'illusions...

le projet dream, les source sont entierement accessibles...

http://sourceforge.net/project/showfiles.php?group_id=71084

[Nico]

il y a l'exception légale d'interopérabilité, qui permet de faire de l'ingénierie inverse (reverse engineering) pour assurer son adaptation. Dès lors que c'est pour assurer à VLC la possibilité d'avoir accès à la technologie des DRM, on ne pourrait leur opposer qu'ils facilitent le contournement d'une mesure technique de protection, puisqu'au contraire il s'agirait d'ajouter à leur logiciel la gestion des DRM

C'est valable uniquement en droit français, ou y-a-t-il un équivalent dans la plupart des pays ?

[desesperatly]

il y a l'exception légale d'interopérabilité, qui permet de faire de l'ingénierie inverse (reverse engineering) pour assurer son adaptation. Dès lors que c'est pour assurer à VLC la possibilité d'avoir accès à la technologie des DRM, on ne pourrait leur opposer qu'ils facilitent le contournement d'une mesure technique de protection, puisqu'au contraire il s'agirait d'ajouter à leur logiciel la gestion des DRM

C'est valable uniquement en droit français, ou y-a-t-il un équivalent dans la plupart des pays ?

C'est valable partout en Europe (directive 91/250/CEE sur les programmes d'ordinateur).
Et en même temps, ce n'est pas valable car il y a conflit de normes. Mais ça a l'air d'être un beau merdier. J'ai lu un article là dessus quelque part, sur un site web traitant de la question. Je vais voir si je retrouve l'adresse.

[leto_2]

Et en même temps, ce n'est pas valable car il y a conflit de normes.

ça mérite plus d'explications pour juger de la pertinence de ton affirmation.