Journal Que faire des formats propriétaires qui n’aiment pas l’interopérabilité?

Posté par  . Licence CC By‑SA.
47
28
nov.
2014

l y a une quinzaine de jours j’ai présenté le logiciel Open source Joker que je développe au sein de ma société Phonations.

Il importe de noter que la nature open-source de mon logiciel le distingue radicalement des logiciels existants, ainsi que son interopérabilité avec les logiciels disponibles sur le marché.
Lors du traitement d’un fichier de l’un de ces différents fournisseurs, nous avons eu la désagréable surprise de constater il y a une semaine, que le concepteur du logiciel Mosaic, s’érigeant en concurrent, encrypte son format de fichier pour lutter contre cette interopérabilité, visant une situation de monopole absolument préjudiciable à l’économie du marché de niche que sont les activités de doublage et de postsynchronisation.

Les conséquences sont en effets des plus regrettables :

  • Je suis pénalisé dans mon développement : les projets d’installation de Joker chez des clients qui en avaient manifesté le désir sont maintenant obsolètes. On pourrait admettre que ce sont les dures lois de la concurrence, mais hélas la profession déjà fragile voit ses ressources se déstabiliser davantage :
  • Les adaptateurs ayant acheté une licence de ce logiciel pouvaient travailler pour une quarantaine de studio (30 sur Mosaic et 10 sur Joker). Leur base de clients potentiels se voit donc réduite de 25 % (je précise que ces chiffres sont une estimation).
  • Les studios équipés de Joker qui avaient la capacité faire travailler n'importe quel auteur voient leur base de fournisseur réduite de 50 % Cet abus de position sociale de la part du concurrent m’invite à chercher des solutions au plan technique et juridique.

