Lettre ouverte à Bill

Posté par  . Modéré par Fabien Penso.
Étiquettes : aucune
0
22
oct.
2001
Justice
D'après la directive européenne 91/250/CEE du Conseil datée du 14 mai 1991, il est autorisé d'effectuer un "reverse engeenering" de composants logiciels :

« Les opérations de chargement et de déroulement nécessaires à l'utilisation d'une copie d'un programme légalement acquis, ainsi que la correction de ses erreurs, ne peuvent pas être interdites par contrat; que, en l'absence de clauses contractuelles spécifiques, notamment en cas de vente d'une copie du programme, toute autre opération nécessaire à l'utilisation de la copie d'un programme peut être effectuée, en conformité avec son but prévu, par un acquéreur légal de cette copie »

j'en passe et des meilleures :) Enfin, lisez quand meme le texte de loi avant de faire n'importe quoi, merci ...

Note du modérateur: il s'agit d'une lettre ouverte sur le site Advogato d'un développeur qui demande à Bill de lui laisser accéder aux spécifications de certains standarts fermés de Windows pour les rendre intéropérables avec d'autres systèmes.

Aller plus loin

  • # Vérifiez votre droit ! Donc tais-toi!!!

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    «Les opérations de chargement et de déroulement nécessaires à l'utilisation d'une copie d'un programme légalement acquis, ainsi que la correction de ses erreurs, ne peuvent pas être interdites par contrat». Et même mieux puisque tout contrat qui repose sur des clauses hors-la-loi est automatiquement contestable juridiquement. Ce qui signifie que toute personne qui se prend un procès à cause de ce genre de clause gagne automatiquement.
    Fallait rien dire, tu gagnais à tout les coups! Quel con...
  • # Retro-ingénierie != spec ouvertes

    Posté par  (site web personnel) . Évalué à 5.

    Autant je trouve normal que le reverse-engineering soit autorisé à des fins d'interopérabilités (ex: lire des DVD achetés très chers et faire péter la protection pour les lire sur un système libre), autant il ne faut pas abuser et demander les spécifications d'un protocole fermé (on va pas demander à la RIAA de nous filer la clé de décryptage).
    • [^] # Re: Retro-ingénierie != spec ouvertes

      Posté par  . Évalué à 4.

      Il ne faut pas confondre filer une clé de décryptage et documenter un protocole.

      La documentation de protocole n'interfère en rien avec une confidentialité : PGP est un standard ouvert offrant une bonne sécurité !
      • [^] # Re: Retro-ingénierie != spec ouvertes

        Posté par  (site web personnel) . Évalué à 9.

        Tant que les entreprises croiront que garder le secret de leurs protocoles propriétaires leur assure un quelconque avantage, elles ne vont sûremement pas te donner les spécifications.C'est le même problème que pour les trous de sécurité, certains croient que le fait de pas les divulguer augmentera la sécurité de leurs produits.

        Et PGP et DeCCS n'on pas grand chose à voir : autant il est possible d'assurer la confidentialité d'une communication entre deux parties, autant crypter une émission diffusée en broadcast (comme Canal sat, ou un DVD) à destination d'un nombre important de clients relève de l'utopie Pour cette raison la non divulgation du protocole de cryptage met un frein (léger) au piratage. Ce n'est pas demain que C+ te filera les spec completes de son décodeur.
        • [^] # Re: Retro-ingénierie != spec ouvertes

          Posté par  (site web personnel) . Évalué à 2.

          Ce n'est pas demain que C+ te filera les spec completes de son décodeur
          Mais alors, il n'est pas brevete. En effet, pour deposer un brevet il faut fournir les specs completes de ton produit. Une personne n'il connaissant rien doit pouvoir en fabriquer un.

          Comme tout systeme de cryptage, sa force reside dans la clef et non le systeme. C'etait d'ailleurs la faiblesse d'Enigma le systeme de cryptage allemand pendant la seconde guerre mondiale.
          (cf http://www.enseignement.polytechnique.fr/profs/informatique/Jean-Ja(...) )

          Le procede Nagravision servant a crypter les emissions de C+ est connu de tous.

          Pour ceux interesse par les problemes de TV a peage un bon livre :
          European Scrambling Systems de John McCormac.
        • [^] # Re: Retro-ingénierie != spec ouvertes

          Posté par  (site web personnel) . Évalué à 2.

          Le fait de donner les spécifications n'est pas forcément suffisant. J'en prends pour exemple le protocole IPMI (Intelligent Platform Management Interface) développé par Intel qui permet de récupérer les informations des senseurs des cartes mères serveurs :
          Des Specs complètes (plus de 350 pages) ont été publiées et sont accessibles quasi-librement depuis le web.
          Des projets libres ont donc vus le jour (notamment à l'initiative de VA Linux). Et tous s'est bien passé jusqu'à il y a 4 mois où toutes les nouvelles machines sorties des usines ne réagissait plus correctement au soft développés.
          La raison : il y avait 10 Lignes dans les 350 pages qui laissait au constructeur la lattitude de faire ce qu'il voulait à un certain endroit (structure de données libres). Intel s'y est engouffré une fois son protocole fortement implanté et tous les projets libres sont devenus inutilisables.
    • [^] # Re: Retro-ingénierie != spec ouvertes

      Posté par  . Évalué à 1.

      Pourtant cette clef de decryptage il vont bien la filer (vendre) aux fabricants d'appareils domestiques, et autres editeurs de logiciels.

      Ce qui est fondamentalement mauvais dans la protection des médias (cd audio, dvd, k7...) c'est que la fonction meme de ces média est de livrer les données à l'utilisateur final. crypter ces données c'est aussi donner les moyens de les décrypter pour les utiliser, ce qui ramène obligatoirement à la case départ: l'utilisateur à accès aux données qu'il vient d'acheter, et le cryptage n'a servi à rien [sinon vendre des clefs :-))].

      Microsoft n'est pas obligé de filer les specs de ses modifications du protocole kerberos ( ? ,c'est une question !), si il ne veut pas que les autres machines puissent communiquer avec les siennes (par contre, on pourrait interdire à MS d'utiliser le terme kerberos dans la mesure ou il s ne sont pas 100% clients kerberos), par contre la RIAA ne vends pas les apareils de lecture, il faut donc bien qu'elle vende des clefs de decryptage !!
      • [^] # Re: Retro-ingénierie != spec ouvertes

        Posté par  . Évalué à 3.

        Microsoft n'est pas obligé de filer les specs de ses modifications du protocole kerberos ( ? ,c'est une question !), si il ne veut pas que les autres machines puissent communiquer avec les siennes

        Il n'est pas obligé, mais alors il ne peut t'empêcher de faire du reverse engineering pour faire communiquer tes logiciels avec les siens, ni de rendre tes résultats publics (quoique je soit pas sûr à 100% là-dessus, qqn pour confirmer/infirmer ?), ni de distribuer une application/bibliothèque/autre pour permettre aux gens de communiquer de la même manière avec les logiciels de MS.
        • [^] # Re: Retro-ingénierie != spec ouvertes

          Posté par  . Évalué à 6.

          en fait MS utilise pour on ne sais quoi un octet qui était marqué "pour utilisation future" dans le protocole kerberos. Bien sûr ils n'ont pas documenté ni expliqué le besoin qui ne peut donc pas être ajouté dans le protocole kerberos officiel.
          Résultat: si le serveur kerberos est celui de MS, les clients kerberos habituels fonctionnent (sans cet octet) et les clients MS aussi (avec cet octet).
          si le serveur est une machine unix, les clients MS ne fonctionnent plus.

          L'équipe kerberos avait émis la possibilité d'utiliser cet octet pour autre chose histoire de rendre les protocoles completement incompatibles et couper l'herbe sous le pied de MS ... ils ne l'ont pas fait.

          Dans cette affaire, ce qui m'horripile le plus c'est que quand MS utilise un protocole ouvert et documenté ... il s'arrange pour s'octroyer le marché des serveurs quand même !!
          • [^] # Re: Retro-ingénierie != spec ouvertes

            Posté par  (site web personnel) . Évalué à 7.

            c'est justement dans ce cas précis que le reverse-ingeenering s'avère nécessaire.

            Cet exemple montre bien :
            1- l'intérêt d'avoir accès au source (de quelque manières que ce soit).
            2- comment krosoft s'y prend pour phagocyter un standard ouvert et tenter de le transformer en standard porpiétaire...

            Le reverse-engeenering permettra de découvrir que l'octet en question ne sert à rien si ce n'est à faire planter les clients MS quand il n'est pas là ! (bon là j'extrapole complétement :)))
          • [^] # Re: Retro-ingénierie != spec ouvertes

            Posté par  . Évalué à 1.

            Quedalle, MS utilise le champ "Vendor defined", et vu le nom, je te laisse deviner a quoi sert ce champ: justement ce que MS a mis dedans, des trucs definis par le vendeur, dans ce cas MS.
            • [^] # Re: Retro-ingénierie != spec ouvertes

              Posté par  . Évalué à 0.

              Ca ne change rien au probleme. Si les clients MS ont besoin qu'il soit conforme à une spec non documentée de MS, c'est une propriétarisation de la norme.
              • [^] # Re: Retro-ingénierie != spec ouvertes

                Posté par  . Évalué à 1.

                Ben vois-tu, le probleme est que MS devait stocker quelque part les ACL de Windows, qui ont pas vraiment la meme gueule que les permissions Unix, ils les ont mis la, car c'etait le meilleur endroit pour ca.

                Je vois pas vraiment ce qu'ils auraient pu faire d'autre, rien d'autre n'est prevu dans Kerberos pour cela.
                • [^] # Re: Retro-ingénierie != spec ouvertes

                  Posté par  . Évalué à 0.

                  Je vois pas vraiment ce qu'ils auraient pu faire d'autre, rien d'autre n'est prevu dans Kerberos pour cela.

                  Kerberos ne concernait que les OS dignes de ce nom ?

                  MS en a détourné l'utilisation, si tu ajoutes des choses à une norme tu la propriétarises, point. Si Windows n'est pas capable d'utiliser Kerberos en le respectant, c'est le probleme de Windows.
        • [^] # droit au reverse et publication

          Posté par  . Évalué à 4.

          ce droit tu l'as pour l'instant

          tant que les brevets ne seront pas passé
          en Europe.

          Après celà, ce sera comme aux us: procès en cascade, découragement, pressions, prison, amendes, etc.
    • [^] # mais bien sur que SI ! il faut abuser

      Posté par  . Évalué à 2.

      autant il ne faut pas abuser et demander les spécifications d'un protocole fermé (on va pas demander à la RIAA de nous filer la clé de décryptage)

      Et notre droit à la copie de sauvegarde
      qu'est-ce que tu en fais!?

      Aussi bien pour la PS2 que pour les dvd quasi illégalement zonés, tu as le droit de péter toutes les clefs que tu veux puisque c'est dans un but
      de copies (3) de "sauvegarde", légalement autorisées.

      Que dire du petit producteur qui sort son film (zoné 1) qui ne PEUT (sans rétribuer les distributeurs de la zone 2) nous montrer son oeuvre ?
      J'appelle ça un scandale, une sous-culture, big brother, la peste; le tout réuni.

      En instaurant cette clef, on nous a retiré ce droit à la copie.

      ps: la prochaine étape : les brevets pour protéger cette clef...
      • [^] # Re: mais bien sur que SI ! il faut abuser

        Posté par  . Évalué à 1.

        En fait, si j'ai tout bien compris ce que m'a explique mon prof de droit, le droit de copie de sauvegarde ne signifie pas que tu a le droit de faire tes propres copies de sauvegardes. Simplement, si l'editeur t'interdit la possibilite de les faire toi-meme, cela signifie qu'il s'engage implicitement a te fournir une nouvelle copie lorsque tu lui adresse une demande motivee (genre un support endommage...)

        En tout cas, les cours de droits informatique en ecole d'ingenieur, c'est une bonne chose : tu te rends compte a quel point les avocats peuvent te mettre dedant simplement en jouant sur les mots lorsqu'ils ont la loi contre eux.

        Et tu te rend compte egalement que dans certaines licences (genre M$ pour ne pas les cites), une bonne partie des clauses sont nullescar contrraire au droit francais. Ils le savent parfaitement mais ils les laissent pour faire peur aux 99,9% des utilisateurs qui ne sont pas au courantdes textes de loi OU qui ne comprennent pas leur implication en informatique
  • # pour le modérateur: paradoxe

    Posté par  . Évalué à 1.

    ...accéder aux spécifications de certains standarts fermés de Windows...

    ceci est un paradoxe car par définition
    un standard n'est pas fermé.

    (sans parler du fait que windows n'utilise aucun standard ;) )
    • [^] # Re: pour le modérateur: paradoxe

      Posté par  (site web personnel) . Évalué à 7.

      Un standard peut etre fermé. Exemple : certains protocoles utilisés par H323 (téléphonie sur IP) suivent les recommandations ITUT qui sont des documents payants, donc non ouverts.
    • [^] # Re: pour le modérateur: paradoxe

      Posté par  . Évalué à 0.

      Un peu trollesque, mais tellement vrai...

      Effectivement, un standard fermé, ça fait bizarre.
    • [^] # Re: pour le modérateur: paradoxe

      Posté par  . Évalué à 3.

      Etre un standard, celà signifie être l'implémentation de référence, la plus répendue, celle qui est incontournable. Ca ne veut pas dire que cette implémentation est documentée.

      Par exemple, le format .doc est le standard de fait en matière de fichiers issus de traîtement de textes, ce qui ne veut pas dire que l'ensemble des fonctionnalités soient documentées.

      Et même lorsque le standard est documenté, ça ne veut pas dire que la documentation est en libre accès. Par exemple, si tu veux un exemplaire du standard ISO des langages C ou SQL, il faudra payer (et c'est cher!).

      A contrario, les RFC sont des exmples de standards ouverts: en général un RFC décrit un standard, et il est librement consultable.
      • [^] # Re: pour le modérateur: paradoxe

        Posté par  . Évalué à -1.

        Bah non, le standard *doit* etre ouvert. Les .doc, c'est pas standard.
        • [^] # Re: pour le modérateur: paradoxe

          Posté par  . Évalué à 2.

          Je pense que tu confonds norme et standard.
          Une norme spécifie un certains nombre de règles permettant à quiconque de l'implémenter (TCP/IP, HTML, XML...). Une norme à bien pour volonté de devenir un standard. Par contre, un standard n'est pas obligatoirement une norme. c'est un état de fait: mon produit ou mon format de fichier est extremement répandu et utilisé par la grande majorité des gens. La nuance n'est pas si mince...

          Denis
          • [^] # Re: pour le modérateur: paradoxe

            Posté par  . Évalué à 1.

            Il y a une différence entre norme et standard, mais ce n'est pas celle là.

            Une norme n'est pas forcément un standard dans le sens où n'importe qui peut s'amuser à en faire une, ouverte et tout, mais s'il est le seul à l'utiliser et que les autres ne savent pas où la trouver et qu'il n'existe pas de logiciel approprié pour l'utiliser, elle ne sert pas à grand chose. Dans ce cas ce n'est pas un standard.

            Un standard est lui lié à une norme. La norme associée doit etre suffisamment ouverte, répandue (spec connue, logiciels l'exploitant). Le .doc n'est pas standard parce qu'il n'est pas lisible partout, il manque des logiciels sur certaines plateformes et les specs ne sont pas toutes données rendant certains documents illisbles pour d'autres logiciels que Word. Le PDF par exemple, meme s'il est moins répandu, a les memes caractéristiques + des logiciels partout et une spec totalement ouverte. Lui, est standard.

            Donc je pense, pour ma part, que tu confonds standard et répandu. L'aspect "répandu" jouant néanmoins beaucoup sur le caractère standard.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.