Journal Elastic fait fermer les dépôts SearchGuard sur GitHub

24
20
sept.
2019

Elastic, l’entreprise derrière Elasticsearch, Logstash et Kibana, fait fermer les dépôts GitHub de SearchGuard, une extension de sécurité pour Elasticsearch sous le motif d’avoir copié le code propriétaire de X-Pack (rendu publique il y a quelques mois).

Floragunn, l’entreprise derrière SearchGuard, s’est défendu sur son blog d’avoir enfreint les droits d’Elastic.

Le dernier paragraphe de l’annonce d’Elastic est particulièrement croustillant (l’emphase est de moi) :

All Search Guard users are a part of the Elastic community, and it is unfortunate that floragunn’s actions may have put you in the position of running infringing code. As you consider your options, please be aware that Elasticsearch now includes free security features by default, which will help ensure you don’t need to run an unprotected cluster. We want to help, so please reach out to us at search-guard@elastic.co if you have questions.

En fait c’est de ça qu’il s’agit, Elastic fait fermer les dépôts d’un concurrent sous des motifs fallacieux. Et c’est tellement simple (j’aurai pu écrire la lettre de DMCA moi même) que ça fait peur.

Anecdote personnelle, j’avais assisté à une conférence d’un employé d’Elastic lors d’un Meetup Kubernetes à Montréal qui parlait d’Open Code (comprendre : c’est pas de l’open source parce que ça nous fait chier, mais on veut quand même la hype qui va avec).

  • # Elsa tique

    Posté par (page perso) . Évalué à 8 (+6/-0).

    Mon commentaire ne répond pas sur le fond mais il y a plus d’occurrences d’Elsatic que d’Elastic dans ton journal ! Je ne sais pas d’où vient ce lapsus mais il est intéressant ! 🙃

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

    • [^] # Re: Elsa tique

      Posté par (page perso) . Évalué à 2 (+1/-1).

      Haha, c'est juste des typos. Je veux bien qu'un modérateur corrige.

      • [^] # Re: Elsa tique

        Posté par . Évalué à -5 (+0/-7).

        Plus sérieusement, je t'invite à visionner cette vidéo avant d ete lancer dans ta diatribe freewashing.

        Voilaaa!

        • [^] # Re: Elsa tique

          Posté par (page perso) . Évalué à 10 (+28/-4).

          J’ai regardé la vidéo et franchement, j’ai un mauvais pressentiment sur l’avenir du logiciel libre.

          Déjà, ça m’énerve ce discours « ouin ouin, les gens y reprennent notre code et y paye même pas ». C’est le putain de deal quand tu fais du libre, fallait faire du proprio si tu voulais qu’on te paye des licences. Ah ben non, le proprio ça se vend pas aussi bien.

          Ensuite, j’ai récemment vu beaucoup de monde se demander si un changement vers du « libre sous condition » ne serait pas bénéfique. Par exemple parce que du logiciel libre est utilisé par l’ICE aux États-Unis, ou alors parce que Google et Amazon sont des crevards qui s’engraisse sur le dos des développeurs du libre (bénévoles ou non).

          Je pense sincèrement qu’on va se tirer une balle dans le pied à faire ça. Parce qu’à vouloir bloquer Google, on bloquera aussi Framasoft. À vouloir bloquer l’ICE, on bloquera aussi les associations qui se battent pour les migrants.

          Et dans tout ça, c’est Google et AWS qui se présenteront comme les grands défenseurs du libre et ils auront gagné.

          Trouvons un moyen de défoncer Google, AWS et l’ICE, ça fera plus de bien que de se défoncer nous même.

        • [^] # Re: Elsa tique

          Posté par (page perso) . Évalué à 6 (+6/-1).

          Résumer le libre à un modèle de diffusion montre clairement que le mec qui a écrit la présentation a raté un aspect majeur du libre : encadrer l'usage d'un logiciel revient à définir ses fonctionnalités.
          La licence est une fonctionnalité qui défini entre autre un modèle de diffusion.

          La présentation est empreinte de business prédateur, celui malheureusement majoritaire, où les buts sont d'avoir la rentabilité maximum et donc de devenir leader d'un marché quasi monopolistique.

          Dans ce cas, oui le libre n'est pas adapté car le libre ne permet pas de verrouiller un monopole (c'est une de ses principales fonctionnalités) : si on veut devenir monopolistique ou presque, il ne faut pas choisir le libre.

          De là a dire qu'il n'est pas viable de faire du libre…

      • [^] # Re: Elsa tique

        Posté par . Évalué à -7 (+0/-9).

        Et ce n'est pas comme si ce cher Arcaik s'était lancé dans la "Libre Entreprise" avant de déblatérer à tout va!

        Quels sont ses risques ?

        • [^] # Re: Elsa tique

          Posté par (page perso) . Évalué à 3 (+2/-1).

          Et tu le sais parce que ?

          • [^] # Re: Elsa tique

            Posté par . Évalué à 5 (+4/-1).

            En effet !

            Je reviens sur cette attaque inutile et purement basée sur l'émotion.
            Comme on ne peut éditer ses contributions, je te présente donc mes excuses !

    • [^] # Re: Elsa tique

      Posté par . Évalué à 2 (+1/-1). Dernière modification le 21/09/19 à 01:13.

      Je ne sais pas d’où vient ce lapsus mais il est intéressant !

      Elsaaaa Fraulein, de l'autre coté

    • [^] # Re: Elsa tique

      Posté par . Évalué à 2 (+0/-0).

      Fait, merci.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Elsa tique

        Posté par . Évalué à 4 (+2/-0).

        Il faudrait aussi corriger : "sous le motif d’avoir copi*er* le code propriétaire" => "sous le motif d'avoir copi*é*…"
        (markdown merde toujours autant…)

        • [^] # Re: Elsa tique

          Posté par . Évalué à 2 (+0/-0).

          Fait, merci

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # En outre...

    Posté par . Évalué à 5 (+5/-2).

    On notera, de mémoire:

    • qu'Elsatic, boite Hollandaise fait son procès à Floragunn, boite Allemande, aux États-Unis
    • ils ont bien demandé aux clients de Floragunn de se prononcer partie civile
    • Depuis peu, OpenDistro d'Amazon est disponible. C'est un plugin(?) aux fonctionnalités similaires à SearchGuard d'après ce que j'ai compris.
    • la plainte porte aussi sur du code semble-t-il déjà présent dans SearchGuard en 2015 alors que le code d'X-Pack n'était pas encore disponible, mais sans doute récupéré via décompilation.
    • certains projets sont certainement déjà en train de changer de solution, ou au moins d'y réfléchir sérieusement pour éviter les problèmes avant l'issue du procès. Aux States, ça rigole pas avec ces choses là. De toute, plus de support avant l'issue du procès.

    Pour les anglophiles, la lecture de la plainte est très intéressante. Je laisserai les extraits de code à votre humble appréciation.

    Par contre, sous-entendre qu'Elsatic, devant l'arrivée du grand Amazon, ai conclu un accord avec ce dernier pour évincer la concurrence en échange d'un respect minimum mutuel, ce serait un peu exagéré ؟

    • [^] # Re: En outre...

      Posté par (page perso) . Évalué à 1 (+1/-0). Dernière modification le 21/09/19 à 09:46.

      il y'a quand même pas mal de contributions de floragunn dans opendistro

      https://github.com/opendistro-for-elasticsearch/security-kibana-plugin/search?q=floragunn&unscoped_q=floragunn
      https://github.com/opendistro-for-elasticsearch/security/search?q=floragunn&unscoped_q=floragunn

      je ne crois pas qu'amazon puisse remplacer par le code d'elastic ouvert depuis qui doit être sous leur licence propriétaire.

      • [^] # Re: En outre...

        Posté par . Évalué à 3 (+1/-0).

        Le code d'Open Distro est bien en partie celui de Floragunn, mais je ne pense pas qu'ils aient utilisé le code sous copyright. Il se sont sans doute basé sur la version floss pour la faire.

        Et il n'est absolument pas question d'utiliser le code du X-pack, ils ont leur propre équivalent.

    • [^] # Re: En outre...

      Posté par (page perso) . Évalué à 4 (+1/-0).

      la plainte porte aussi sur du code semble-t-il déjà présent dans SearchGuard en 2015 alors que le code d'X-Pack n'était pas encore disponible, mais sans doute récupéré via décompilation.

      Ce qu'ils justifient en disant qu'ils ont décompilé le code. Vu que ça tourne sur la JVM, la décompilation est assez aisée.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: En outre...

        Posté par (page perso) . Évalué à 1 (+0/-2). Dernière modification le 22/09/19 à 18:42.

        Vu que ça tourne sur la JVM, la décompilation est assez aisée.

        Je n'ai pas compris cette partie.
        Que ce soit facile n'implique pas que ce soit légal : par exemple il est facile de faire un excès de vitesse en automobile.

        • [^] # Re: En outre...

          Posté par (page perso) . Évalué à 3 (+1/-1).

          Je ne comprends pas du tout ta remarque. Je dis que c'est aisée et que donc c'est tout à fait imaginable qu'ils l'aient fait sans trop de problèmes et qu'ils ont donc bien pu violer le droit d'auteur avant que les sources soient publiées.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: En outre...

            Posté par . Évalué à 1 (+0/-1). Dernière modification le 22/09/19 à 22:24.

            D'où le "mais sans doute récupéré via décompilation". Mais le fait que ce soit du code pour la JVM aide, en effet.

      • [^] # Re: En outre...

        Posté par . Évalué à 1 (+1/-0).

        J'ai eu la chance de rencontré Jochen Kressin, CEO et Co fondateur de SG à plusieurs reprises. https://www.linkedin.com/in/jkressin/

        Ce mec c'est un crack, spécialisé en sécu,

        Quand on regarde la timeline de la création d'un solution de sécu par Floragunn VS ce qu'a pu faire ES on voit qu'ils avaient déjà une longueur d'avance. Rien qu'a regarder depuis quand la communication inter-serveur est sécurisée via TLS dans les 2 cas (c'est la moindre des choses dans des transferts de data, non ?). https://search-guard.com/elasticsearch-security-free-search-guard/

        Pour moi c'est un pur "dick move" de la part d'ES, deal ou pas avec AWS.

        L'équipe de Redis, qui n'a peut-être pas choisit la bonne réponse (https://www.zdnet.com/article/redis-labs-and-common-clause-attacked-where-it-hurts-with-open-source-code/ et https://www.techrepublic.com/article/why-redis-labs-made-a-huge-mistake-when-it-changed-its-open-source-licensing-strategy/) - a, de mémoire, eu marre que les GAFAM se gavent sur leurs techno (parfois en rebrandant la techno simplement) et ne contribuent pas ou très peu et ne reverse pas une partie de leurs gain aux dev, parfois bénévoles dans le domaine de l'OpenSource.

        C'est la tendance pour moi côté OpenSource pour ces prochaines années.

        • [^] # Re: En outre...

          Posté par . Évalué à 2 (+1/-0).

          Rien qu'a regarder depuis quand la communication inter-serveur est sécurisée via TLS dans les 2 cas (c'est la moindre des choses dans des transferts de data, non ?).

          Je sais pas trop. Selon le profile de ta charge tu ne peux pas forcément faire du TLS ou en tout cas pas sans avoir un F5 devant chaque machine, mais du coup c'est entre tes nœuds et ton F5 que tu sécurise pas… Sincèrement je ne suis pas un crack et je ne fais pas forcément bien les choses, mais j'ai déjà rencontré des cas où je ne vois pas comment mettre en place du TLS sans complètement exploser sous la charge.

          • [^] # Re: En outre...

            Posté par (page perso) . Évalué à 3 (+0/-0).

            Je ne vois pas, avec des CPU actuels (qui ont notamment des instructions dédiés pour l'AES), comment tu fais pour avoir des problèmes de charge avec TLS. Surtout pour de la communication entre un faible nombre de machine. Si tu as un cas d'exemple, je suis vraiment preneur.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: En outre...

              Posté par . Évalué à 2 (+1/-0).

              Je vais le dire de manière plus exacte. Je ne suis pas certain de voir l'intérêt de ce genre d'architectures :
              architecture

              (où on voit en vert tout ce qui est TLS et en rouge tout ce qui n'est pas chiffré)

              Il faut vraiment craindre d'avoir des informations critiques en base qui ne viennent pas des utilisateurs (et qui ne leur sont pas transmises). Je ne doute pas que ça existe, mais c'est pas un cas courant amha.

              • [^] # Re: En outre...

                Posté par (page perso) . Évalué à 3 (+0/-0).

                Je ne vois pas pourquoi les flux en rouge ne serait pas chiffrés. L'avantage du tout chiffré, c'est d'éviter que la moindre machine qui voit passer le trafic (comme un switch) puisse le stocker/dévier pour le lire. Ça protège aussi d'un admin malveillant d'une de ses machines (pas des admin des machines où le trafic est déchiffrés bien sûr). Ça permet aussi d'autentifier tes machines. Pour être sûr qu'il n'y a pas un malin qui a spawner une machine et puisse récupérer les données.

                Après, je réagissais principalement sur les performances. Le tout TLS est pour moi loin d'être la principale priorité sur la plupart des infra. Et la gestion de l'expiration des certificats est bien plus problématique pour moi que les performances.

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: En outre...

                  Posté par . Évalué à 2 (+1/-0). Dernière modification le 26/09/19 à 15:11.

                  Je ne vois pas pourquoi les flux en rouge ne serait pas chiffrés.

                  Généralement si tu t'achète un F5 plusieurs dizaines de milliers d'euros, c'est parce que tu ne sais pas gérer ta charge TLS. L'exemple le plus récent pour moi c'est d'avoir des dizaines de milliers de mobiles qui viennent te faire une requête. Non seulement ils sont nombreux, mais ils ont tendance à consommer longtemps tes sockets parce qu'ils sont pas sur un réseau haut débit.

                  L'existence même de F5 ou le prix qu'AWS vend ses ELB1 montre que c'est une vraie problématique.

                  Après on est d'accord qu'avoir du TLS à tous les étages a pleins d'avantages. J'en suis absolument convaincu. C'est juste que je vois "facilement" les cas où ça paraît difficilement faisable (on peut toujours acheter plus de machines plus grosses).

                  Le tout TLS est pour moi loin d'être la principale priorité sur la plupart des infra. Et la gestion de l'expiration des certificats est bien plus problématique pour moi que les performances.

                  Ah oui avec une vraie PKI c'est encore autre chose :)


                  1. il faut regarder les ELB avec trafic garanti sinon ça coûte rien 

                  • [^] # Re: En outre...

                    Posté par (page perso) . Évalué à 3 (+0/-0).

                    Perso, j'ai servi facilement 200Mbps de trafic avec un nœud arm chez scaleway il y a 2 ou 3 ans. C'est pour ça que je vois mal la question de la perf.

                    Perso, les gens que j'ai vu acheté du F5 récemment, c'était pour la sécurité (genre filtrage de client), pas pour les perfs. Des dizanes de milliers de mobile, 4a me semble assez facile de répartir avec un load-balancer tcp en front avant d'avoir les front qui exposent le TLS.

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                    • [^] # Re: En outre...

                      Posté par . Évalué à 2 (+1/-0).

                      Perso, j'ai servi facilement 200Mbps de trafic avec un nœud arm chez scaleway il y a 2 ou 3 ans. C'est pour ça que je vois mal la question de la perf.

                      Le débit ça coûte rien. C'est du chiffrement symétrique si je ne m'abuse. Il te faut juste un gros CPU. Ce qui peut te flinguer c'est par exemple l'ouverture de connexion. Ouvrir 10k connexions TLS par seconde ça commence à demander de l'entropie, du chiffrement asymétrique pour l'échange de clef, de la validation de certificat, de la deserialisation de certificats1,… Tout ça va impacter sensiblement ta latence.

                      Des dizanes de milliers de mobile, 4a me semble assez facile de répartir avec un load-balancer tcp en front avant d'avoir les front qui exposent le TLS.

                      En IPv4 (c'est pas ma décision), ton loadbalancer va devoir gérer du NAT, ce qui va lui demander pas mal de RAM, mais oui ça consiste à multiplier ton nombre de machines. C'est un choix ça a un coût, ça se calcul.

                      Mon point n'est pas forcément de dire que c'est impossible juste que ce n'est pas aussi évident que « c'est un minimum ». Ce n'est pas forcément trivial à mettre en place selon le contexte.


                      1. je ne l'avais pas benché et je ne pensais pas que ça puisse poser problème, mais ça a l'air d'être sensible https://jbp.io/2019/07/01/rustls-vs-openssl-performance.html 

                      • [^] # Re: En outre...

                        Posté par (page perso) . Évalué à 4 (+1/-0). Dernière modification le 26/09/19 à 16:27.

                        Ouvrir 10k connexions TLS par seconde ça commence à demander de l'entropie, du chiffrement asymétrique pour l'échange de clef, de la validation de certificat, de la deserialisation de certificats1,… Tout ça va impacter sensiblement ta latence.

                        Je suis d'accord que ça a un coût. Mais l'exemple que tu donne montre qu'il fait 1300 handshakes par seconde sur une machine assez petite. Donc même 10k, ça ne doit pas être difficile à atteindre. Surtout que si tu as 10k sessions par secondes, ton infra derrière doit encaisser aussi le trafic hors chiffrement.

                        En IPv4 (c'est pas ma décision), ton loadbalancer va devoir gérer du NAT,

                        Là, je ne vois pas. Ton loadbalancer reçoit une connexion et en ouvre une autre. Je ne vois pas où est le NAT dans l'histoire. C'est même un moyen de se "passer" de NAT.

                        ce qui va lui demander pas mal de RAM,

                        En gros, le nat, c'est 32 bits d'IP sources, 16 bits de ports multiplié par deux pour la traduction. Ça fait donc 96bits par session. Donc pour 10k connexions, tu es à 110Kio. Si tu ajoute un timestamp pour les faire expirer, ça fait 160bits par connexion et on approche des 200Kio.

                        Mon point n'est pas forcément de dire que c'est impossible juste que ce n'est pas aussi évident que « c'est un minimum ». Ce n'est pas forcément trivial à mettre en place selon le contexte.

                        Je suis d'accord qu'il ne suffit pas de faire apt-get install openssl. Mais ça ne semble pas non plus hors de portée de la plupart des gens sérieux.

                        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: En outre...

              Posté par . Évalué à 0 (+0/-1).

              comment tu fais pour avoir des problèmes de charge avec TLS. Surtout pour de la communication entre un faible nombre de machine. Si tu as un cas d'exemple, je suis vraiment preneur.

              OpenVPN utilise TLS et ses limitations sont facilement testable avec pivpn et wget.

              🇪🇺

              • [^] # Re: En outre...

                Posté par (page perso) . Évalué à 4 (+1/-0).

                OpenVPN utilise UDP par défaut (et donc pas TLS), donc tu ne va pas tester les performances de TLS. wget tout seul utilise TLS si tu télécharge depuis un site en HTTPS et tu verra que tu obtiens des perfs bien meilleurs en TLS sans passer par OpenVPN.

                (La consommation de ressource d'OpenVPN est connue et n'est pas lié à TLS mais à l'architecture et au switch kernel/user mode)

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: En outre...

                  Posté par . Évalué à 2 (+1/-0). Dernière modification le 26/09/19 à 15:01.

                  et donc pas TLS

                  Ah, tu as en partie raison : "As such, we believe TLS is an excellent choice for the authentication and key exchange mechanism of a VPN product." (source)

                  Ce qui explique pourquoi "TLS" revient régulièrement dans les logs d'OpenVPN.

                  🇪🇺

                • [^] # Re: En outre...

                  Posté par . Évalué à 1 (+0/-0).

                  OpenVPN utilise UDP par défaut (et donc pas TLS)

                  Je ne me suis pas vraiment penché dessus, mais de ce que j'ai compris des micro présentation il semble que HTTP/3 soit UDP+TLS (ne me demande pas comment c'est possible).

                  • [^] # Re: En outre...

                    Posté par (page perso) . Évalué à 3 (+0/-0). Dernière modification le 26/09/19 à 16:14.

                    À ma connaissance, TLS est n'est pas utilisé dans HTTP/3 mais est modifié pour fonctionner avec QUIC (à la manière de DTLS).

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                • [^] # Re: En outre...

                  Posté par (page perso) . Évalué à 2 (+0/-0).

                  UDP et TLS ne sont pas antinomique : Datagram Transport Layer Security.

                  Et de mémoire, OpenVPN n’utilise TLS que pour le le canal de contrôle, pas pour le canal des données (qui sont chiffrées différemment).

                  • [^] # Re: En outre...

                    Posté par (page perso) . Évalué à 3 (+0/-0).

                    DTLS n'est pas TLS. Même si c'est bien sûr très proche.

                    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: En outre...

      Posté par (page perso) . Évalué à 5 (+4/-0).

      "Delaware et Hollande", ca sent l'évasion fiscale à plein nez.

  • # Oss

    Posté par . Évalué à 7 (+7/-0).

    Toutes les outils elastic (elasticsearh, logstash, beats) sont disponibles *aussi en saveur oss sous licence apache 2.

    Perso, après avoir lu leur licence elastic, j'ai banni cette dernière et réorganisé mes projets utilisant elastic afin qu'ils se content des versions oss…

    Certes ça ne résoudre pas la question x-pack vs searchguard, et on est d'accord que le procédé employé ici est clairement dégueulasse… Mais je voulais tout de même rappeler que le core est bel et bien libre.

    • [^] # Re: Oss

      Posté par . Évalué à 2 (+1/-0).

      Si on prend le cas d'elasticsearch, cela reste tres problematique combien meme le coeur est libre:
      Ils ont tout mis dans le meme depot git, que ce soit la partie libre ou la partie pas libre. Du coup ce qui se passe dedans n'est pas forcement clair (ex: si je construit un tar, comment ca se passe?) mais cela rend plus complique toute contribution (ex: j'ai du code a contribute mais ca risque de casser une de leur partie proprio or entre en concurrent).
      De meme il n'y a pas vraiment de communaute de developpeurs pour elasticsearch, seulement des utilisateurs. Note: Avoir une visibilite dans les tickets et pr du repository ne compte pas vraiment comme communaute.

  • # motif fallacieux ?

    Posté par . Évalué à 10 (+8/-0).

    Je ne comprends pas trop, pourquoi un motif fallacieux ? Ce n'est pas parce qu'ils disent que la fonctionnalité incriminée est maintenant dans leur code que c'est pour cette raison qu'ils ont fait fermer le concurrent. L'argument d'avoir la fonctionnalité, c'est plutôt pour signifier à leurs clients : "arrêtez d'utiliser le produit concurrent qui bafoue notre licence, utilisez plutôt l'original qui fait la même chose maintenant".

    La raison évoquée c'est que du code proprio rendu public a été utilisé chez ce concurrent :

    "About a month after we made the code of our proprietary features publicly accessible, developers of Search Guard directly copied the source code"

    et qu'en plus des éléments de code ont été retrouvé avant la publication, chez ce même concurrent, alors que le code n'avait pas encore été rendu public, ce qui leur fait penser que les concurrents ont décompilé leurs binaires (je ne vois rien de mal à ça, je ne sais pas si c'est légal ou pas…) :

    "Most of these instances of copying occurred before we opened our proprietary code last year, which means the Search Guard developers intentionally decompiled our binary releases in order to copy our code. "

    Je ne sais pas si ce qui est dit dans leur lettre est vraie ou pas, mais ça me semble justifier la demande de fermeture, et l'ouverture d'un procès. Je ne connais aucune des deux parties et je n'utilise aucun des logiciels évoqués, c'est juste une question de logique. On trouverait normal de faire un procès à une boîte qui utilise du code sous GNU GPL pour le réinjecter dans du code proprio.

    • [^] # Re: motif fallacieux ?

      Posté par . Évalué à 10 (+9/-0).

      ce qui leur fait penser que les concurrents ont décompilé leurs binaires (je ne vois rien de mal à ça, je ne sais pas si c'est légal ou pas…)

      C'est bel et bien illégal, même en France (premier lien trouvé). Ce ne peut être fait que pour des raisons d’interopérabilité avec un logiciel indépendant.

      Je ne sais pas si ce qui est dit dans leur lettre est vraie ou pas, mais ça me semble justifier la demande de fermeture, et l'ouverture d'un procès.

      Je trouve justement les éléments avancés dans le document comme très limite pour considérer qu'il s'agit d'une copie. Quand on doit correspondre à une interface, utiliser l'API du logiciel pour lequel on crée le plugin et que le scope de ces méthodes est très limité, on se retrouve très rapidement avec du code similaire. Pareil pour la configuration.

      Maintenant, je ne connais pas le droit Américain, je suppose qu'ils ne sont pas obligés d'exposer l'entièreté des griefs dans le document et qu'ils ont gardé le plus croustillant pour le procès, mais dans le cas contraire, j'ai l'impression que beaucoup de logiciels ont décompilé leurs plugins.

  • # Alternatives

    Posté par (page perso) . Évalué à 2 (+0/-1). Dernière modification le 21/09/19 à 13:13.

    Quels sont les alternatives à Elastic Stack?

    Incubez l'excellence sur https://linuxfr.org/board/

    • [^] # Re: Alternatives

      Posté par . Évalué à 7 (+6/-0). Dernière modification le 21/09/19 à 13:53.

      Ça dépend de ce que tu fais.

      Si tu t'intéresse à ELK (Elasticsearch Logstash Kibana) pour manager tes logs, il y a pas mal d'alternatives comme graylog, grafana ou chronograf. Je ne parle là que des solutions libres tu a des alternatives non libres comme splunk, dynatrace ou new relic qui sont très connues.

      Si tu cherche à avoir un moteur d'indexe pour faire des recherches fulltext, tu as apache solr. Comme elasticsearch c'est basé sur la bibliothèque lucene. Je ne sais pas ce que vaut lucene face à elasticsearch.

      • [^] # Re: Alternatives

        Posté par (page perso) . Évalué à 3 (+1/-0).

        Grafana dessine des courbes et est plutôt complémentaire, quant à Graylog, il utilise ElasticSearch comme stockage.

        • [^] # Re: Alternatives

          Posté par . Évalué à 4 (+3/-0).

          Grafana peut très bien le faire avec loki.
          Pour graylog, tu as raison c'est un oubli de ma par.

          • [^] # Re: Alternatives

            Posté par (page perso) . Évalué à 2 (+0/-0).

            Je ne connaissais pas Loki. Est-ce que ça fonctionne vraiment bien, autrement dit, peut-on faire autant qu'avec Graylog ou Kibana en termes d'analyse de logs, de Dashboard ou d'alertes ?

      • [^] # Re: Alternatives

        Posté par . Évalué à 5 (+4/-0).

        Chronograf est un autre product open core, que je ne compterai pas dans la categorie libre. Pour rappel, les gars d'influxdata, qui sont derriere chronograf, sont les memes qui ont enleve tout code lie au clustering d'influxdb pour le rendre proprietaire et rabaisser le coeur libre.

        Elasticsearch n'est que l'enrobage de la bibliotheque Apache Lucene dans un service distribute. Donc on peut arriver a la meme chose avec Apache Solr qu'Elasticsearch. L'avantage d'elasticsearch est qu'il a ete longtemps l'outil le plus facile a deployer et a integrer avec des connecteurs pour tout ce qui est a la mode et le fait que l'on pouvait envoyer des documents sans avoir a definir de schema au prealable. Apache Solr Cloud s'est pas mal ameliore en terme de facilite d'utilisation depuis.
        D'ailleurs pour tous mes prochain projets, je vais regarder en premier Apache Solr.

        • [^] # Re: Alternatives

          Posté par (page perso) . Évalué à 3 (+2/-1). Dernière modification le 22/09/19 à 15:54.

          Je crois qu'il n'y a jamais eu de clustering dans influxdb. Pour ça, ils avaient implémenté infludb-relay puis ils l'ont abandonné quand la fonctionnalité est devenu payante (Vente Privé/“We Pee” maintient un fork).

          Par contre la stack TICK est libre : open core ne veut pas dire non libre.

          • [^] # Re: Alternatives

            Posté par . Évalué à 3 (+2/-0).

            influxdb-relay est quelque chose d'autre.
            Voir https://www.influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/ pour plus de details. Mais en gros:

            Next week we’ll be cutting the first release candidate for the 0.11.0 release. While this release includes significant improvements in the query engine and the clustering code base, it will be the last open source version that includes clustering. In April, we’ll release 0.12.0, which will be fully open source and have great new features, but it will be focused on the standalone InfluxDB server. Both of these will be drop in replacements for the current stable 0.10.3 release.

            For our users looking for free open source options, we’ll be releasing the open source InfluxDB Relay project along with a landing page how to achieve high availability using pure open source and subscription options with the 0.12.0 releases and beyond. From that point forward our clustering efforts will be focused on the closed source Influx Enterprise offering.

            Dans les projets libres que je recommande, je ne regarde pas juste la license du logiciel mais aussi si il y a une communaute autour. Un logiciel libre pousse par une boite sans communaute se rapproche plus d'un shareware que d'un logiciel dans l'esprit du libre. Et note que c'est voulu et admis (de facon semi-ouverte) par la plupart de ces boites.
            Et pour rappel, voici ce qu'a dit le CEO de mongodb recemment:

            [W]e didn't open source it to get help from the community, to make the product better. We open sourced as a freemium strategy; to drive adoption.

            La plupart de ces boites veulent beneficier de l'aura positive des logiciel libres sans pour autant s'y investir completement. Realistiquement, ells vont mettre des barrieres a la contribution tiers.

            En tant qu'utilisateur, je veux m'assurer les que les interets des utilisateurs passe en premier pour eviter que d'autres ennuis comme le clustering d'influxdb ne m'arrive. Je veux aussi pouvoir contribuer de facon positive au projet si necessaire et meme beneficier du choix de plusieurs fournisseurs de services si necessaire. Et c'est bien pour ca aussi que le motto non-officiel de l'ASF est "community over code".

            • [^] # Re: Alternatives

              Posté par . Évalué à 5 (+4/-0).

              J'allais te dire que pour ça il y a les fondations comme Apache ou Eclipse qui sont là pour établir un standard de projet.

              On entends régulièrement que ce sont des cimetières de projets abandonnés, mais pour Apache, si tout projet peut rejoindre l'incubateur, seul les projets qui ont certaines propriétés peuvent en sortir. On peut retrouver tout ce qui est « Apache Way » dans le projet incubator. Outre la crainte d'une entreprise non libre, Apache donne un cadre pour éviter les batailles de gouvernance. Ça évite à chaque projet de définir des documents comme la constitution Debian pour s'organiser.

              Ils imposent une forme de gouvernance, elle ne plaît pas forcément à tout le monde ou a tous les projets, mais ça permet de savoir que lorsqu'il y a Apache dans le nom d'un logiciel on sait comment il est fait1.


              1. ça va assez loin parce que la fondation peut reprocher de ne pas assez communiquer sur un logiciel avec Apache. Par exemple si tu es une entreprise qui travaille sur « Apache SpamAssassin », il faut que ta communication explicite bien « Apache SpamAssassin » pour que ça ne puisse devenir de la pub déguisée pour ta version propriétaire « Better SpamAssassin » que tu vend de ton coté. 

              • [^] # Re: Alternatives

                Posté par . Évalué à 2 (+1/-0).

                Tout a fait! Et c'est l'un des gros avantages de l'ASF!
                Ceci dit l'ASF n'est pas completement immunise contre ce genre de tactiques. Voir par exemple tous les coups bas entre les differentes boites liees au big data et comment ils ont fait le forcing pour enlever la clause de diversite pour la graduation de l'incubateur.

          • [^] # Re: Alternatives

            Posté par (page perso) . Évalué à 6 (+4/-1).

            La stack TICK c'est l'attac?

            Incubez l'excellence sur https://linuxfr.org/board/

      • [^] # Re: Alternatives

        Posté par . Évalué à 4 (+2/-0).

        Si tu cherche à avoir un moteur d'indexe pour faire des recherches fulltext, tu as apache solr. Comme elasticsearch c'est basé sur la bibliothèque lucene. Je ne sais pas ce que vaut lucene face à elasticsearch.

        Lucene ne gère pas la distribution des données ou des calculs, c'est elasticsearch ou solr qui s'en charge.

        Donc si tu veux travailler sur de la recherche fulltext tu n'utilises pas lucene directement sauf si tu connais assez bien tes besoins en calculs distribués et que tu veux réécrire cette couche toi même.

        • [^] # Re: Alternatives

          Posté par . Évalué à 5 (+4/-0).

          Dans ma dernière phrase il fallait lire solr et pas lucene.

          Mais lucene est tout à fait utilisable tel que selon les besoins que tu as. Si ton besoin d'indexation est simple, ça peut valoir le coup de ne pas avoir à déployer un cluster solr/es. Tu n'a pas toujours besoin que ton index soit mis à jour en temps réel (pleins d'utilisateurs d'ES ne sont déjà pas temps réel) et si ton index n'explose pas (par exemple tu veux un index par utilisateur avec des quantités de données soumis à quotas), ça peut très bien le faire.

          Par contre es est tellement simple à mettre en place et bien documenté que généralement ça n'a pas de sens de ne pas s'en servir (et il ne te limitera pas dans tes usages futurs).

      • [^] # Re: Alternatives

        Posté par (page perso) . Évalué à 2 (+1/-0).

        Une alternative méconnue (car libérée récemment) est Vespa (vespa.ai). Le language de requetage est moins riche qu'elasticsearch, mais les performances sont excellentes et les possibilités concernant le tri des résultats sont vraiment très larges.

    • [^] # Re: Alternatives

      Posté par . Évalué à -1 (+0/-3). Dernière modification le 21/09/19 à 18:04.

      Il y a bien splunk mais c'est encore moins libre (et c'est pas gratuit non plus).

      EDIT: mentionné avant, vous pouvez moinsser…

    • [^] # Re: Alternatives

      Posté par . Évalué à 4 (+4/-0).

      Sinon comme moteur de recherche fulltext, j'utilise xapian sur un projet en cours et j'en suis plutôt satisfait.
      Rapide, en C++ (avec des bindings python), relativement bien documenté et complètement open-source (GPL).

  • # GitHub

    Posté par (page perso) . Évalué à 10 (+9/-0).

    Ce qui m'ennuie le plus dans tout ça, ce n'est pas qu'une boîte s'attaque à ce que fait une autre sous des motifs peut-être fallacieux. C'est choquant si vous voulez, mais pas du tout inhabituel.

    Là où ça devient amusant, c'est que sans cette centralisation sur GitHub, il ne se serait rien passé du tout, enfin, peut-être un procès, mais pour les utilisateurs, rien du tout. Sauf que là, on a une dépendance à GitHub, et il ne faut pas grand chose pour les convaincre de fermer un dépôt. C'est amusant, tous ces problèmes, quand on les observe de l'extérieur.

    • [^] # Re: GitHub

      Posté par . Évalué à 7 (+6/-0). Dernière modification le 23/09/19 à 10:54.

      Là où ça devient amusant, c'est que sans cette centralisation sur GitHub, il ne se serait rien passé du tout, enfin, peut-être un procès, mais pour les utilisateurs, rien du tout. Sauf que là, on a une dépendance à GitHub, et il ne faut pas grand chose pour les convaincre de fermer un dépôt. C'est amusant, tous ces problèmes, quand on les observe de l'extérieur.

      Je doute que ce soit la difficulté technique de répliquer le dépôt qui les gêne.
      Aujourd'hui les utilisateurs de SearchGuard ne sont techniquement pas impactés. Le site officiel est toujours là, tu peux toujours télécharger la version que tu souhaite sans difficulté. Les utilisateurs qui ne se renseignent pas ne savent même pas qu'il y a un litige.

      Ce qui fait fuir les utilisateurs aujourd'hui, c'est la crainte du procès.

      Pour ce qui est des développeurs :

      • soit le coté réseau social/communautaire de github est important et du coup oui c'est un coup dur, mais c'est la centralisation même de github qui était recherchée1
      • soit on se fou de ça et ils ont déjà répliqué le dépôt sur gitlab ou en auto hébergé et ça leur a donné quelques heures d'indisponibilité

      Quant à la décision de github, elle est discutable, mais pas forcément choquante. Personne ne s'est pleins quand ils ont détruit le dépôt de deep-nude par exemple. Ils se donnent un droit de regard sur les dépôts, ils ne veulent pas prendre de risque.


      1. il n'existe à ma connaissance pas aujourd'hui de plateforme d'hébergement de code acentré/fédéré/décentralisé qui ai suffisamment de popularité pour concurrencer github 

      • [^] # Re: GitHub

        Posté par . Évalué à 2 (+3/-1).

        Github s'autorise à fermer ce qu'il veur, comme Google avec le store Android. C'est le risque d'avoir des entreprises privées en situation de quasi monopole.

        • [^] # Re: GitHub

          Posté par . Évalué à 3 (+3/-1).

          Bof… Framasoft s'autorise tout autant à supprimer du contenu. Le spectre de la loi est toujours le même. On avait un contributeur framasoft qui l'expliquait clairement ici même.1

          Framagit est ouvert à toute personne respectant nos CGU (après, nos CGU nous autorisent justement à virer n'importe quel utilisateur/données qui ne conviendraient pas à l'asso de façon autoritaire (je rappelle que si certains font de la merde avec nos services, c'est nous qui pouvons aller en taule).

          C'est génial cette croyance qu'ils faut appliquer les décisions de justices avant que celles-ci soient prononcée…

          Et la réforme du droit d'auteur européen semble malheureusement leur donner raison en demander à faire des vérifications à priori…

          Bref je vois pas ce que l'« entreprise privée » ou le monopole changent quelque chose à ça.


          1. pour vérification on peut trouver les cgu de framagit ici https://framasoft.org/fr/cgu/ 

        • [^] # Re: GitHub

          Posté par . Évalué à 3 (+2/-0).

Envoyer un commentaire

Suivre le flux des commentaires

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