Continued thread
Administered by:
#redict
0 posts0 participants0 posts today
Done: Migration from 
In Progress: Migration from MariaDB to Galera ClusterContinued thread
We were still struggling with email delivery from Forgejo. It looks like some queues are corrupted and restoring them is very hard. Most queued messages are spam or registration emails with already expired tokens. Finally, we made the decision to reset the queue and will do that in a few minutes.
We are using the opportunity to switch the queues to #redict / #redis, which was a planned project anyway (a requirement for clustering our Forgejo to multiple instances).
My OSS Hitlist 2025:
1. #paperless_ngx
2. #Proxmox
3. #Syncthing
4. #Debian
5. #Ansible
6. #SpringBoot Framework
7. #HTMX
8. #MariaDB
9. #Mkdocs
10. #Python
11. #Minio
12. #PostgreSQL
13. #Bulma
14. #KeePass
15. #VScode
16. #redict
These things enable me to be productive. Many thanks!
"Last Thursday... Redis announced that it had changed the license covering its software from the open-source 3-Clause BSD License to the Redis Source Available License and the Server Side Public License, both source-available proprietary licenses..."
#ChristineHall, 2024
Testing #Platypush with #Valkey and #Redict, now that #Redis has decided to apply a weirdly restrictive license like SSPL.
At a first impression, it looks like Valkey is more ambitious and willing to implement many new features and optimize Redis' data model, while Redict seems to stick to "let's do what Redis already does best and become great at it, without time-series, open telemetry and a lot of new whistles and bells".
I also wish that these projects will soon make it upstream in the major package managers. As of now most of the package managers still provide Redis, which isn't full FOSS anymore, and none of its recent forks.
If you are working on a project that relies on Redis, what options are you currently considering after Redis' SSPL migration?
At a first impression, it looks like Valkey is more ambitious and willing to implement many new features and optimize Redis' data model, while Redict seems to stick to "let's do what Redis already does best and become great at it, without time-series, open telemetry and a lot of new whistles and bells".
I also wish that these projects will soon make it upstream in the major package managers. As of now most of the package managers still provide Redis, which isn't full FOSS anymore, and none of its recent forks.
If you are working on a project that relies on Redis, what options are you currently considering after Redis' SSPL migration?
@drewdevault https://translate.codeberg.org/ is now running on #redict. 
(Switch was easy enough, no problems encountered: https://codeberg.org/Codeberg-Infrastructure/weblate-docker-compose/commit/7eefb48fed481ea10f5b1fe285ae737206e25dcc)
Codeberg TranslateCodeberg TranslateThis site runs Weblate for localizing various software projects.
Forking is easy, ideas are cheap — but this blog post/announcement by #Redis successor (more correctly: one of multiple free software Redis successors) #Redict sounds really reasonable: https://redict.io/posts/2024-04-03-redict-7.3.0-released/
Focus on stability over new features (the production projects we use(d) Redis in required mostly 2015-era features; I bet that’s true for many users) to distinguish itself from and peacefully coexist and complement with other forks like #Valkey 
I'm not really sure it's a good thing the #LinuxFoundation has now also forked #Redis: Their fork #Valkey is announced to be backed by major large companies like AWS, Google, Ericsson, Oracle (duh!), but of course keeps using a BSD license.
https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community
This might make it a lot harder for the #Redict, that changed to LGPL, to keep traction. But copyleft licenses are a necessary against projects going proprietary again just like Redis did.
www.linuxfoundation.orgLinux Foundation Launches Open Source Valkey CommunityCommunity maintainers, contributors, and users will continue collaborative development of an open source, in-memory data store under the new Valkey name.
Replied in thread
@FritzAdalis @Codeberg @pkw
"LGPL was chosen over the GNU General Public License to reduce concerns that integrations with Redis® compatible Modules or Lua plugins would be subject to the “virality” of the GNU GPL."
#LGPL can be itself subject to the 'virality' of GNU GPL if I'm not mistaken.
One can take a LGPL project and change the license to GPL.
cc @drewdevault
Another day, another #redis alternative packaged for @fedora and EPEL.
This time we have #redict led by @drewdevault
https://bodhi.fedoraproject.org/updates/?search=redict-7.3.0~rc1
bodhi.fedoraproject.org
Fedora Updates System
management of Fedora Project updates
I really like @andrewrk's take on the Redis BS. In short: "Redis Renamed to Redict."
andrewkelley.meRedis Renamed to Redict - Andrew Kelley
#Redict is an independent, copyleft fork of #Redis
https://redict.io/posts/2024-03-22-redict-is-an-independent-fork/
redict.io · Redict is an independent, copyleft fork of Redis®Like many of you, I was disappointed when I learned that Redis®1 was changing to a non-free licensing model. This is a betrayal of the free software community, but perhaps not an entirely surprising one. Forks are likely to start appearing in the coming days, and today, I would like to offer Redict to you as a possible future home for your needs, and present its trade-offs as compared to the other forks you’re likely to be choosing from soon.
Shouldn’t you mention that if anybody distributes a product based on the UNMODIFIED #Redict they can satisfy all requirements just by pointing to https://codeberg.org/redict/redict to make it clear they don’t have to be burdened too much?
Codeberg.orgredictA distributed key/value database
3 serious forks of #Redis to watch:
Mutli-threaded fork of Redis based on Redis 6.
BSD 3 Clause license.
Owned by Snapchat.
https://github.com/Snapchat/KeyDB
Recent fork by @drewdevault based on the last open source version of Redis 7.2.4.
On Codeberg.
LGPL 3.0 license.
https://codeberg.org/redict/redict
Accepted by Linux Foundation. Started by former Redis contributors & AWS employees.
BSD 3 Clause license.
https://valkey.io/
Boosts appreciated 
andrewkelley.meRedis Renamed to Redict - Andrew Kelley
We are proud to be home to #Redict, the #fork of the formerly free (but no longer) Redis project. We are using #Redis on our own infrastructure for caching, and we are looking forward to migrate to the new version, then fetched from Codeberg. A small world … 
Missed the story? Get up to date here: https://redict.io/posts/2024-03-22-redict-is-an-independent-fork/
Directly check out the code? Check the #Codeberg repo: https://codeberg.org/redict/redict
redict.io · Redict is an independent, copyleft fork of Redis®Like many of you, I was disappointed when I learned that Redis®1 was changing to a non-free licensing model. This is a betrayal of the free software community, but perhaps not an entirely surprising one. Forks are likely to start appearing in the coming days, and today, I would like to offer Redict to you as a possible future home for your needs, and present its trade-offs as compared to the other forks you’re likely to be choosing from soon.
Can a fork (i.e. not original copyright holder) relicense from from BSD-3-Clause to LGPL-3.0?
Barrister Google seems to think you are very limited in what sort of relicensing you can do (i.e. you can only adopt *more* restrictive licenses, otherwise why not fork everything and change the license to public domain?)
Codeberg.orgredictA distributed key/value database
Continued thread
Do you need the v7 #redis features or #KeyDB won't work for you for some other reason? Check out #redict, an up and coming #opensource v7 fork of redis.
Codeberg.orgredictA distributed key/value database