Existe-t-il des solutions de décompilation mobilisant des puissances de calcul restant à ma portée de développeur indépendant ?
En matière légale, on peut penser que la loi française soit de mon côté puisque le document de l'April semble bien préciser que si faire de la rétroingénierie sur un logiciel est interdite, elle est autorisée en France si c'est dans le but d'assurer l'interopérabilité de données (http://wiki.april.org/w/Synth%C3%A8se_interop%C3%A9rabilit%C3%A9).
Évidemment il reste aussi la solution du dénigrement systématique et autres manœuvres politiques déplaisantes, mais j’aimerais les éviter pour consacrer plus utilement mon temps à l’avancée de la technique profitant à l’ensemble de la communauté.

Merci d’avance de vos lumières.

  • # problème à la base

    Posté par  . Évalué à 7.

    Pourquoi cela n'a-t-il pas été envisagé avant? Parce que ce problème est visiblement une grosse barrière d'entrée dans ce business…

    La demande de libération des fichiers devrait venir des clients de Mosaic. Côté technique je ne sais pas si c'est autorisé de craquer une clé de chiffrement pour récupérer le contenu (le format est connu?) d'un fichier. C'est un terrain assez risqué, ils peuvent porter plainte contre toi et te couler financièrement - même s'ils sont en tord - en faisant durer les procédures.

    Bonne chance

    Je trolle dès quand ça parle business, sécurité et sciences sociales

    • [^] # Re: problème à la base

      Posté par  . Évalué à 2.

      Bien sûr que ce problème me pendait au nez. J'ai déjà réussi à décoder 3 formats propriétaires binaires/xml/sqllite avec plus ou moins de facilité. Là par contre le fait que ça semble crypté monte la barre de la difficulté d'un cran car je n'ai aucune expérience en cryptographie. Après c'est une question de temps et de financement de ces travaux car actuellement je n'ai ni l'un ni l'autre. C'est pour ca que j'interroge la communauté pour essayer de me sortir de là.

      Merci de votre aide!

    • [^] # Re: problème à la base

      Posté par  . Évalué à 4.

      je ne sais pas si c'est autorisé de craquer une clé de chiffrement pour récupérer le contenu (le format est connu?) d'un fichier.

      Admettons que ce soit interdit. Ou du moins que l'auteur ne souhaite pas prendre de risque.
      Il « suffit » que Joker possède le nécessaire pour déchiffrer de manière générique (par exemple un mécanisme de greffon), et qu'un vilain pirate diffuse le bon greffon. Rhooo, pas de bol, Joker est 100% légal.
      Vilain pirate, pa bô, méchan.

      Sérieux, je serais client de Mosaic, je me sentirais vaguement empapaouté. C'est une manoeuvre utilisée exclusivement par ceux qui n'ont rien de mieux que la concurrence. Donc leur produit ne vaut rien par rapport à Joker ? J'en doute.

      note : c'est forcément un chiffrement symétrique, donc la clef et l'algo sont dans Mosaic. Après, je sais juste ouvrir ma bouche à ce propos, je ne sais pas aller chercher l'information.

      • [^] # Re: problème à la base

        Posté par  . Évalué à 1.

        Oui il peut jouer au plus malin :-). Si le concurrent est un peu taquin ça va être une procédure judiciaire à la clé et le temps passé à se défendre c'est du temps perdu côté développement de son entreprise.

        Je trolle dès quand ça parle business, sécurité et sciences sociales

  • # Commentaire supprimé

    Posté par  . Évalué à 2.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Va t'asseoir au bord de la rivière

      Posté par  . Évalué à 1.

      Oui de toute façon au niveau potentiel, le fait que Mosaic fonctionne uniquement sur Windows est déjà un sacré aveu de faiblesse :-)

    • [^] # Re: Va t'asseoir au bord de la rivière

      Posté par  . Évalué à 7.

      Et tu verras passer leur enseigne :)

      Pas forcement

      un exemple que j'ai vu d'assez près : les ENT¹ scolaires doivent permettre l'import des données issues des logiciels d'emploi du temps. Il existe deux logiciels (propriétaires mais passons) sur le marché. L'éditeur de l'un des deux propose aussi un ENT complet et chiffre les fichiers de données.

      Les ENT concurrents sont obligés à des acrobaties douteuses pour assurer cette fameuse interopérabilité. La dernière trouvaille consiste à passer par une impression PDF des emplois du temps suivie de l'analyse des fichiers. Foirage si les marges et les cases n'ont pas la «bonne» taille.

      Cela fait quelques années que cela dure, que ça râle et que le chiffreur fou se porte très bien…

      ¹ espace numérique de travail

  • # reverse

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

    Pour ne pas tomber dans la copie illégal de code, il faut respecter plusieurs points :
    - avoir fait une demande de spécification du format de fichier, en cas de refus, le reverse n'est plus illégal
    - faire le reverse de préférence en séparation : une personne écrit une spec à partir du reverse et une autre implémente la spec, c'est le moyen le plus simple pour ne pas se faire accuser de contrefaçon.

    Lors du reverse, il faut avoir une licence légal du logiciel, lors de l'affaire Tegam, c'est ce qui avait été reproché par la justice.

    Si le fichier est crypté, pour une personne ayant l'habitude, cela ne devrait pas être compliqué de trouver la méthode de décryptage. Mais es-tu sûr qu'il ne s'agit pas simplement d'un format binaire ?

    "La première sécurité est la liberté"

    • [^] # Re: reverse

      Posté par  (site web personnel) . Évalué à 8. Dernière modification le 28 novembre 2014 à 22:17.

      faut avoir une licence légal du logiciel, lors de l'affaire Tegam, c'est ce qui avait été reproché par la justice.

      surtout le fait qu'il ait publié la décompilation, considérée comme un dérivé du produit initial. Ne pas en avoir la licence n'a fait qu'aggraver. C'est la contrefaçon qui a été retenue, outre le fait qu'il n'avait pas de licence.

      Pour quelqu'un étant en France, la rétro-ingénierie à des fins d'interopérabilité reste légale (et ton conseil de demander les specs du fichier au préalable tombe au coin du bon sens).

      Le tout est de ne publier que des fichiers sur lesquels tu as les droits d'auteur… ça va sans dire, ça va mieux en le disant.

      Si c'est un système de gestion des droits numériques, le DMCA s'est décliné en France en DADVSI et HADOPI qui peuvent être gênantes, même si le simple fait de contourner la protection éventuelle est bien l'évidence qu'elle n'est pas efficace.

      Autant promouvoir un format ouvert, vu que c'est l'un des rares apports de la LCEN… auprès de tes clients, un peu de pédagogie (sans dénigrement du concurrent) pour montrer les apports.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 3.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: reverse

        Posté par  . Évalué à 4.

        Merci pour ces remarques constructives. Je vais faire la démarche de demande d'ouverture du format (même si je ne suis pas très optimiste).
        En parallèle, des groupes d'utilisateurs ce sont formés sur facebook pour échanger truc et astuce, et dépanner les copains. J'ai intégré ces groupes et tente d'apporter mon aide. J'espère obtenir le soutien des utilisateurs de ce logiciel par la suite.
        Sinon concernant le décodage de ce format crypté, j'ai créé une issue sur le projet qui rassemble les infos que j'ai: https://github.com/Phonations/Joker/issues/300
        J'ai commencé à regarder les outils de décompilation et pour l'instant je ne trouve que IDA, mais leur fiche de tarif n'est pas très claire: https://www.hex-rays.com/products/ida/order.shtml
        Je vais les appeler lundi pour avoir une offre correspondant à mon besoin. En tout cas je regrette que ce genre d'outil ne soit pas libre et open source ;-)

        • [^] # Re: reverse

          Posté par  . Évalué à 2.

          Tu es sûr que ce n'est pas simplement compressé ?

          Sinon avant d'attaquer avec un décompilateur ou autre grosse artillerie, je commencerais plutôt par produire plusieurs fichiers avec de légères différences et voir l'influence sur le fichier de sortie (ou par ex: est-ce qu'enregistrer 2 fois le même fichier change le contenu ? ou sa taille ?).

          En tout cas c'est un challenge intéressant :)

          • [^] # Re: reverse

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

            Tu es sûr que ce n'est pas simplement compressé ?

            Que dit la commande file sur un de leurs fichiers ?

            Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

      • [^] # Re: reverse

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

        Il me semble que ne peuvent prétendre à la couverture du droit d'auteur qu'exclusivement les réalisations de l'esprit qui expriment singulièrement la personnalité de leur auteur ? Ne serait-il pas curieux de voir défendre devant des juges qui n'ont aucune connaissance informatique le lien caractéristique entre choix et ordres des variables ou de l'algorithme de chiffrement et la personnalité du développeur ?

        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

        • [^] # Re: reverse

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

          c'est la partie substantiellement similaire de l'exception qui est gênante, la partie sur le droit d'auteurs, même si elle s'applique difficilement, est de toute façon - aussi - à l'appréciation d'un juge…

          et, malencontreusement pour certains, le logiciel est du ressort du droit d'auteur, depuis pfiou bien avant 1978 et la loi informatique et libertés qui couvre en plus les fichiers et bases de données via la CNIL.

          • [^] # Re: reverse

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

            « Ni utilisées pour la mise au point, la production ou la commercialisation d'un logiciel dont l'expression est substantiellement similaire ou pour tout autre acte portant atteinte au droit d'auteur. »

            Pour moi dans cet article substantiellement similaire se rapporte indéniablement au droit d'auteur. C'est du moins ainsi que semble devoir s'interpréter « ou pour tout autre acte portant atteinte au droit d'auteur. » Ainsi, ce n'est pas tant la similarité que la similarité au regard du droit d'auteur — donc en ce qui concerne l'expression de la personnalité de l'auteur — qui est visée par cette exception.

            « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

      • [^] # Re: reverse

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

        J'ai l'impression que c'est simplement un garde fou contre une forme de plagiat ou d'un abus de droit pour faire quelques choses qui ressemble à de la contrefaçon, cela ne s'applique pas ici, sinon toutes interopérabilité rentre dans le champ de cette clause.

        "La première sécurité est la liberté"

  • # Défi

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

    Et tu aurais un exemple de petit fichier produit par ledit Mosaic, avec un contenu connu ?

    Genre « ceci est un blob offusqué, il faut trouver dedans la chaîne “Je reviendrai.” et la date “00:39:48,600”. ».

    Je ne pense pas avoir le niveau, mais ça peut amuser certains.

    ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: Défi

      Posté par  . Évalué à 10.

      Voir le proposer à un concours de hack.

      • [^] # Re: Défi

        Posté par  . Évalué à 1.

        Oui j'ai créé une issue sur le projet: https://github.com/Phonations/Joker/issues/300
        Pour le concours de hack ce serait une bonne idée, mais je ne sais pas à qui m'adresser!

        • [^] # Re: Défi

          Posté par  (site web personnel) . Évalué à 3. Dernière modification le 29 novembre 2014 à 12:43.

          euh, ta chaîne de caractères risque d'être un peu courte…

          Mieux vaudrait prendre un livre entier : par exemple de la Terre à la Lune de Jules Vernes, qui est dans le domaine public. Tu as le texte en UTF-8 sur le projet Gutenberg.

          …et changer un caractère.
          Tu peux te limiter à un chapitre, le tout est d'avoir suffisamment de texte pour trouver des schémas récurrents.

          • [^] # Re: Défi

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

            Vu la gueule des fichiers (il y a une volonté délibérée d'ofusquer), attaquer frontalement le fichier ne servira de toutes manières pas, chaine courte ou longue.
            Il va falloir aller jouer avec les API Windows pour "capturer" les appels si ils font appels aux API de chiffrement de Windows, ou décompiler leur binaire pour voir comment ils font en interne…

            Bon courage, il va y en avoir besoin…

            • [^] # Re: Défi

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

              la décompilation a son intérêt pour identifier le type de codage, effectivement… Cela réduit le nombre de personnes en mesure de le faire :

              • besoin d'un windows
              • besoin du logiciel
              • connaissances en déchiffrement (le bon sens est souvent le meilleur outil)

              il y a une volonté délibérée d'ofusquer

              je suis au regret de m'offusquer que tu ne saches écrire obfusquer ;-)

              ou que ta touche b soit blo

          • [^] # Re: Défi

            Posté par  . Évalué à 1.

            Oui j'ai commencé avec une chaîne courte qui m'a permis de tirer des conclusions. Que veux-tu dire par "schéma récurrent"?

            • [^] # Re: Défi

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

              Que veux-tu dire par "schéma récurrent" ?

              comme peut y faire penser la définition de récurrent :

              • des octets similaires voire identiques dans chaque fichier, éventuellement en même position, cela donnera une idée des séparateurs de champ utilisés
              • généralement au début ou à la fin du fichier
              • pour un texte quasi identique, on s'attendrait à ce qu'il y ait des points communs
              • pour un texte identique, on s'attendrait à ce que les fichiers soient identiques
              • pour deux textes différents ne contenant que de l'ascii (pas d'accents pour éviter l'effet de bord du codage UTF-8 ou autre…) et faisant la même longueur, le fichier généré fait-il la même taille ?
              • [^] # Re: Défi

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

                Tu devrais regarder la gueule des fichiers avant de parler de ce genre de travail (pour faire bref : tu es complètement hors sujet, une lettre modifiée changeant 100% du fichier).

                • [^] # Re: Défi

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

                  oui, j'ai bien vu, même si je n'y ai pas passé une heure non plus ; mais bon, avec un échantillon de deux fichiers, c'est assez difficile de tirer des conclusions générales àmha.

                  pour l'instant, je réussis seulement à invalider au moins l'hypothèse "taille fixe du fichier pour chaîne de même longueur" :

                  • une chaîne de même longueur ne génère pas forcément un fichier de même longueur (791 octets pour l'un, 773 octets pour l'autre…)
                  • [^] # Re: Défi

                    Posté par  . Évalué à 4.

                    Deux fichiers, ça fait un peu léger effectivement.
                    La source est de taille faible (qq octets), il serait intéressant d'avoir également des fichiers de grosse taille (qq Mo).
                    --> ca permet d'avoir une idée de la taille de l'enveloppe versus taille des données

                    -1Mo de 'A'
                    -1Mo de random (plusieurs fois) afin de voir s'il y a un changement de taille
                    --> Ca permettra déjà de voir s'il y a des fonctions genre "compression avant chiffrement"

                    -plusieurs fois les mêmes données
                    --> Ca permet de voir s'il y a du salt avant chiffrement

                    etc..

                    Ensuite, vu les deux fichiers, et vu qu'il n'y a rien en commun, il me parait difficile de le casser uniquement avec des fichiers de sortie.. Il faudra vraiment prendre le logiciel en main (le reverser)

            • [^] # Re: Défi

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

              Est-ce que deux fois la même chaîne mais dans un contexte différent (autre poste de travail, ou bien le logiciel a été fermé entre temps, ou deux fichiers différents modifiés pour devenir les mêmes) produisent exactement le même fichier, ou pourrait-il y avoir des métadonnées peu utiles de rajoutées (voir tout simplement du bruit) ?

              ce commentaire est sous licence cc by 4 et précédentes

  • # Grand classique

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

    Les conséquences sont en effets des plus regrettables

    Rien de nouveau, tu ne fais que découvrir ce qui se passe depuis longtemps.
    J'y suis aussi confronté (domaine des formats vidéos).

    Existe-t-il des solutions de décompilation mobilisant des puissances de calcul restant à ma portée de développeur indépendant ?

    Ce n'est pas une problème de calcul (bête), mais de personne (intéligence).

    En matière légale, on peut penser que la loi française soit de mon côté puisque le document de l'April semble bien préciser que si faire de la rétroingénierie sur un logiciel est interdite, elle est autorisée en France si c'est dans le but d'assurer l'interopérabilité de données (http://wiki.april.org/w/Synth%C3%A8se_interop%C3%A9rabilit%C3%A9).

    Oui, et perso je n'ai jamai été inquiété, même par les boites qui sont US (les formats que j'ai rétro-ingéniéré sont d'origine US).
    Il y a de grands classiques du reverse engineering dans la vidéo :
    - Multimedia.cx qui essaye de centraliser les découvertes
    - FFmpeg qui implémente un nombre de formats impressionnant par reverse engineering

    Par contre, ton format semble hyper-rare, donc pas foule s'y est penché. Je vois deux choix :
    - Tu trouves des hackeurs passionnés par les chalenges qui vont s'interesser à ton chalenge
    - Tu trouves des hackeurs mercenaires qui vont se faire payer pour faire ton chalenge (tu as dit "indépendant" et non pas "fauché", et les deux n'étant pas synonymes je ne sais pas si tu peux te permettre d'investir, à toi de voir, mais les mercenaires sont rarement peu chers).

    Évidemment il reste aussi la solution du dénigrement systématique et autres manœuvres politiques déplaisantes,

    Pourquoi en passer par la?
    Tu peux expliquer tranquillement que du fait du refus de l'autre, tu es matériellement dans l'incapacité d'être compatible et tu demandes aux clients de mettre la pression sur l'interopérabilité (seuls les clients peuvent mettre la pression), en sous-entendant gentiment que si ils empèchent l'inter-opérabilité c'est peut-être parce qu'ils ont peur d'une concurrence libre et non faussée (crédo de l'UE, mais justement l'UE essaye d'éviter ce genre de vérouillages que les Etats font, ça s'applique autant aux Etats qu'aux entreprises) et que les clients devraient se demander la raison (toi, tu joues cartes sur table avec l'Open-Source et tu peux être remplacé si tu ne plait plus, à mettre en avant)

    Bon, en pratique, ça marche que très rarement que le concurrent change d'avis, ne te fat pas d'illusions… Donc reverse engineering.

    • [^] # Re: Grand classique

      Posté par  . Évalué à 2.

      Ce n'est pas une problème de calcul (bête), mais de personne (intelligence).

      Bien sûr, ma phrase était mal formulée en faite.
      Merci pour ton retour d'expérience en tout cas! En effet le format est rare (le logiciel a entre 100 et 150 utilisateurs en France). De mon côté j'ai créé une issue sur le projet: https://github.com/Phonations/Joker/issues/300
      Pour les hackeurs passionnés, j'aimerai bien mais malheureusement je n'en connais pas :-)
      Pour payer un hacker pour faire le boulot, c'est le même problème je ne sais pas où m'adresser et tout contact est intéressant! Après étant à budget limité, je ne pense pas lui demander de faire le boulot, mais au moins de me mettre sur la piste. Ca me permettra de gagner en expérience et ajouter une nouvelle compétence à mon arc!

      • [^] # Re: Grand classique

        Posté par  . Évalué à 3.

        J'interviens un peu hors sujet pour te signaler que Zenitram, à qui tu réponds, est un spécialiste reconnu des formats vidéo. Il pourrait peut-être te tuyauter un peu plus si tu l'interroges en privé.

        Sinon tu peux contacter aussi les développeurs de mplayer, ffmpeg, xine, vlc, …qui ont du faire pas mal de reverse engineering. Fouille aussi dans les archives de Linux Magazine France, qui a publié sur le sujet et dans celle de Misc (même éditeur) chez qui il y a des spécialistes en crypto.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: Grand classique

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

          Merci du compliment, mais ici il ne s'agit pas à priori de reverse engineering sur du format bête et méchant (qu'est-ce que j'ai pu en faire du reverse engineering sur des formats, mais du format qui ne chercher pas à se cacher, juste que les développeurs ne voulaient pas filer la doc) mais dans un premier temps il faut virer la partie obfuscation et ça ce sont des expert en reverse engineering de programme qu'il faut, un autre domaine (et certes je sais que ça existe, mais non je n'ai pas de nom à filer), avent de filer ça à un expert en format vidéo/audio/texte.

          J'ai jeté un oeil vite fait à ses fichiers, et il n'y a de mon point de vue clairement rien de pertinent à en sortir sans avoir le programme décompilé tellement c'est une suite "illogique" d'octets.

  • # DRM

    Posté par  . Évalué à 2.

    C'est pas une bonne nouvelle, mais régler ce genre de problème semble être dans les attributions de la Hadopi http://www.hadopi.fr/es/node/714

    • [^] # Re: DRM

      Posté par  . Évalué à 1.

      Pourquoi ce n'est pas une bonne nouvelle?

      • [^] # Re: DRM

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

        Il répondront ça après 3 ans, le temps que tu crèves.

        • [^] # Re: DRM

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

          synthétique, sourcé, un peu d'avis d'autorité néanmoins (mais reconnue), c'est là que tu devrais te concentrer plutôt que les généralisation à outrance qui débouchent inévitablement sur des threads à rallonge :/ (sur le fauxpensource que ce soit le -NC ou les licences non-OSI tu es pas mal non plus, merci et en plus tu le présentes mieux qu'avant, il y a longtemps il est vrai, jusqu'à réussir à faire changer d'avis certains, continue !).

  • # Qui possède le fichier ?

    Posté par  . Évalué à 3.

    Si tu as accès à un fichier crypté créé avec le logiciel de ton concurrent, ce fichier n'appartient pas pour autant à ce concurrent, non ? Il appartient à celui de l'a créé. Ce dernier sait ce que le fichier contient comme information et doit pouvoir demander à quelqu'un de créer un outil pour le lire. Si ce n'était pas le cas, ça voudrait dire que ce fichier ne lui appartient pas totalement (et que ledit concurrent aurait des droits sur des fichiers qu'il n'a pas créés)

    La question n'est pas de faire de la rétro-ingénierie sur un logiciel, mais de le faire sur un fichier créé par un logiciel ce qui est bien différent. L'article du code de la PI sur la question parle bien de logiciel et seulement de logiciel

    • [^] # Re: Qui possède le fichier ?

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 29 novembre 2014 à 23:40.

      cela dépend tout de même du contenu du fichier (ce pourquoi je propose un texte du domaine public plus haut) et si le format du fichier est assimilable à une "base de données" au sens de la loi informatique et libertés : pas pour moi, mais c'est à l'appréciation du juge, la notion de format ouvert apparue avec la LCEN étant plutôt le point à mettre en avant àmha, l'aspect interopérabilité étant bien intégré par l'auteur du journal.

      La rétro-ingénierie concerne la partie du logiciel en mesure de lire ledit fichier.

      Le concurrent revendique par ailleurs sur son site web avoir déposé des brevets (sans doute illégaux en Europe… heureusement !). Cela crée une incertitude juridique pour distribution aux USA (bon, uniquement dans quelques états, les brevets logiciels étant battus en brèche dans pas mal de juridictions).

      • [^] # Re: Qui possède le fichier ?

        Posté par  . Évalué à 5.

        On peut partir du fait qu'un fichier appartient à son créateur. Après bien entendu on peut se demander si le contenu ne recèle pas d'autres droits.

        Quand Dave Coffin fait de la rétro-ingénierie pour décoder les images des différents formats raw des fabricants d'appareils photos numériques il le fait à partir des fichiers raw et il n'a pas (encore) été poursuivi pour des raisons de PI.

        Du coup, je pense qu'il vaut mieux partir d'un fichier issu du logiciel Mosaic dont on connait le contenu et essayer de trouver comment les données sont organisées que de vouloir tenter de la rétro-ingénierie sur le logiciel. En parallèle, ça ne coûte rien de demander les spécifications du fichier pour l'interopérabilité, également voir un peu comment faire remonter tout ça auprès d'une autorité officielle pour un abus de position dominante (si ledit logiciel est en position dominante)

  • # Changement de format

    Posté par  . Évalué à 1.

    Le danger est que si tu arrives à percer leurs spécifications à jour, ils changent le format pour rendre caducs tes efforts.

    • [^] # Re: Changement de format

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

      Ce qui démontrera à tout le monde, dont à leurs utilisateurs, qu'ils cherchent à garder leurs clients captifs et s'opposent à l'interopérabilité. De l'intérêt de promouvoir l'interopérabilité et les formats ouverts, gages de pérennité pour tout le monde : éditeur comme utilisateur.

Suivre le flux des commentaires

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