Du danger d’un acteur non-communautaire dans votre chaîne de production du Logiciel Libre

La récente affaire désormais connue sous le nom de npmgate (voir plus bas si cet événement ne vous dit rien) est encore une illustration à mon sens du danger intrinsèque d’utiliser le produit possédé et/ou contrôlé par un acteur non-communautaire dans sa chaîne de production du Logiciel Libre. J’ai déjà tenté à plusieurs reprises d’avertir mes consœurs et confrères du Logiciel Libre sur ce danger, en particulier au sujet de Github dans mon billet de blog Le danger Github.

L’affaire npmgate

Pour rappel sur cette affaire précise du npmgate, l’entreprise américaine Kik.com a demandé à l’entreprise npm Inc., également société américaine, qui gère le site npmjs.com et l’infrastructure derrière l’installeur automatisé de modules Node.js npm, de renommer un module nommé kik écrit par Azer Koçulu, auteur prolifique de cette communauté. Il se trouve qu’il est également l’auteur d’une fonction left-pad de 11 lignes massivement utilisée comme dépendance dans de très très nombreux logiciels enNode.js. Ce monsieur avait exprimé un refus à la demande de kik.com.

Npm-logo

Cette entreprise, qui pour des raisons obscures de droits d’auteur semblait prête à tout pour faire respecter sa stupide demande (elle utilise d’ailleurs elle-même du Logiciel Libre, à savoir au moins jquery, Python, Packer et Jenkins d’après leur blog et en profite au passage pour montrer ainsi sa profonde gratitude à l’égard de la communauté), s’est donc adressé à npm, inc, qui, effrayée par une éventuelle violation du droit d’auteur, a obtempéré, sûrement pour éviter tout conflit juridique.

Azer Koçulu, profondément énervé d’avoir vu son propre droit d’auteur et sa volonté bafoués, a alors décidé de retirer de la publication sur npmjs.com l’ensemble de ses modules, dont le très utilisé left-pad. Bien que npmjs.com ait apparemment tenté de publier un module avec le même nom, le jeu des dépendances et des différentes versions a provoqué une réaction en chaîne provoquant l’échec de la construction de très nombreux projets.

Sourceforge, Github, npmjs.com et … bientôt ?

Sourceforge, devant un besoin accru de rentabilité et face à la desaffection de ses utilisateurs au profit, on l’imagine, de Github, a commencé à ne plus respecter les prérequis essentiels d’une forge logicielle respectueuse de ses utilisateurs.

sourceforge-logo

J’ai présenté assez exhaustivement les dangers liés à l’utilisation de Github dans une chaîne de production du Logiciel dans mon article de blog le danger Github, à savoir en résumé la centralisation, qui avec de nombreux installeurs automatisés qui vont maintenant directement chercher les différents composants sur Github, si Github vient à retirer une dépendance, il se produira une réaction en chaîne équivalente au npmgate. Et cela n’est qu’une question de temps avant que cela n’arrive.

Autres risques, l’emploi de logiciel propriétaire comme l’outil de suit de bugs de Github issues, la fermeture et la portabilité limitées des données hébergées par eux et l’effet plus insidieux mais de plus en plus réel d’une sorte de fainéantise communautaire, inédite dans  notre communauté dans la recherche de solutions libres à des produits propriétaires existants et hégémoniques, sentiment également ressenti par d’autres.

github-logo

Le danger de l’acteur non-communautaire

Devant la massification des interdépendances entre les différents projets et le développement important du Logiciel Libre, aujourd’hui rejoint par les principaux acteurs hier du logiciel privateur comme Microsoft ou Apple qui aujourd’hui adoptent et tentent de récupérer à leur profit nos usages, il est plus que jamais dangereux de se reposer sur un acteur non-communautaires, à savoir en général une entreprise, dans la chaîne de création de nos logiciels.

microsoft-free.png

C’est un modèle séduisant à bien des égards. Facile, séduisant, en général peu participatif (on cherche à ce que vous soyez un utilisateur content), souvent avec un niveau de service élevé par rapport à ce que peut fournir un projet communautaire naissant, une entreprise investissant dans un nouveau projet, souvent à grand renfort de communication, va tout d’abord apparaître comme une bonne solution.

Il en va malheureusement bien différemment sur le moyen ou long terme comme nous le prouve les exemples suscités. Investir dans la communauté du Logiciel Libre en tant qu’utilisateur et créateur de code assure une solution satisfaisant tous les acteurs et surtout pérenne sur le long terme. Ce que chacun de nous recherche car bien malin qui peut prévoir le succès et la durée de vie qu’aura un nouveau projet logiciel.

