Redis is also on the list, but not Valkey. Gitea is on the list, but not Forgejo. Still nice to see governments endorsing the open-source-ish software they know and FOSS principles, though!
I imagine the list will be dynamic. Those projects might be on a list somewhere, just haven't been vetted yet by their standards. Start with the source projects, then dive through the forks.
To be fair, I know redis and gitea (barely, gitlab is way more popular) and not the other two. Enterprise support and name recognition are quite important for government usage.
Valkey was created recently as Redis changed their license, having clauses which made the user choose between being “discriminatory against users of the software that use proprietary software within their stack, as the license requires the open-sourcing of every part interacting with the service, which under these circumstances might not be possible” or being non-commercial.
Forgejo was created when Gitea decided to go the JetBrains route a few years ago. It’s since absorbed Gitea’s clout.
The simple answer: nobody is actually reading any of these licenses. I run into the problem constantly and even people who should know better do not (most of our IT staff for example...)
Yeah, and you have to pay for that. Lots of open source software have enterprise support and usage limit licenses but having to pay for something isn't open source. I am personally ambivalent at non-commercial licenses but I agree that the restriction against using proprietary software with Redis in commercial usage is kinda bad.
Sorry, I didn't see the notification for some reason. The SSPL would prohibit people from running Redis from Windows, as Windows is proprietary. That forces them to use the source-available RSAL.
I don't think that's correct. It maybe prohibits people from building a service to offer redis to third parties on Windows, but you can run redis in your stack on whatever OS you want, as long as what you are building is not "redis as a service". So any end-user SaaS that just uses redis as a cache is not bound to section 13.
And even if you built a redis as a service, the operating system is not explicitly mentioned in the license, so it would be for a lawyer to say whether that's required...
Well, it's how I would interpret it, especially for Windows being a violation of section 13 (a little less for whether section 13 applies when you just use Redis: one could argue it applies to dynamic sites that really require fast responses as part of its feature set, which has to use something like Redis). It's also an issue that nobody has interpreted the license in court yet.
Agree on the court, but the wording is super specific. Doesn't matter if you couldn't build it without a redis-like component, because of the speed or whatever, it is targeting "offering the program as a service". There's even an FAQ on the mongodb (SSPL authors) site regarding this. Unless your program is just a proxy to access redis, you're fine.
offering a service the value of which entirely or primarily derives from the value of the Program or modified version
Doing it fast is essential and a core part of many services' value, I'm sure.
You have a point regarding the FAQ but I do not see that written in the license. This is a problem that would only be granted in case MongoDB/ElasticSearch/Redis sues someone for internal use and I think that's a borderline risk too much to take.