IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Redict, un fork open source indépendant et non commercial de Redis, suite au passage de Redis à un modèle de licence non libre
Vu comme une "trahison de la communauté du logiciel libre"

Le , par Anthony

67PARTAGES

12  0 
Le passage de Redis® à un modèle de licence non libre a causé plusieurs déceptions. Il s'agit d'une trahison de la communauté du logiciel libre, mais qui n'est peut-être pas tout à fait surprenante. Les forks vont probablement commencer à apparaître dans les jours à venir, et aujourd'hui, Redict se présente comme une future solution possible pour vos besoins. Voici les avantages de Redict par rapport aux autres forks parmi lesquelles vous aurez probablement à choisir très prochainement.

En quelques mots, Redict est une version indépendante et non commerciale de Redis® OSS 7.2.4. Il est basé sur le code source BSD 3-Clause de Redis® OSS, et toutes les modifications à partir de ce point sont placées sous la Lesser GNU General Public license, LGPL-3.0-only.


Pourquoi LGPL ?

Le choix de LGPL comme licence pour Redict est un choix délibéré qui tient compte d'un certain nombre de préoccupations. Plus important encore, il s'agit d'une promesse irrévocable que Redict sera toujours libre, bien plus forte que la promesse faite par le cofondateur de RedisLabs et ex-CEO Yiftach en 2018. En utilisant une licence copyleft, toutes les modifications apportées à Redict doivent être distribuées en utilisant la même licence de logiciel libre LGPL, garantissant que les versions modifiées du logiciel seront libres.

En outre, aucune sorte d'accord de licence de contributeur ne sera utilisée pour donner à une entité des privilèges spéciaux en ce qui concerne les droits d'auteur et les licences de Redict d'une manière similaire à celle employée par Redis®. Par conséquent, le copyright de Redict est détenu en commun par tous les contributeurs, qui devraient tous accepter un futur changement de licence, ce qui rend pratiquement impossible un changement de licence similaire dans l'avenir de Redict. La provenance des contributions est vérifiée par le certificat d'origine du développeur.

Il existe de nombreuses licences copyleft et la LGPL a été choisie comme la plus adaptée à Redict. L'Affero GNU General Public License (AGPL) est un choix courant pour les projets de cette nature, en particulier ceux gérés par des intendants qui, comme Redis® Ltd, préféreraient que les fournisseurs de cloud ne vendent pas leur logiciel. L'AGPL est une excellente licence, mais l'objectif est de permettre aux utilisateurs de se conformer le plus facilement possible à la licence Redict et il n'y a pas de raison de décourager les fournisseurs de cloud de faire usage de Redict. La licence EUPL a été envisagée, mais n'a pas été retenue pour les mêmes raisons.

La LGPL a été préférée à la GNU General Public License pour éviter que les intégrations avec des modules compatibles Redis® ou des plugins Lua ne soient soumises à la "viralité" de la GNU GPL.

Le choix de la LGPL protège l'avenir du projet Redict tout en équilibrant au mieux chacune de ces préoccupations.

Changements par rapport à Redis®

Actuellement, les changements par rapport à Redis® 7.2.4 sont limités. La principale préoccupation est de changer le nom de manière rétrocompatible et d'établir une base technique pour un avenir indépendant. Les changements mis en œuvre jusqu'à présent pour les utilisateurs sont les suivants :

  • Les exécutables ont été renommés en redict-*, par exemple redict-cli.
  • L'API Lua fournit un global "redict" compatible avec l'API Redis® OSS, disponible via le global "redis" pour une compatibilité ascendante.
  • Les symboles de l'API du module ont été renommés, mais Redict conserve la compatibilité ABI avec les modules Redis® OSS jusqu'à la version 7.2.4.

Des travaux sont en cours pour achever le processus de renommage, et un guide de migration sera disponible lorsque la première version, 7.3.0, sera publiée, ce qui devrait idéalement être le cas la semaine prochaine. Redict fonctionnera comme un remplacement direct de Redis® OSS 7.2.4, bien que vous puissiez prendre des mesures pour mettre à jour votre configuration locale pour Redict si cela vous convient (comme la migration de votre base de données vers /var/lib/redict).

Le référentiel a également été mis à jour pour être conforme à la spécification REUSE, pour faciliter le processus de conformité de la licence et pour clarifier les différentes licences logicielles qui s'appliquent à Redict, y compris la licence BSD 3-Clause du code OSS original de Redis® et les nouveaux changements LGPL, mais aussi les dépendances vendored telles que Lua.

Changements futurs