6 thoughts on “Du danger d’un acteur non-communautaire dans votre chaîne de production du Logiciel Libre

  1. Oui, et non.
    Le problème tient autant du caractère de cochon du développeur, loin d’être désintéressé, qu’à un manque d’anticipation de kik.com (Une bonne partie de l’échange est ici : https://medium.com/@mproberts/a-discussion-about-the-breaking-of-the-internet-3d4d2a83aa4d#.avqiuwuw2).
    Le gentil développeur n’a pas hésité a demandé 30000$ en prenant la communauté en otage et à mettre sa menace à exécution lorsque cela lui a été refusé. Au final, ce que cela montre est qu’un développeur seul est moins fiable qu’une entreprise : npmjs a remis à disposition une archive des paquets qui posaient problèmes lorsque l’autre crétin se réjouissait d’avoir foutu un beau bordel.
    Sur les conclusions, ce que cela montre est qu’un système centralisé unique est problématique lorsqu’il est faillible. Il n’y a pas eu de problèmes avec CPAN, PyPi et plein d’autres systèmes centralisés fonctionnent depuis des années sans problèmes majeures. Le problème vient plutôt de la communauté autour de npm, et de l’écosystème Javascript dans son ensemble. Pourquoi rajouter une micro dépendance critique de 11 lignes dans un projet lorsqu’il est possible de rajouter de code dans la bibliothèque du projet ? Et je ne parle pas des dépendances d’une seule ligne… (cf http://lucumr.pocoo.org/2016/3/24/open-source-trust-scaling/). Bref, tu voulais taper sur les systèmes centralisés non-communautaires et c’est maintenant fait. Pour ma part, la faute est du côté du gars qui préfère prendre en otage une communauté plutôt que de discuter pour trouver une solution intelligente. Au fait, ça fonctionne bien chez wikipedia ?

    • La chronologie que tu annonces est erronée. Le dév donne une fin de non-recevoir à la demande de Kik, ce qui est son droit vu qu’il a l’antériorité sur le module et devrait se taper le boulot pour assurer la bonne compatibilité lors du changement de nom de toutes les dépendances. Bonne chance.
      C’est quand Kik le menace de faire appel à la Justice qu’il parle d’argent, sûrement uniquement dans le but de les embêter. S’il y a quelqu’un qui prend la communauté, c’est bien la société Kik qui est capable de tout pour faire respecter son nom, y compris à ne pas respecter le droit d’auteur des autres en passant par la société commerciale npmjs, apparemment plus sensible à éviter les ennuis judiciaires, et court-circuiter le développeur qui possède le droit d’auteur. On est clairement dans un cas de passage en force par Kik.

      En plus Kik reconnaît utiliser des logiciels libres dans l’échange que tu cites. Par contre ça leur fait ni chaud ni froid de court-circuiter les modèles et usages d’une communauté qui produit les logiciels qui leur servent à gagner de l’argent.

      Mais de toute façon le problème n’es pas de savoir qui a tort et qui a raison, mais sur la résilience et la pérennité du modèle de npm. L”article pointe surtout le fait que le problème dans la chaîne de construction des paquets st le statut d’entreprise commerciale de npmjs. Tu cites PyPI qui est géré par la fondation python, ce qu me semble un modèle beaucoup plus résilient que npmsj et npm, comme le démontre l’affaire du npmgate

  2. Autant je suis d’accord sur le principe de se méfier des plateformes centralisés et de la stupidité des dépendances externes, autant cet article perds énormément en crédibilité à cause de la manière dont il déforme les faits pour l’histoire de npm et kik ainsi que pour sourceforge.

    cette histoire kik.com vs Azer n’est pas la grande méchante corporation du mal contre le pauvre petit dev open source, mais un conflit de nommage entre une société qui produit du logiciel open source et un dev open source, conflit qui a été tranché par la platefrome centrale d’hébergement en faveur du moins de confusion pour les usagers.

    Azer se rendant compte que npm est un espace privé sur lequel il n’a aucun droit est parti ailleurs emmenant son code avec lui. Le problème ici n’est pas une question d’acteur communautaire mais de collision de nom faute de disposer d’espace de nommage et de reposer sur une plateforme tierce centralisée pour y héberger son code.

    Sourceforge c’est autre chose: en 2012 geeknet vends sourceforge (ainsi que slashdot et freecode) à dice.com, et passe dans les mains d’une boite qui ne sait pas gérer ce genre de site et cherche a maximiser les profits n’hésitant pas à recourir à des pratiques détestables au prix de la réputation du site. Pour finalement le remettre en vente face à leur incapacité à l’exploiter correctement, vente effective en janvier 2016 qui mets un terme à ces pratiques.

    Bref, écrire des articles pour exprimer son opinion, oui mais pas besoin de déformer les faits pour ça colle mieux avec ce que tu as à dire.

    • Tu ne sembles pas voir compris les enjeux de cette affaire. je vais donc les rappeler ici. Il s’agit parfaitement comme cause de l’effet présenté dans cet article d’un conflit de deux société Kik et Npm inc VS Azer Koçulu dans non pas un conflit de nommage, mais la requête d’une société privée Kik estimant être de son droit d’utiliser le nom kik pour un module déjà existant écrit par le très prolifique Azer Koçulu (Github impressionnant) auprès dans un premier temps dudit développeur puis dans une second temps du gestionnaire de npmjs et npm qui est la société Kik.

      Le conflit a été résumé ici https://medium.com/@mproberts/a-discussion-about-the-breaking-of-the-internet-3d4d2a83aa4d#.k4sxsuj6b et l’échange est accablant pour Kik et Npm. Ils se sont mis d’accord en dehors de l’accord de Azer Koçulu et pour Npm Inc. sous la menace insidieuse de poursuite judiciaire de Kik vers Npm Inc (étant donné qu’Azer s’est montré totalment non réceptif au chantage de Kik).

      Azer demande $30K, de mon point de vue ironiquement juste pour répondre aux menaces judiciaires de Kik. Et il a un coup de sang en dépubliant son code en sachant qu’il va causer un problème sur toute la chaie de dépendances. Ce qui est dommage mais le vrai problème n’est pas là.

      “In fact, once Azer had made it clear that he wasn’t going to change the name, we decided to use a different name for an upcoming package we are going to publish to NPM.”

      Et donc ? pourquoi continuer et menacer de poursuite judiciaire un auteur du Logiciel Libre sur une question de copyright, comportement à l’opposé des personnes qui évoluent dans le Logiciel LIbre ?

      “The wording we used here was not perfect. We’re sorry for creating any impression that this was anything more than a polite request to use the Kik package name on NPM for an open source project we have been working on that fits the name.”

      Et là un bel essai de ré-écriture de l’histoire, le “wording” et la “polite request” comportant une menace d’actions en justice grâce à leur gros copyright sur le mot kik dès lors que la partie adverse n’est pas d’accord avec eux. J’appelle ça de la propagande d’entreprise, par laquelle les entreprises réécrivent l’histoire et essaient de se donner le beau rôle, ce qu’a fait immédiatement Npm Inc de son côté avec ce billet http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm sur lequel ils ont bien sûr fermé les commentaires afin de ne pas avoir à répondre aux questions pressantes qui allaient suivre. Ce que les premiers commentaires mettent en avant.

      Le vrai problème est que ce cas de figure est possible. Le vrai problème est que la décision prise par Npm Inc n’aurait pas dû être prise par eux mais par un groupe de personnes dont le meilleur intérêt va dans la bonne marche de la communauté Npm et non d’un entreprise Npm Inc. et le fait qu’elle peut être attaquée judiciairement. Et c’était tout l’objet de mon article de mettre ce fait en avant.

  3. Je rejoins les deux commentaires précédents.
    Et je rajouterai : est-ce que le problème et le résultat auraient été différents si NPM inc, était une association libre ‘NPM ass’ produisant du logiciel libre dans un environnement libre ?
    Non, puisque le problème ici est le droit d’auteur et non une lutte libre/proprio ou gentil association/ méchante entreprise (ce qui semble ressortir de cet article). Même si Kik avait été une association également, elle a le droit de faire respecter sa marque…

    • Deux points de réponse :

      1/ si on a inventé les fondations et les associations, ça n’est pas pour rien. On a rien inventé de mieux pour défendre les intérêts de communauté, et on connaît depuis longtemps les travers dont sont victimes les entreprises qui essaient d’assumer ce rôle, j’en ai cité plusieurs dans l’article et mes deux précédents commentaires.

      Même si la propagande et la battage médiatique dont ces entreprises sont capables pour défendre leurs intérêts et faire passer leur vision sont parfois extrêmes, il faut savoir prendre de la distance et revenir aux fondamentaux du droit et à l’histoire.

      Les projets adossés à une fondation dans le Logiciel Libre sont légions (Linux, PostgreSQL, Python comme ça de tête) et ça s’explique car c’est un gage de stabilité, de pérennité et de bonne défense d’intérêt pour la communauté concernée. Maintenant tu peux tenter de réinventer l’histoire tous les jours si tu veux en imaginant qu’une entreprise soit gentille, bienveillante et attentif quoiqu’il arrive, mais les communautés détruites par un rachat de société dont les racheteurs ont des idées très différentes des fondateurs, ça arrive très régulièrement.

      2/ Par rapport au droit, il me semble ici que le seul point établi est que Kik a tenté de faire pression sur Azer et a réussi à faire pression sur Npm Inc. Savoir s’ils étaient dans leur droit requière à mon avis une analysé complexe pour savoir quelles sont les modalités du droit américain vis-à-vis de la défense des marques, si c’est applicable à des domaines différents, qui avait l’antériorité du nom kik etc. Je ne m’aventurerai pas sur ce terrain. Par contre je constate que Kik a massivement recours au Logiciel Libre (voir l’article et le blog de Kik qui évoquent souvent leur infrastructure) et qu’ils utilisaient déjà un nom alternatif à “kik” pour leur projet. Il s’agit donc d’une volonté délibérée d’affronter un projet du Logiciel Libre pour le contraindre à se plier au volonté peut-être non fondée juridiquement sans souci des dégâts potentiels sur cette communauté et les projets utilisant ce code en dépendance. Bref une méconnaissance complète ou une volonté d’ignorer la communauté du Logiciel Libre, ses usages et son fonctionnement.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *