this post was submitted on 19 Apr 2025
1399 points (99.3% liked)
Technology
69658 readers
2736 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
Of course you have to pay for a commercial license, it's in the name. Development, tooling, support, etc, all costs money.
I like the distinction. If you want to profit from open source, make your code open source. If not, pay up.
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.
I feel like it qualifies under
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.
That wording is pointing to reselling the program or the same functionality. Of course if your service is "fast key based data retrieval" it would violate the definition, but something like "low latency gaming notifications" would not, because the value is gaming notifications, something redis doesn't offer. Same as if your service uses encryption in transit, you're not just reselling openssl.
I know prohibiting reselling is what they probably intended. But that doesn't mean they can't push a different and very valid interpretation when they want to.
The wording—"primarily derives from"—is much broader than "just". I believe that Resque's dependence on Redis is enough to satisfy "primarily".
Well, I don't believe so, but as you said it's ultimately for a court to test it.