L'intention de Redict est de poursuivre le développement d'une distribution de logiciel libre compatible avec Redis® OSS, avec un minimum de changements perturbateurs pour le moment. Des discussions sont en cours sur les changements suivants :

  • Profiter de l'occasion pour supprimer certaines fonctionnalités obsolètes depuis longtemps, telles que "redis-trib"
  • Éliminer les dépendances vendored et passer à Lua en amont, jemalloc
  • Devenir plus agnostique en aval, en supprimant par exemple les services systemd ou upstart.

Hiredis sera également forké, car il s'agit d'une dépendance interne de Redict.

Aucun effort ne sera fait pour rester compatible avec les futures versions de Redis® SAL.

Changements d'infrastructure

Cette opportunité est utilisée pour établir une communauté indépendante des infrastructures propriétaires, telles que GitHub et Slack. Le code source est hébergé sur Codeberg, une instance Forgejo gérée par une association allemande à but non lucratif, qui devrait fournir une expérience utilisateur confortable et familière pour toute personne à l'aise avec la communauté Redis® OSS basée sur GitHub. De plus, un canal IRC #redict a été créé sur libera.chat, où la communauté naissante est en train de s'organiser.

Relations avec d'autres forks

Avant le changement de licence de Redis®, un certain nombre de forks étaient déjà établies, comme KeyDB. Cependant, ces forks ont plus d'opinions que Redict n'en a l'ambition : Redict fournira une continuation plus conservatrice de la base de code OSS Redis®.

Dans les semaines à venir, il est probable que d'autres forks de Redis® OSS apparaissent. Il est possible que des changements soient apportés à partir de forks sous licence permissive, ou utilisant une licence copyleft compatible avec la LGPL.

Besoin de votre aide

Rejoignez le projet et apportez votre aide ! Les contributeurs établis de Redis® OSS n'ont qu'à se faire connaître et ils se verront accorder un accès push au dépôt amont. Si vous avez des pull requests en cours contre Redis® OSS, prenez le temps de les rebaser contre Redict. Les nouveaux contributeurs sont également encouragés à participer au développement.

Vous pouvez également contribuer à l'élaboration de la documentation de Redict, car la documentation de Redis® n'utilise pas de licence libre et ne peut donc pas être adaptée à Redict. La participation des distributions Linux cherchant à remplacer leur paquetage "redis" par un logiciel libre constitue également un atout. N'hésitez pas à venir à faire part de vos besoins, de vos inquiétudes et de vos commentaires.

Rejoignez la communauté sur IRC pour commencer : #redict sur libera.chat. Une infrastructure communautaire supplémentaire sera mise en place dans un avenir proche, notamment une liste de diffusion sur la sécurité et un code de conduite mis à jour.

Source : "Redict is an independent, copyleft fork of Redis®" (Redict)

Et vous ?

Que pensez-vous de Redict et de ses potentialités ?

Voir aussi :

Redis, célèbre base de données en mémoire, n'est plus un logiciel libre car il abandonne la licence BSD à trois clauses. Des distributeurs comme Fedora envisagent déjà de le supprimer en conséquence

L'étude 2024 de Red Gate sur l'état de l'art en matière de SGBD montre l'avance de Microsoft SQL Server, pour un usage professionnel d'entreprise quel est votre classement ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de ced
Rédacteur/Modérateur https://www.developpez.com
Le 25/03/2024 à 14:04
Citation Envoyé par SQLpro Voir le message
L'éditeur propose une version bridée et la version performante est payante (PostGreSQL)
Faux ! PostgreSQL n'appartient à aucun éditeur, mais au PostgreSQL Global Development Group, justement affranchi de tout éditeur.
C'est justement ce qui fait que ce qu'on voit avec Redis, MongoDB ou MySQL il y a quelques années, ne peut pas se produire (et c'est volontaire) avec PostgreSQL.

ced
10  0 
Avatar de calvaire
Expert éminent https://www.developpez.com
Le 30/03/2024 à 18:22
Il est intéressant dans un projet informatique dans son entreprise de voir toute les dépendances qu'ils utilisent, on incluant celle de l'os si c'est linux.
Beaucoup pour pas dire la totalité sont gratuite. La majorité maintenue bénévolement par juste 2-3 gugusses en best effort.
Rien que Firefox s'appuie sur 1 tonne de dépendance "critique", les codec videos par exemple.

100% des grosses boites française que j'ai faite n'ont jamais rien donné aux créateurs de ces dépendances.
Ce serait drôle si un jours il fallait payer chacune de ces dépendances

On peut difficilement en vouloir à une boite de trouver des solutions pour gagner de l'argent et monter un business.
Si demain Firefox n'arrive pas à gagner assez d'argent ils vont devoir trouver un autre modèle économique (vente de donnée, pub...).

Linux ou Wikipedia sont des exceptions dans le monde du libre, ce sont des projets critiques que les grosses entreprises et institutions finances beaucoup d'argent.
Mais sous le capot, si je prends la lib numpy ou pandas en python par exemple, sur Wikipédia j'ai l'impression que c'est des projets maintenues par juste 2-3 gugusses gratos (je peux me tromper mais ca n'a pas l'air d'etre soutenue par de grosses structures). Lib pourtant très critique et tres connue, si je parle maintenant des sous libs inconnue alors la....

