J'ai vu passer cette information qui pose problème. On a interfacé Tracim avec Elastic search ; la question aujourd'hui est : vers quelle solution alternative peut/doit on s'orienter ?
Rester bloqué sur des versions encore sous licence libre ? Passer sur Solr ? Autre solution ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
OpenDistro c'est un packaging de ElasticSearch dans sa version sous licence Apache-2 mais ce n'est pas un projet de développement et d'évolution du moteur
le fork initié par Amazon est:était plutôt hostile ; je ne sais pas trop quoi en penser.
S'opposer au business de Elastic sur fond de version "entreprise" propriétaire je suis relativement d'accord, mais d'un autre côté, visiblement c'est LE modèle économique le plus utilisé en logiciel libre (mattermost, gitlab, etc).
Merci pour les liens en tout cas.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Je voulais sécuriser le mien, le choix entre xpack et searchguard (testé les deux, et xpack était clairement plus simple techniquement parlant). Mais payant (l'un sous licence, et l'autre, je pense que j'aurai pu convaincre mes managers qu'un geste aurait été pas mal).
Merci pour la référence. Je ne pensais pas que Elastic était agressif-offensif mais agressif-défensif. Ce journal laisse penser qu'en fait c'est quand même pas tout à fait dans leur philosophie de faire du libre…
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Je me suis probablement mal exprimé sur la chronologie. Quand j'ai tenté la sécurisation, xpack était une option payante (avec version d'essai gratuit), et searchguard (open source sur la base, et options payantes pour plus) ; la "guerre" n'était pas engagée, j'ai donc pu rapidement tester les deux, et clairement xpack était plus facile de déploiement, mais certainement avec moins de fonctionnalités.
C'est après que le rouleau compresseur s'est mis en marche. Je n'étais plus dans la même société, donc plus impacté directement, mais j'ai trouvé l'attitude pitoyable, genre : Bon bin on a mis en "libre", donc maintenant, vous, vous pouvez fermer la boutique.
J'ai pas trop suivi la suite, mais floragunn semble toujours en vie.
Je me suis probablement mal exprimé sur la chronologie.
Non. C'était clair ;)
Nous avons choisi de passer la sécurité en basic afin de pouvoir avoir des un opérateur Kubernetes. Je crois, de mémoire, qu'il fallait qu'il soit sécurisé par défaut.
C'était de toute façon dans les tuyaux de mettre ça en gratuit. Le projet ECK (Elastic Cloud for Kubernetes) a fait avancer plus rapidement notre décision.
mais floragunn semble toujours en vie.
Oui. Je le crois aussi.
Je n'étais pas dans les discussions légales mais de mémoire également, il me semble que le problème que nous avions eu à l'époque avec ce code est qu'il s'agissait d'une copie de notre code source par moment et qu'il y avait eu visiblement une décompilation de xpack pour disons "s'inspirer" de notre implémentation de sécurité. A l'époque, le code source de xpack n'était pas publique. Quand nous l'avons publié, les analogies sont devenues plus évidentes.
Je crois que depuis le code en question a été réécrit.
Oui. Tout dépend de ce qu'on entend par libre en effet.
Il y a effectivement un cas (et à ma connaissance uniquement celui-là) qui fait que tu n'es pas libre de faire tout ce que tu veux avec le code source. Tu ne peux pas commercialiser un service SaaS (Elasticsearch as a Service) sans un partenariat ou une license adéquate ou alors tu t'engages également à publier le code source qui te permet aussi de faire tourner ton service.
Tout le reste est "libre" au sens que tu peux faire ton business en utilisant la partie gratuite d'Elasticsearch, sans reverser la moindre chose, ni revenus, ni code source, …
En tout cas, j'espère avoir clarifié pour nos nombreux utilisateurs actuels qu'ils peuvent continuer à utiliser les projets elastic comme ils l'ont toujours fait jusqu'à ce jour.
Enfin, en dernier lieu, je me permets d'ajouter l'adresse email à contacter (elastic_license@elastic.co) si jamais quelqu'un a le moindre doute sur ce qu'il fait et souhaite avoir un email qui valide que l'utilisation qui est faite est bien conforme.
Est-ce que la licence AGPL ne répondait pas à cette problématique. Si "non", quelle est la différence ? Car il me semblait que AGPL répondait bien à cette problématique.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
Tout dépend de ce qu'on entend par libre en effet.
Rien à voire avec "on entend", il y a une définition précise.
Tu ne peux pas commercialiser un service SaaS
Donc pas libre.
En gros, ça ne change rien à votre activité…
Ca change tout, pour qui souhaite du libre à du non libre.
En tout cas, j'espère avoir clarifié pour nos nombreux utilisateurs actuels qu'ils peuvent continuer à utiliser les projets elastic comme ils l'ont toujours fait jusqu'à ce jour.
Ben non, c'est retiré de Debian par exemple.
Bref, il faut appeler un chat un chat : ce n'est plus libre, et ça change tout pour qui souhaite que du libre.
# Plus de liens
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
https://en.wikipedia.org/wiki/Server_Side_Public_License
https://anonymoushash.vmbrasseur.com/2021/01/14/elasticsearch-and-kibana-are-now-business-risks
https://www.reddit.com/r/fsf/comments/9ovt4z/thoughts_on_mongodbs_new_server_side_public/
https://www.reddit.com/r/opensource/comments/kxdjs3/with_todays_relicensing_to_sspl_elasticsearch_and/
https://lwn.net/Articles/768670/
…
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
# Quelle alternative ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 6.
J'ai vu passer cette information qui pose problème. On a interfacé Tracim avec Elastic search ; la question aujourd'hui est : vers quelle solution alternative peut/doit on s'orienter ?
Rester bloqué sur des versions encore sous licence libre ? Passer sur Solr ? Autre solution ?
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Quelle alternative ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
https://linuxfr.org/users/devnewton/liens/elastic-search-preforke -> https://opendistro.github.io/for-elasticsearch/ ?
[^] # Re: Quelle alternative ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Si jai bien compris :
S'opposer au business de Elastic sur fond de version "entreprise" propriétaire je suis relativement d'accord, mais d'un autre côté, visiblement c'est LE modèle économique le plus utilisé en logiciel libre (mattermost, gitlab, etc).
Merci pour les liens en tout cas.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Quelle alternative ?
Posté par Benoît Laurent (site web personnel) . Évalué à 2.
C'est une très bonne question. Je garde pas mal de lien vers des solutions de moteurs de recherche.
Ça dépend beaucoup de l'échelle. Si c'est pour votre offre SAS, je crois que Solr à maintenant une solution de cluster.
Si c'est plus petit, on trouve pas mal de choses, à commencer par les solutions sur des bases de données.
Ou alors des choses un peu plus spécialisée, comme côté Rust :
https://github.com/meilisearch/MeiliSearch
https://github.com/tantivy-search/tantivy
Côté Go :
https://github.com/mosuka/blast
Où même C++ avec https://github.com/Kronuz/Xapiand
Ou encore https://github.com/pgroonga/pgroonga
Attention, ce ne sont que des bookmarks, je ne les ai pas essayés !
[^] # Re: Quelle alternative ?
Posté par _kaos_ . Évalué à 2. Dernière modification le 15 janvier 2021 à 16:35.
Salut,
Le gros de la question est : pour quoi ?
Si c'est de la NLP, en allant plus bas (lucene), ça se fait. Si c'est indexer/versionner, là, lucene, ça sera probablement chaud.
Et perso, j'ai perdu foi en elasticsearch à peu près là :
elasticsearch vs searchguard
Je voulais sécuriser le mien, le choix entre xpack et searchguard (testé les deux, et xpack était clairement plus simple techniquement parlant). Mais payant (l'un sous licence, et l'autre, je pense que j'aurai pu convaincre mes managers qu'un geste aurait été pas mal).
Donc voilà, la concurrence, ça s'écrase…
Matricule 23415
[^] # Re: Quelle alternative ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Merci pour la référence. Je ne pensais pas que Elastic était agressif-offensif mais agressif-défensif. Ce journal laisse penser qu'en fait c'est quand même pas tout à fait dans leur philosophie de faire du libre…
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Quelle alternative ?
Posté par dadoonet (site web personnel) . Évalué à 0.
A noter que Elasticsearch fournit aujourd'hui une version gratuite de la sécurité.
Developer | Evangelist at elastic
[^] # Re: Quelle alternative ?
Posté par _kaos_ . Évalué à 2.
Salut,
Oui, tout à fait.
Je me suis probablement mal exprimé sur la chronologie. Quand j'ai tenté la sécurisation, xpack était une option payante (avec version d'essai gratuit), et searchguard (open source sur la base, et options payantes pour plus) ; la "guerre" n'était pas engagée, j'ai donc pu rapidement tester les deux, et clairement xpack était plus facile de déploiement, mais certainement avec moins de fonctionnalités.
C'est après que le rouleau compresseur s'est mis en marche. Je n'étais plus dans la même société, donc plus impacté directement, mais j'ai trouvé l'attitude pitoyable, genre : Bon bin on a mis en "libre", donc maintenant, vous, vous pouvez fermer la boutique.
J'ai pas trop suivi la suite, mais floragunn semble toujours en vie.
Matricule 23415
[^] # Re: Quelle alternative ?
Posté par dadoonet (site web personnel) . Évalué à 1.
Non. C'était clair ;)
Nous avons choisi de passer la sécurité en basic afin de pouvoir avoir des un opérateur Kubernetes. Je crois, de mémoire, qu'il fallait qu'il soit sécurisé par défaut.
C'était de toute façon dans les tuyaux de mettre ça en gratuit. Le projet ECK (Elastic Cloud for Kubernetes) a fait avancer plus rapidement notre décision.
Oui. Je le crois aussi.
Je n'étais pas dans les discussions légales mais de mémoire également, il me semble que le problème que nous avions eu à l'époque avec ce code est qu'il s'agissait d'une copie de notre code source par moment et qu'il y avait eu visiblement une décompilation de xpack pour disons "s'inspirer" de notre implémentation de sécurité. A l'époque, le code source de xpack n'était pas publique. Quand nous l'avons publié, les analogies sont devenues plus évidentes.
Je crois que depuis le code en question a été réécrit.
Developer | Evangelist at elastic
[^] # Re: Quelle alternative ?
Posté par _kaos_ . Évalué à 2.
Salut,
Tant mieux, si ça a permis de résoudre le litige légal.
Désolé d'avoir un peu mis l'accent sur le mode On tire, et on voit après :)
Matricule 23415
[^] # Re: Quelle alternative ?
Posté par dadoonet (site web personnel) . Évalué à 1.
Hello. De ce que je peux voir, cela ne change rien pour toi.
As-tu regardé ce lien ? https://www.elastic.co/pricing/faq/licensing
Developer | Evangelist at elastic
# En gros, ça ne change rien à votre activité...
Posté par dadoonet (site web personnel) . Évalué à -1.
Bonjour,
Disclaimer: je bosse pour Elastic
Un petit message pour vous inviter à lire la FAQ ici : https://www.elastic.co/pricing/faq/licensing
Comme je le dis dans le titre, dans l'immense majorité des cas, ça ne change strictement rien à votre usage, à votre business, etc…
Voici un très bon résumé en image de ce qui se passe.
Si vous avez des questions ou un doute sur votre cas, n'hésitez pas à les poster ici ou me trouver sur Twitter (dadoonet) :)
Developer | Evangelist at elastic
[^] # Re: En gros, ça ne change rien à votre activité...
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Cela change un point important : avant c'était un logiciel libre, ça ne l'est plus. Du coup on va sans doute en parler moins sur LinuxFr.org.
(le Free de l'image a toujours été pour gratuit, pas pour libre).
[^] # Re: En gros, ça ne change rien à votre activité...
Posté par dadoonet (site web personnel) . Évalué à 0.
Oui. Tout dépend de ce qu'on entend par libre en effet.
Il y a effectivement un cas (et à ma connaissance uniquement celui-là) qui fait que tu n'es pas libre de faire tout ce que tu veux avec le code source. Tu ne peux pas commercialiser un service SaaS (Elasticsearch as a Service) sans un partenariat ou une license adéquate ou alors tu t'engages également à publier le code source qui te permet aussi de faire tourner ton service.
Tout le reste est "libre" au sens que tu peux faire ton business en utilisant la partie gratuite d'Elasticsearch, sans reverser la moindre chose, ni revenus, ni code source, …
En tout cas, j'espère avoir clarifié pour nos nombreux utilisateurs actuels qu'ils peuvent continuer à utiliser les projets elastic comme ils l'ont toujours fait jusqu'à ce jour.
Enfin, en dernier lieu, je me permets d'ajouter l'adresse email à contacter (elastic_license@elastic.co) si jamais quelqu'un a le moindre doute sur ce qu'il fait et souhaite avoir un email qui valide que l'utilisation qui est faite est bien conforme.
Developer | Evangelist at elastic
[^] # Re: En gros, ça ne change rien à votre activité...
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
Est-ce que la licence AGPL ne répondait pas à cette problématique. Si "non", quelle est la différence ? Car il me semblait que AGPL répondait bien à cette problématique.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: En gros, ça ne change rien à votre activité...
Posté par Zenitram (site web personnel) . Évalué à 2.
Rien à voire avec "on entend", il y a une définition précise.
Donc pas libre.
Ca change tout, pour qui souhaite du libre à du non libre.
Ben non, c'est retiré de Debian par exemple.
Bref, il faut appeler un chat un chat : ce n'est plus libre, et ça change tout pour qui souhaite que du libre.
# Précisions par Elastic
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
https://www.elastic.co/fr/blog/license-change-clarification (rien qui n'ait été dit sur le changement lui-même, mais les perspectives pour le futur sont explicitées)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.