Journal Le filtrage à la source

Posté par  . Licence CC By‑SA.
Étiquettes :
16
23
avr.
2018

Pff, les combats, c'est jamais fini. Alors, on rigole tous sûrement un peu des abus des blocages automatiques sur YouTube. Et bien maintenant, c'est au tour des développeurs : https://juliareda.eu/2018/04/free-software-censorship-machines/

Comme j'imagine que vous êtes nombreux dans le coin, vous n'avez plus qu'à choisir votre mode d'expression. Je suppose que vous êtes contre ce changement, mais enfin, vous avez le droit d'être pour. Vous aurez juste du mal à me convaincre.

Parce que le problème de ces filtres est multiple, mais il pose également une asymétrie flagrante. Les forges logicielles hébergent énormément de code open-source (quoi que cela veuille dire), qui se verra donc inspecter pour valider qu'il ne viole pas une autre licence, a priori propriétaire. Mais par contre, les dépôts de logiciels propriétaires ne seront pas inspectés, pour vérifier qu'aucune licence libre n'est violée. C'est bien pratique.

  • # trop gros

    Posté par  . Évalué à 0.

    C'est trop gros pour passer avec la discrimination. Et si ça passe, ça sera inapplicable car personne à l'heure actuelle ne sait filtrer comme ça, ça ne concerne que les grosses (non-profit) forges, et il n'y a pas à ma connaissance de grosse forge en Europe.

    • [^] # Re: trop gros

      Posté par  . Évalué à 10.

      C'est parce que tout le monde regarde en pensant "non, ça c'est trop gros" qu'on se retrouve avec des lois et des directives absurdes, parce qu'il ne reste que les ignorants et les gens de mauvaise foi pour débattre.

      C'est un peu l'idée d'Einstein.

  • # On en a discuté ici

    Posté par  . Évalué à 5. Dernière modification le 24 avril 2018 à 15:24.

    On en a discuté ici https://linuxfr.org/users/bluestorm/journaux/copyleft-is-censorship

    Pour le mode d'expression, il y a ça : https://savecodeshare.eu/

  • # Est-ce qu'on a le droit de ne pas s'inquiéter?

    Posté par  . Évalué à 9. Dernière modification le 24 avril 2018 à 16:14.

    Je suppose que vous êtes contre ce changement, mais enfin, vous avez le droit d'être pour. Vous aurez juste du mal à me convaincre.

    En fait, j'aimerais bien être convaincu que c'est un problème, parce que pour l'instant, je vois sortir les grands mots (censure, filtrage, blocage…), mais sur le fond, est-ce que la mauvaise qualité potentielle des algorithmes de filtre est le seul argument? Parce que ça me parait bien faible…

    Jusqu'au début du XXIe siècle, les problèmes de droit d'auteur et de contrefaçon étaient gérés a posteriori. Quelqu'un publiait une œuvre de l'esprit sans en avoir le droit, les ayant-droits portaient plainte, la justice tranchait, et éventuellement sanctionnait le malandrin.

    On ne peut pas nier que cette procédure est devenue inapplicable. Quand une œuvre est diffusée sur Internet, elle devient immédiatement accessible au monde entier, et quelques minutes suffisent, surtout quand l'info est relayée sur les réseaux sociaux, pour que «le mal» soit fait. Mal qu'on peut considérer comme relativement mineur pour tout un tas de raisons, mais mal qui a indéniablement des conséquences économiques potentielles. Bien entendu, si 1000 personnes téléchargent un film, le manque à gagner pour l'industrie du DVD n'est pas 1000 x le prix d'un DVD (à cause de l'effet d'aubaine et de plein de trucs), mais c'est compliqué d'affirmer qu'il est de zéro. Bref, que les raisons soient liées à des gros sous ou non, il y a un problème avec la modération par la justice, et la mise en place d'une modération privée par les plateformes sur dénonciation ne règle pas ce problème, puisque l'ayant-droit ne peut se plaindre qu'après la publication. Même sur le fond, on peut trouver ça anormal : OK, les grosses boites de l'industrie pseudo-culturelle ont des moyens illimités, mais il n'est quand même pas normal qu'une «victime» doive assurer activement et sur des fonds privés la défense de ses intérêts qui sont pourtant protégés par la loi, surtout si l'on considère qu'il est généralement impossible de récupérer le moindre sou auprès des contrefacteurs fauchés (qui n'en tirent aucun revenu, certes, mais ça n'est pas une raison : le vandalisme ne génère pas de revenus non plus, mais ça ne légitime pas le fait de laisser la «victime» sans recours).

    Dans ce contexte, la protection des ayant-droit avant la publication, ça me semble une solution acceptable, à la fois pour les plateformes (qui montrent leur bonne foi), pour les ayant-droit, et même pour les contrefacteurs du dimanche qu'on protège des conséquences potentiellement démesurées de leur geste.

    Du coup, je ne vois pas pourquoi le logiciel, libre ou pas, devrait avoir droit à des règles différentes d'autres types d'œuvres. Le diable est toujours dans les détails, mais je ne comprends pas la légitimité de mettre à disposition du public un bout de code que son auteur a placé dans une base de données de code à protéger. Il ne faut pas oublier que le logiciel libre n'existe que par une application extrêmement stricte du droit d'auteur ; on passe notre temps à fustiuger telle ou telle entreprise qui n'a pas respecté l'article 127 d'une licence libre hyper-technique, on est aussi super-procéduriers, et tout ça, c'est basé sur un droit d'auteur quasiment sans limite. Le minimum pour un contributeur de logiciel libre, c'est de ne pas pomper de code non-libre (qui met en danger les utilisateurs du logiciel), et de s'assurer de la compatibilité des licences avant de diffuser du code qui ne lui appartient pas. Sur le fond, je me vois mal défendre le droit d'aller uploader du code proprio en le mettant faussement sous GPL, ça nuit certainement plus au logiciel libre qu'au propriétaire du code.

    Alors oui, le diable est dans les détails, mais les problèmes potentiels restent assez gérables, à mes yeux. Les faux positifs? Il suffit d'une procédure simple pour contacter les administrateurs du site et prouver sa bonne foi. D'ailleurs, je ne vois pas comment on pourrait avoir de faux positifs sur des bouts de code non-triviaux. Les «faux» dans les bases de données? Pareil que pour Youtube ou autres diffuseurs de contenu, le risque semble élevé pour une base de données peu regardante ; après plusieurs incidents elle risque de ne plus être consultée du tout par les diffuseurs, qui n'ont aucun intérêt à gêner leurs utilisateurs légitimes. La surcharge de travail pour monter une plateforme de diffusion? Si l'interface est bien faite, il suffit d'une requête vers un site de référence avant la validation de l'upoad, ça n'est pas une procédure très lourde…

    Mais par contre, les dépôts de logiciels propriétaires ne seront pas inspectés, pour vérifier qu'aucune licence libre n'est violée. C'est bien pratique.

    C'est vicelard comme argument, ça ne peut pas fonctionner. Dans un cas tu publies un document (tu prends la responsabilité de le rendre disponible au monde entier), dans l'autre cas tu le privatises sans que personne ne le sache. Les conséquences ne sont pas du tout les mêmes, et les responsabilités non plus, sans compter qu'il reste légal de privatiser du code libre tant qu'on ne le diffuse pas.

    D'ailleurs, il ne me semble pas impossible que les bases de données de code qui seront utilisées comme référence ne soient pas justement inspectées, justement pour éviter les faux positifs, et qu'une entreprise qui essaye de privatiser du code libre se retrouver justement dans l'obligation de retirer ce code de la base. Mais bon, de toutes manières, j'imagine mal Microsoft balancer le source de Windows dans des bases de données indépendantes… D'une manière générale, le code proprio n'a pas vocation à être diffusé, et c'est un danger que de risquer de le diffuser accidentellement en tentant de se protéger d'une éventuelle fuite qui n'aura certainement jamais lieu. Ça reste très différent de l'industrie musicale, qui diffuse déja (la plupart du temps) les œuvres qu'elle tente de protéger.

    • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

      Posté par  . Évalué à 7. Dernière modification le 24 avril 2018 à 23:01.

      Le point de vue optimiste c'est que tout pourrait être mis en place de façon pertinente et juste, oui.

      D'un autre côté, quand du code libre se fera jeter parce qu'un système automatisé aura décidé que ça ressemblait trop à du code protégé, on aura quoi comme recours ? Envoyer un mail et se battre des semaines ? Le code d'un logiciel entier ça se fait "protéger" pour 250 euros à l'APP, rien à justifier, on envoie le code et le chèque, point. Le code inclura probablement des portions standard pompées sur internet par un collaborateur négligent. Et des portions qu'on aurait du mal à coder de façon différente de toutes façons, du parcours de liste ou de graphe par exemple.

      Quelle est la granularité du système de filtrage ? Comment il va reconnaître une portion "simple" d'une portion "complexe" ? Si on lui apprend à détecter de la similarité incluant un simple renommage de variables on va vite retomber sur les algorithmes qu'on aurait du mal à écrire autrement. Il y aura de l'intelligence artificielle dans le tout, aussi. Massivement automatisé, difficile à contrôler, il y a toujours des faux positifs. Potentiellement beaucoup, vu la quantité de code propriétaire versus la quantité de code libre.

      Du coup, avec la dissymétrie des informations (on ne verra jamais le code proprio, mais le système de filtrage le voit), la dissymétrie de qui est scanné pour plagiat et antériorité, l'accès aux specs techniques du système filtrage, le fait que les petites gens capituleront massivement (pas le choix) devant le jugement des missi dominici des ayants droit, et que ni les ayant "droit" ni les plateformes n'auront de sanction alors que se faire refuser la publication de son travail ça peut être démoralisant voir bloquant pour son travail, on a de bonnes raisons de s'inquiéter. Pas d'avoir peur quand même, mais de s'inquiéter. Ce qui n'inquiète pas du tout les lobbys malheureusement.

      Où peut-on trouver des cas de repompage de code propriétaire dans du code libre ? En quoi sont-ils suffisamment fréquents pour justifier la mise en place de tout ça ?
      Sera-t-il possible de prendre des mesures pour éviter que des "coding trolls" fassent protéger des portions de code simples et/ou génériques  ?

      • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

        Posté par  . Évalué à -1.

        Envoyer un mail et se battre des semaines ?

        Une plateforme d'hébergement de code (type Github) a intérêt à être réactive si elle ne veut pas perdre son marché, et de limiter elle-même les faux positifs.

        Et des portions qu'on aurait du mal à coder de façon différente de toutes façons, du parcours de liste ou de graphe par exemple.

        … du code trivial, donc, qui ne rentre pas dans le cadre de la propriété intellectuelle. S'il ne s'agit que de quelques lignes, pourquoi irait-il déclencher une alerte rouge?

        Le code d'un logiciel entier ça se fait "protéger" pour 250 euros à l'APP

        Et l'APP encourage également le dépot de code sous licence libre. Pourquoi ne pas saisir l'occasion?

        En plus, techniquement, ça semble tout à fait faisable de déterminer automatiquement la compatibilité des licences. Dans les dépôts de logiciels, on indique en général la licence des projets ; si le système de détection identifie un bout de code existant sous licence X, il peut tout à fait vérifier la compatibilité de la licence X avec la licence du projet.

        il y a toujours des faux positifs.

        Oui, il y en a toujours. Mais combien? Un commit sur 1000? Un commit sur 10000?

        Il ne faut pas oublier la finalité de ces filtres. La finalité, c'est d'éviter les pertes d'exploitation liées à la contrefaçon. On se prend la tête sur des conséquences potentielles de la mise en place d'un tel système, mais ces conséquences n'ont aucun intérêt pour les ayant droit. Qu'est-ce qu'un gros éditeur de logiciel peut avoir à faire qu'une fonction de 2 lignes qui parcourt un graphe dans un logiciel libre ait, par hasard (*), une ressemblance avec deux lignes sur 100M d'un gros projet commercial? Rien à battre. C'est une force et une faiblesse ; une faiblesse parce que personne n'en a rien à faire que ton commit se retrouve bloqué, mais aussi une force parce que personne n'en a rien à faire que la plateforme d'hébergement laisse passer ce genre de choses pour éviter les réclamations.

        (*) le hasard, en droit d'auteur, je n'y crois pas une seconde. C'est un argument trop faible, qui ne tient pas la vérification. Ça n'est pas forcément intuitif, mais la plupart des phrases sont uniques. Une seule phrase peut souvent permettre de définir un plagiat. Si je prends ta première phrase, "Le point de vue optimiste c'est que tout pourrait être mis en place de façon pertinente et juste". Sur Google:
        * "le point de vue optimiste" : 2470 résultats
        * "Le point de vue optimiste c'est" : 8 résultats
        * "Le point de vue optimiste c'est que" : 2 résultats
        * ""Le point de vue optimiste c'est que tout" : 0 résultat.

        Étant donné que la base de données de Google recouvre probablement la majorité des écrits qui ont jamais été produits, il est probable que personne n'ait simplement écrit "le point de vue optimiste c'est que tout" avant toi. C'est étonnant, non? Tu peux parier une certaine quantité d'argent que la phrase complète "Le point de vue optimiste c'est que tout pourrait être mis en place de façon pertinente et juste" n'a jamais été, ni ne sera jamais plus, écrite ou prononcée par aucun autre être humain que toi (et moi qui te cite). C'est assez contre-intuitif, et tant de gens essayent d'argumenter sur Wikipédia qu'il n'y a pas 50 manières de rédiger une information. En effet, il n'y en a pas 50, il y en a probablement 50 milliards de milliards :-)

        Je pense que c'est exactement la même chose pour le code. Trois ou quatre lignes identiques, ça ne peut pas être du hasard. J'imagine que c'est d'ailleurs facilement testable en cherchant les bouts de binaires ou d'assembleur identique entre logiciels libres ; on doit facilement déterminer la probabilité pour, par hasard, avoir une séquence de n éléments identifiques.

        • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

          Posté par  . Évalué à 2.

          Tiens, d'ailleurs, je me réponds à moi-même pour admirer le geekscotte qui a disparu d'Internet, mais ça marche aussi complètement avec le code. J'ai été piquer une ligne très courte complètement au hasard dans le kernel Linux, "cs->mark_unstable(cs);". Je tape ça dans Google, et je tombe sur "linux/kernel/time/clocksource.c", exactement le bon fichier. Ça serait intéressant de tester ce genre de trucs avec les bases de données de l'APP par exemple, mais ça ne m'étonnerait pas que "cs->mark_unstable(cs);" soit une ligne unique dans l'histoire du logiciel, que personne n'avait jamais écrite avant, et que personne ne réécrira jamais après. Elle est pourtant totalement triviale, et personne n'irait prétendre qu'à elle seule elle puisse être couverte par le droit d'auteur. Mais n'empêche, un argument probabiliste montrerait qu'elle est suffisante à identifier un plagiat. Alors 10 lignes? 50 lignes?

          Ça serait pas mal que les tenants de l'hypothèse du code identique par hasard prouvent que c'est possible en pratique, plutôt que de partir du principe que c'est par définition possible.

          • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

            Posté par  (Mastodon) . Évalué à 3.

            Identique… à un renommage près ?

            objet->méthode(objet);

            Là tu vas en trouver des utilisations strictement identiques…
            Et par dizaines de millions au moins !

            Un plagiat en changeant le nom … ça reste un plagiat.
            L'exemple ici n'est pas pertinent du tout, il ne représente pas du tout le problème dont il est question.

            Yth.

        • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

          Posté par  . Évalué à 8.

          Je pense que c'est exactement la même chose pour le code. Trois ou quatre lignes identiques, ça ne peut pas être du hasard.

          Euh… Comment dire… C'est juste fréquent, très fréquent même; j'aurais même tendance à dire que c'est 4 lignes de codes puis autre 4 lignes de code, pis encore d'autre qui forment la majorité des programmes.

          Fait un "Hello world" en C, sur 1000 personnes tu vas avoir plusieurs programme exactement identique.

          Quand on fait du code, on part pas dans le lyrique, on va au plus efficace, les variable de boucle ont tendance à s'appeler i,j,k,l, une classe à un nom explicite et concis, un itérateur it (ou itClasse)

          Je ne parle même pas de java avant les lambda (java 8), où les mêmes morceaux de codes étaient répétés, ad nauseam. Comme les IDE formatent ton code réordonnent les include/import selon des règles pré établies, les convention grandement partagées la mise en forme est l’œuvre d'un automate.

          Les même problèmes ont les même solutions, les algo sont pour la plupart connus, et c'est la mise en œuvre qui échoie aux développeurs.

          Je ne parle même plus de l'entraide aux développeur (fait un tour sur stackoverflow , où des gens posent des questions, et d'autre gens répondent avec du code généralement fonctionnel, ce code qui va se retrouver dans le programme, légèrement adapté )

          La grammaire d'un langage de programmation est rigide et limite énormément ce que tu peux écrire, et on s'embarrasse pas de fioritures;

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

          • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

            Posté par  . Évalué à 1.

            Je ne demande qu'à être contredit, mais fais-le sur des bases solides, et pas sur une vague impression. Comme je l'ai précisé dans mon post, l'argument "il n'y a pas 50 manières de faire telle ou telle chose", je l'ai entendu des dizaines de fois quand je trainais sur Wikipédia et que j'étais impliqué dans des histoires de copyvio. Or, il est faux, factuellement faux. Souvent, un enchainement de 5 mots dans une phrase complètement triviale est original. C'est contre-intuitif, mais c'est indéniable.

            Encore une fois, contredis-moi. Montre-moi que des bouts de code indépendants et non-triviaux, écrits par des gens qui ne se sont pas inspirés les uns des autres, sont identiques. Parce que c'est bien de ça qu'on parle : de droits d'auteur, donc d'œuvres de l'esprit, qui, par définition, reflètent la personnalité de l'auteur. Alors prends deux logiciels libres, des gros par exemple, pour avoir beaucoup de code (style Gnome et Libre Office), fais une recherche de similarité, et fais la liste des plus gros blocs. Si tu trouves plusieurs lignes consécutives identiques, avec de sérieux indices qui montrent qu'ils ont été élaborés indémendamment (c'est facile à prouver à partir des commits), alors mea culpa, j'admettrai qu'on peut écrire le même bout de code non-trivial indémendamment. Tant que tu n'apportes pas de telles preuves, alors je reste sur mon idée que c'est un non-argument. C'est une impression que beaucoup de gens ont, mais c'est faux.

            Si ton argument, c'est de dire "tout le monde se pompe plus ou moins", ça complique nettement les choses. Quand tu fais du logiciel libre, tu imposes une licence au document, et quand tu fais ça, tu te définis comme l'auteur du code. En plus, l'argument de la trivialité du code est à double tranchant. Si c'est du code trivial, alors tu n'as pas besoin de le pomper dans un livre. Si c'est un algo complexe et optimisé, qui reflète le travail de son auteur, même s'il ne fait que 5 lignes, il entre dans le cadre du droit d'auteur. Et si tu l'as recopié dans un bouquin ou dans un forum sans que l'auteur ne t'en donne le droit, et pire, si tu l'as inclus "silencieusement" sous une licence libre, ça serait tout à fait normal que tu te fasses jeter d'un dépôt libre. Ce que tu veux dire, c'est qu'en fait, tu n'es pas l'auteur de tout le code? Alors c'est toi qui, en premier lieu, est coupable de contrefaçon, et tu devrais peut-être changer tes méthodes de travail.

            Après, évidemment, si 90% de la base de Github est pourrie par du code dont le statut en termes de droit d'auteurs n'est pas clair (auteurs non indiqués, licence non respectée, code copié-collé de sources propriétaires), l'imposition d'un filtre va devenir un problème. Mais ça ne ferait que révéler un problème plus ancien et profond dans la manière de travailler dans le logiciel libre, et pas vraiment un problème de la loi dont on parle…

            • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

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

              En 10 ans de boite, j'ai vu passer des palanquées de code, écrit par des gens éparpillés partout autour du monde. Et ce que j'en ressort comme expérience va exactement dans le sens d'arnaudus : le code non-trivial piqué d'un post, d'une lib voire pire d'un autre projet fait par d'autres gens (sisi, ça existe), ça se voit tout de suite avec un peu d'habitude. Pour peu que le projet n'ait pas de contrainte de style, tu arrives même à reconnaitre la personne qui a fait le plus gros du code d'une classe X ou Y juste en lisant ce code – tout comme tu peux reconnaitre un auteur à son style.

              Pour moi, les principaux effets de ce genre de détection si ça se met en place, ça va être :

              • La détection de code copié/collé d'un projet sur l'autre, en général dans l'irrespect le plus total des licences (et ça peut être une excellente chose pour le logiciel libre sous licence contaminante)
              • Un risque de faux positifs d'autant plus élevé que le projet a des normes communes et paranoïaques

              La connaissance libre : https://zestedesavoir.com

          • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

            Posté par  . Évalué à 1.

            Fait un "Hello world" en C, sur 1000 personnes tu vas avoir plusieurs programme exactement identique.

            Sur le "Hello World", c'est un peu facile, ça n'est même pas un algo. Mais prends un truc super simple : faire la moyenne d'un vecteur ou d'un tableau. Je prends le code dans R (un langage de stats assez populaire), la boucle for est écrite :

            for (R_xlen_t k = 0; k < nbatch; k++)
                    s += dx[k];
                });
            s /= n;

            C'est loin d'être des glands qui écrivent le code de R, donc je pense que c'est une référence. Le code est en effet trivial. Mais jamais tu ne pourras retomber sur ces noms de variable sans pomper. D'ailleurs, on ne trouve que ce fichier quand on cherche "for (R_xlen_t k = 0; k < nbatch; k++)" dans Google.

            Encore une fois, non, on ne peut pas réécrire du code existant sans pomper, même s'il ne s'agit que de faire la somme des éléments d'un tableau. Parce que le nom du tableau, les noms des types, les index, tout ça génère une combinatoire quasi infinie.

            • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

              Posté par  . Évalué à 5.

              tiens j'ai fait un essai : "for ( int i = 0 ; i < size ; i++)", dans google j'ai un bon paquet de résultats, change ton R_xlen_t en int tu as deux autre résultats.

              Tu as volontairement pris un exemple avec une faible occurrence, pour prouver ton propos.

              Le problème c'est que tu as une vision très étriqué de ce qu'est le code. Si il suffit de renommer les variables pour être hors d'eau, ton système n'a aucun sens car ce n'est pas ce que l'on cherche à protéger. Si il faut que ton détecteur soit capable de détecter le renommage, tu vas avoir des millions de faux positifs.

              Aucun auteur, aujourd'hui ne construit sur rien, il s'inspire de ceux qui l'ont précédé; utilise des 'patrons' plus ou moins usuels pour constituer son histoire, et c'est cet agencement qui est protégé par le droit d'auteur. On ne demande pas à un auteur d'être concis, on leur demande même d'avoir un vocabulaire riche, là ou le développeur doit aller au plus vite, et où les variables ne changent pas de dénomination en route.

              par exemple pour échanger deux valeurs a et b, on peut écrire

              template<typename T> void swap(T &a, T &b)
              {
                 T c=a;
                 a=b;
                 b=c;
              }
              
              // ou 
              
              std::swap(a,b);

              voila j'ai fait le tour de ce qu'on peut faire en c++ pour un développeur normal;
              note bien j'ai aussi la variation pour les long/int/short

              a+=b;
              b=a-b;
              a=a-b;

              et on peut encore inverser a et b. ou replace a+=b par a = a + b, ou utiliser auto à la place de T;

              Voila, j'ai donné des variations voila, maintenant trouves une autre solution susceptible d'être écrite par un développeur, le renommage ne compte pas, et le formatage non plus.

              Toujours si on veut aller ver la protection du code, il faut que ton analyse soit capable de repérer des inversions de lignes, virer le code 'mort', Bref maitriser les techniques de dissimulations, il faut que ton outil soit suffisamment fiable pour ne pas se planter tous les deux commits.

              J'ajouterai que protéger du code comme on protège la littérature va être folklorique avec un blocage jusqu'à 70 ans après la mort de l'auteur ;) La programmer deviendra vraiment de l'art ;) Je plains les nouvelle génération qui devront faire un "Hello world", en s'assurant de n'avoir pas de prior act ;)

              Il ne faut pas décorner les boeufs avant d'avoir semé le vent

              • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

                Posté par  . Évalué à -1.

                change ton R_xlen_t en int tu as deux autre résultats.

                Prends ta souris, rajoute une trompe, grossis 1000 fois, et tu as un éléphant, donc une souris ressemble vachement à un éléphant.

                Tu as volontairement pris un exemple avec une faible occurrence, pour prouver ton propos.

                C'est totalement faux. Je me suis demandé "tiens, prenons un algo trivial, le calcul de moyenne", j'avais un script R ouvert, j'ai été chercher le source sur Google, et je l'ai sorti.

                Mais bon, si tu imagines que les interlocuteurs avec qui tu n'es pas d'accord sont systématiquement de mauvaise foi, alors c'est sûr que tu vas avoir l'impression d'avoir toujours raison.

                c'est cet agencement qui est protégé par le droit d'auteur.

                Ça n'est qu'une interprétation très lointaine et très douteuse de ce qu'est le droit d'auteur. Le code est protégé par le droit d'auteur de la même manière qu'un texte ou une œuvre quelconque, et c'est toi qui te construis tout une idée de ce qui est protégé et de ce qui ne l'est pas. Sur les textes littéraires par exemple, je ne connais pas de cas où un auteur a été condamné pour avoir repris la structure d'un roman (ou alors beaucoup de films Hollyhoodiens auraient un problème).

                voila j'ai fait le tour de ce qu'on peut faire en c++ pour un développeur normal;

                Pas de bol, ça n'est pas l'implémentation de std::swap, qui utilise std::move

                et on peut encore inverser a et b. ou replace a+=b par a = a + b, ou utiliser auto à la place de T;

                Ou spécialiser le template pour les pointeurs, ou appeler a et b comme on veut, ou mettre class à la place de typename, ou appeler la fonction myswap ou n'importe quoi d'autre pour la distinguer de std::swap… Donc oui, il existe des dizaines de manières d'implémenter ce truc trivial.

                D'ailleurs, un très bon exemple est l'implémentation de la stl par les différents compilos. Les implémentations se ressemblent parfois un peu, mais la plupart du temps, elles diffèrent grandement! Impossible d'affirmer qu'il n'y a qu'un moyen de coder la stl, alors que pourtant, on reste dans des fonctions très génériques, avec la même API et les mêmes contraintes!

                Toujours si on veut aller ver la protection du code, il faut que ton analyse soit capable de repérer des inversions de lignes, virer le code 'mort', Bref maitriser les techniques de dissimulations, il faut que ton outil soit suffisamment fiable pour ne pas se planter tous les deux commits.

                Non, parce que ça n'est pas du tout l'objectif. C'est un peu comme si tu demandais à ce que l'algo de Youtube arrive à déceler les vidéos composées d'images de film variés, qui durent 1/24 seconde, montées à l'envers et distordues par tout un tas de filtres… Mais non, c'est à côté de la plaque. Les ayant-droit se foutent complètement que tu proposes des trucs illisibles qui ne servent à personne, ils ne veulent pas que tu diffuses leur truc à leur place, c'est tout.

                L'idée n'a jamais été de mettre des filtres infaillibles, c'est la communauté du logiciel libre qui fantasme sur des risques purement théoriques. Tu dis qu'un filtre doit faire ci, ci, ou ça, mais pourquoi tu lui inventes des contraintes? Si ça se trouve, les filtres vont porter au niveau du fichier, voire du projet! Mais non, on préfère se faire peur en prétendant que "for (int i = 0; i < size; i++)" va être interdit. On n'est pas là pour se monter un jeu de rôle! Ces filtres servent à empêcher l'upload de matériel protégé par le droit d'auteur ; je reste sur ma conviction qu'il est strictement impossible de créer plusieurs lignes de code identiques par coïncidence dans des pojets réels, et il est aussi très probablement impossible de créer plusieurs dizaines d'instruction assembleur identiques après compilation (donc là, exit les noms de variable et l'indentation du code). Et je ne parle même pas des chaines de caractères, des commentaires, des messages d'erreurs!

                Après, il y a peut-être quelques copieurs-colleurs fous qui mouillent un peu ; en particulier, les algos non-triviaux publiés sur le web ou dans des bouquins ne sont peut-être pas libres, et oui, si on passe notre vie à faire semblant de coder, ça peut être problématique.

                • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

                  Posté par  . Évalué à 4.

                  Pas de bol, ça n'est pas l'implémentation de std::swap, qui utilise std::move

                  Oups désolé de faire du C++ pré C++11, un manque de pratique :P;

                  Ces filtres servent à empêcher l'upload de matériel protégé par le droit d'auteur

                  justement soit il font plus que de la bête comparaison et ils sont inutiles si je copie comme un vandale du code le réarranger est trivial, un peu comme inverser une vidéo sur youtube ou la ralentir, c'est encore plus facile (shift-f6->refactor->rename)

                  Prends ta souris, rajoute une trompe, grossis 1000 fois, et tu as un éléphant, donc une souris ressemble vachement à un éléphant.

                  Si je prends Harry Potter, et que je renomme tous les personnages/lieux, ça reste Harry Potter.

                  Les implémentations de patron de conception, sont toutes proche voire identique au renommage près.

                  mais pourquoi tu lui inventes des contraintes;

                  c'est pas une contrainte c'est le minimum pour que ça serve à quelque chose.

                  Ensuite pour une raison de dérive usuelle des droit d'auteur je suis contre ce genre d'approche, déjà qu'on doit déjà se battre contre les troll de brevets, si on doit en plus se farcir les trolls de snipet de code, on est pas sorti de l'auberge; des chants d'oiseau se sont fait dégommer par youtube par exemple.

                  Après, il y a peut-être quelques copieurs-colleurs fous qui mouillent un peu ;

                  Je connais très peu de dev qui ne posent aucune question à google, les forum d'entraide entre développeur sont une ressource essentielle; si demain le gars qui vient de répondre sur SO se fait jeter son commit parce-que le gars qu'il vient d'aider a fait son commit avant, il réfléchira à deux fois avant d'aider.

                  Et contrairement à toi, je ne pense pas qu'un calcul de somme, de moyenne, un tri ou autre brique élémentaire de code ne doive être monopolisé.

                  Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

                  Posté par  . Évalué à 2.

                  Après, il y a peut-être quelques copieurs-colleurs fous qui mouillent un peu ; en particulier, les algos non-triviaux publiés sur le web ou dans des bouquins ne sont peut-être pas libres, et oui, si on passe notre vie à faire semblant de coder, ça peut être problématique.

                  Ah, le bon vieux syndrome du NIH… Triste.

                  "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                  • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

                    Posté par  . Évalué à 1.

                    Triste, le respect des licences? Tu te colles 10 lignes d'un algo optimisé, tu ne cites pas la source ni l'auteur, et pire, tu colles ton nom en haut du fichier, avec la licence que tu aimes bien? C'est un comportement méprisable. Le minimum quand tu prends quelque chose à quelqu'un d'autre, c'est 1) d'indiquer que le code n'est pas de toi (en commentaire, par exemple)—ça pourra aussi aider les relecteurs, 2) de faire en sorte que la licence du code est compatible avec la licence de ton logiciel, ce qui pourra t'éviter des problèmes, éviter des problèmes à ton patron, et au passage d'éviter des problèmes à tes utilisateurs.

                    Le je-m-en-foutisme avec les licences et la propriété intellectuelle, c'est dramatique. On parle de délits assez graves, qui sont quand même passibles de peines de prison! C'est quoi l'argument, "Boarf, tout le monde fait comme ça" (ce qui est complètement faux), "Boarf, c'est pas si grave" (bah non, c'est pas grave, c'est pour ça que ça peut se finir au tribunal), "Ah mais si on ne peut plus recopier du code c'est la fin du monde", l'argument du gros beauf typique? Sérieusement, il faut aussi se poser les bonnes questions. Dans ton code, il n'y a que TON code. Tu mets ton nom en haut, tu choisis la licence, tu diffuses éventuellement sous licence libre, alors non, tu ne peux pas par paresse intellectuelle faire passer le travail des autres comme ton travail. Il y a plein de manières légales et élégantes d'utiliser le travail des autres; soit en liant des bibliothèques, soit en isolant le code compatible dans d'autres fichiers, soit en créditant les auteurs, soit en contactant les auteurs dans le cas où la licence du code est ambigüe; bref, c'est très facile de travailler correctement. Il n'y a aucune justification à travailler comme un goret, aucune. Parce que non, ça n'est ni moral, ni éthique, ni normal, de repomper un beau morceau de code sans en avoir le droit.

                    Du coup, je comprends un peu mieux la discussion sur ces histoires de filtre. Les gens n'ont pas peur des faux positifs, ils ont peur des vrais positifs, peut-être. Je trouverais ça très bien que les gens qui ne respectent pas les droits des autres (mais bien sûr qui ne voudraient surtout pas qu'on change la licence de leur code, il ne faut pas déconner) aient des problèmes.

                    • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

                      Posté par  . Évalué à 4.

                      En fait le problème il est là.

                      Tu sors l'exemple d'un morceau que tu juges digne d'être protégé, et tu l'étends à la totalité du code produit.

                      Si tu veux voire jusqu'où les dérive du droit d'auteur va voir ici

                      https://pitchfork.com/news/57774-jay-zs-run-this-town-copyright-infringement-lawsuit-thrown-out/

                      Par ailleurs ton postula que deux codes sont fatalement différent est faux, j'ai des exemples sous mes yeux dans mon projet, et l'un des morceau est une fonction antérieur à la seconde portion de code, si la deuxième personne avait eu connaissance de la fonction, il l'aurait utilisé (on est pas payé à la ligne). L'exemple sur std::swap est assez parlant, la différence est du à une nouveauté du langage, qui est la move sémantic datant de c++11.

                      Moi ce que je crains de ces conneries c'est le risque de la fin du code libre et de l'entraide entre les développeurs, le début de code avec des noms de variables à rallonge pour éviter une éventuelle détection.

                      "Ah mais si on ne peut plus recopier du code c'est la fin du monde

                      Non, c'est on ne peut plus coder, prends l'exemple que j'ai donné sur le for, cherche dans google, avec les guillemets, regarde le nombre de résultat à l'espace près, et après tu va prétendre que tous le monde à copié les uns sur les autres? Réfléchit un minimum à ce que ton automate de détection de copie soit capable de faire pour être un minimum pertinent.

                      par exemple la séquence

                      b.addActionListener( 
                           new ActionListener() {    
                             @Override 
                             public void actionPerformed(ActionEvent e) {

                      est très fréquente, selon les styles automatique tu peux l'avoir entre 2 et 4 lignes.

                      Avec les dérive de la détection auto de youtube (chant d'oiseau ou bruit blanc par exemple), désolé de ne pas applaudir, quelque chose qui va prétendre que mon code, ma production est celle d'un autre.

                      Toujours dans les exemple de 3/4 lignes qui vont faire tilter ton détecteur, encore java, un GridBagLayout, ou plus globalement tout ce qui se fait à coup de builder, tous les import (java/python) / include (c/c++)

                      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: Est-ce qu'on a le droit de ne pas s'inquiéter?

      Posté par  . Évalué à 3.

      Il y a un peu de tout là-dedans : https://framablog.org/2018/04/19/la-reforme-europeenne-du-droit-dauteur-une-menace-pour-le-logiciel-libre-selon-glyn-moody/

      Sinon, pour le code propriétaire : https://en.wikipedia.org/wiki/VMware_ESXi#Lawsuit qui n'est qu'un exemple.

      Désolé de faire court, ma vie trépidante m'empêche d'être aussi prolixe. Mais j'ai bien apprécié l'effort, que j'ai pris le temps de lire.

  • # Le droit d'écrire

    Posté par  . Évalué à 4.

    Le débat m'évoque irrésistiblement une nouvelle lue sur Linuxfr il y a quelques années: Le droit d'écrire

    Merci encore à son auteur

    • [^] # Re: Le droit d'écrire

      Posté par  . Évalué à 2.

      Effectivement, je trouve le texte excellent. Par contre, « quelques » années n'est pas tout à fait exacte. On en est presque à deux fois sept ans ;)

  • # Détecteur de plagiat

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

    Ce type de filtrage me rappelle les filtres automatiques mis en place par les éditeurs de revues scientifiques.
    Ils mettent en place des filtres afin de détecter les plagiats. C'est une bonne chose en soit mais là aussi il y a des dérives. Par exemple, un collègue s'était vu refuser un de ses articles et après avoir bataillé quelques temps, il avait pu obtenir le rapport de la moulinette. Au final, il s'était "auto-plagié". Un petit paragraphe dans la partie "Matériel et méthode" était identique à un de ses précédents articles. Les conditions expérimentales étaient strictement identiques et il avait récupéré son propre texte. Au final, il a changé légèrement le texte, utilisé la voie passive et des synonymes mais cette situation profondément débile. La science derrière l'expérience n'a pas changé pour autant. Le nouveau texte est peut-être moins clair que le premier et l'auteur n'était pas lésé par la situation. Mais non, le détecteur de plagiat a parlé et il faut se soumettre au rapport.

    Les citations (avec style imposé) ont aussi tendance à augmenter le "score" et il est terriblement désolant de voir ces outils utilisés en dépit du bon sens. Effectivement, il est possible d'avoir quelques dizaines de lignes identiques à d'autres articles à la fin. Il s'agit tout simplement de l'état de l'art. Il n'y a aucune marge de manœuvre ici car le style des citations est imposé par la revue pour des raisons de cohérence (et c'est très bien comme ça).

Suivre le flux des commentaires

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