c'est un miracle que ce château de carte tiens pas trop mal en 2024 et les grosses boites du cac40 et gafam sont très contente d'en profiter gratuitement, c'est un gain de productivité énorme !

Si demain une boite devait payer son os, son langage avec son compilateur, chaque lib, chaque sgbd... ca changerait totalement le modèle économique de l'informatique. Je pense qu'on s'enfermerais dans un écosysteme de gafam. Un windows avec visual studio avec c# et sql server par exemple coté Microsoft.
3  0 
Avatar de RenarddeFeu
Membre averti https://www.developpez.com
Le 17/09/2024 à 4:40
La particularité des logiciels cités dans l'article, et des SGBD en particulier, c'est qu'ils ont besoin d'une base d'utilisateurs conséquente pour pouvoir exister.

Sauf qu'il est bien difficile de rivaliser face à un Oracle ou un SQL Server, qui ont déjà largement pénétré le marché, qui ont leur réseau de lobbyistes, et dont certaines pratiques sont ethniquement discutables. Par exemple : ces entreprises exploitent très largement le biais du coût irrécupérable. Leurs clients ont tellement investi d'argent dans leur solution à coup de licences, de formations, de prestations externes, dans compter les coût d'infra, qu'elles ont peur de tout perdre si elles passent à une alternative moins onéreuse.

La solution est donc de proposer le logiciel gratuitement avec l'open-source comme paravent dans un premier temps afin de gagner en popularité. Puis de passer à un modèle commercial plus classique une fois le logiciel largement répandu.
3  0 
Avatar de PhilNelwyn
Futur Membre du Club https://www.developpez.com
Le 26/03/2024 à 11:57
Citation Envoyé par TheGuit Voir le message
Du coup pour résoudre une incertitude sur la licence on préfère une incertitude sur la maintenance et le suivi.
C'est un trade-off que je ne ferais pas personnellement sur mes projets.
Ça c'est un autre débat.
Tu demandais quel était l'intérêt, c'est celui-là.
1  0 
Avatar de esperanto
Membre émérite https://www.developpez.com
Le 28/03/2024 à 9:27
Citation Envoyé par Michel.Priori Voir le message
[*]En quoi l'utilisation en cloud serait moins tolérable qu'ailleurs ...
L'auteur initial d'un logiciel a le privilège de décider ce que ses utilisateurs ont le droit de faire avec ou pas. Il peut donc autoriser l'usage en cloud ou pas. Et il n'a pas à justifier ce choix.
Pour indiquer son choix, l'auteur glisse dans son logiciel un document appelé licence. Il peut la rédiger lui-même mais il est plus simple de choisir une des grandes licences du logiciel libre: non seulement il a moins à rédiger (juste une phrase indiquant le nom de la licence) mais pour l'utilisateur aussi c'est plus simple, beaucoup d'autres logiciels utilisent la même et si il ne comprend pas certains termes, de nombreux utilisateurs ont pu écrire des résumés sans valeur officielle mais plus faciles à lire.

En ce qui concerne le cloud, les licences de logiciel libre l'autorisent sans problème. Par contre si tu diffuses une version modifiée d'un logiciel libre, là tu dois bien regarder ce que dit la licence car c'est typiquement pour ce genre de cas qu'il y a des différences entre BSD, GPL et AGPL. Typiquement une licence de type GPL ou AGPL va t'obliger à diffuser gratuitement tes modifications en téléchargement, avec les sources. ça ne t'interdit pas de faire de l'argent avec tes propres services, mais tu ne pourras pas empêcher quelqu'un de faire la même chose avec tes sources (mais sur son propre cloud et sous un autre nom, le nom original ne pouvant être que cité en référence)

Citation Envoyé par Michel.Priori Voir le message
[*]Si l'argument est de dire que les nouvelles moutures seront largement plus évoluées que le produit actuel, pourquoi ne pas en faire un produit séparé ? -REDIS entreprise- par exemple
En fait l'outil était sous une licence BSD qui autorisait n'importe qui à créer un produit commercial ... mais pas à s'approprier le nom.
Ici une société a réussi à s'approprier le nom en poussant l'auteur original à céder sa marque avec des promesses qu'elle n'a ensuite pas tenues.

Aujourd'hui n'importe qui peut créer un produit sur base des anciennes versions ... mais en changeant le nom.
Techniquement ça ne change pas grand chose, mais dans le monde dans lequel nous vivons, ça pose un problème parce que beaucoup feront la confusion avec le nom original désormais associé à un produit techniquement similaire mais légalement très différent par sa nouvelle licence.

A contrario, pour rester dans le monde des SGBD:
  • MySQL était dès le départ la propriété d'une société commerciale qui a connu des rachats successifs. Le résultat est certes comparable à celui de Redis (la version libre s'appelle désormais MariaDB) mais il n'y a pas eu de vol parce qu'on le savait depuis le début;
  • EntrepriseDB commercialise une version payante de PostgreSQL... mais ne s'attribue ni le nom, ni la paternité du logiciel original (juste de ses propres modifications) et encore moins l'exclusivité (même si je ne connais pas d'autres forks commerciaux de PostgreSQL). Il n'y a guère que xxxPro pour entretenir la confusion.


Citation Envoyé par Michel.Priori Voir le message
... à quand linux payant dans le cloud ??
Il existe des distributions payantes de Linux, cloud ou pas cloud. Mais
  • Ce sont des distributions (contenant linux + autre chose), pas des variantes
  • Le nom Linux appartient à une fondation, il sera plus difficile de faire le même tour de passe-passe qu'avec Redis. Les distributions se disent basées sur Linux, elles ne s'approprient pas le nom et surtout pas en exclusivité.
  • Linux utilise une licence GPL, qui contrairement à la BSD n'est pas modifiable (il faudrait l'accord de tous les développeurs pour faire un tel changement et il y en a plein).
1  0 
Avatar de calvaire
Expert éminent https://www.developpez.com
Le 02/04/2024 à 12:01
bien tien, un article aujourd'hui qui dit exactement ca

Vous avez bien lu, la sécurité du web mondial, le truc qui permet de piloter des ordinateurs à distance de manière fiable, tient en partie au travail d’un unique et obscur bénévole sur son temps libre.
1  0 
Avatar de ilyos
Candidat au Club https://www.developpez.com
Le 01/05/2024 à 12:57
Que pensez-vous de l'analyse de Jeff Geerling ?
Je suis tout à fait d'accord avec lui.
Partagez-vous son point de vue ?
Oui.
Dans quelle mesure ?
100%
Quelle est votre opinion sur la décision de HashiCorp de passer à la licence « Business Source License » ?
Une manipulation de la communauté open source.
Pensez-vous que cela a nui à la confiance de la communauté des développeurs ?
Oui.
Comment percevez-vous les forks d’outils Open Source tels qu’OpenTofu et OpenBao ?
La réponse adéquate.
Sont-ils une solution viable pour les entreprises et les utilisateurs qui se sentent trahis par les changements de licence ?
Oui, tant qu'ils ne sont pas maintenus majoritairement ou exclusivement par IBM & Co..
Quelles sont les implications à long terme de la « fin de l’illusion de l’Open Source d’entreprise » ?
Une grande orientation de la communauté vers les projets "libres".
Comment cela pourrait-il affecter la façon dont les entreprises développent et distribuent leurs logiciels à l’avenir ?
Elles devront engager plus de développeurs compétents et se trouver de nouveaux marchés à la Microsoft.
Pensez-vous que les entreprises devraient privilégier les licences Open Source ou les licences propriétaires ?
Tout dépend de la philosophie de l'entreprise, de son secteur d'activité et de sa cible commerciale.
Quels sont les avantages et les inconvénients de chaque approche ?
Désolé, mais il faudrait rédiger un article entier sur ce sujet.
1  0 
Avatar de TheGuit
Membre régulier https://www.developpez.com
Le 25/03/2024 à 14:42
KeyDB étant déjà un Fork de Redis, je ne vois pas bien l’intérêt d'en créer encore un autre ? Surtout quand la majeur partie des gens font des choses extrêmement basique avec Redis et que donc KeyDB les fait très bien lui aussi.
0  0 
Avatar de PhilNelwyn
Futur Membre du Club https://www.developpez.com
Le 26/03/2024 à 9:25
Citation Envoyé par TheGuit Voir le message
KeyDB étant déjà un Fork de Redis, je ne vois pas bien l’intérêt d'en créer encore un autre ? Surtout quand la majeur partie des gens font des choses extrêmement basique avec Redis et que donc KeyDB les fait très bien lui aussi.
Sous quelle licence KeyDB est-il distribué?
0  0 
Avatar de nirgal76
Membre chevronné https://www.developpez.com
Le 26/03/2024 à 9:53
Citation Envoyé par PhilNelwyn Voir le message
Sous quelle licence KeyDB est-il distribué?
BSD-3 license me semble t-il
0  0