It's your choice between SSLPv1 or RSALv2.
If your product is open source, then you choose SSLPv1 and you're safe.
If your product is closed/commercial, then you choose RSALv2.
You probably want to look at RSALv2 [0] instead of SSLPv1. It's very short, plain and simple.
With RSALv2 you're safe as long as your product is not a wrapper/database aimed at developers that just exposes redis internals. If it does that then you need to enter agreement with Redis Labs to share your profit margin with them.
Ie. if documentation for your offering redirects users to redis docs for usage of your product – you can't use RSALv2 because you're directly competing with Redis Labs with your offering.
This means cloud providers are directly impacted, not usual businesses that USE, not OFFER redis.
And frankly, that's the way it should be. This is the way to do sustainable, source available, open source compatible (through SSLPv1) business model.
If I choose a dependency that's SSLPv1 licensed, my product is no longer open source.
> If your product is closed/commercial, then you choose RSALv2.
From the limitations section of the RSALv2:
> You may not make the functionality of the Software or a Modified version available to third parties as a service or distribute the Software or a Modified version in a manner that makes the functionality of the Software available to third parties.
What does this even mean? The functionality of Redis is to store data and then make it available on request (typically over a network), therefore this clause means I'm not allowed to use it in any system which exposes the capability of storing data for end users and making it available on request. For example, a product that allows a user to set some preferences.
If it doesn't mean that, why isn't the licence more specific?
> With RSALv2 you're safe as long as your product is not a wrapper/database aimed at developers that just exposes redis internals.
It's delightful that you infer this. However, this is not what the licence says.
From user's perspective it's open source. From provider's perspective it's not. OSI doesn't distinguish between those two, there is only user, which can be ordinary end user or provider. Because for provider it's not open source, it can't be approved OSI license.
For RSALv2 "Software" and "Modified" is not "software" and "modified". It's capitalized because it refers to terms that are provided in "Definitions" section. From there you have:
Modify, Modified, or Modification: copy from or adapt all or part of the work in a fashion requiring copyright permission other than making an exact copy. The resulting work is called a Modified version of the earlier work.
Redis: the Redis software as described in redis.io.
Software: certain Software components designed to work with Redis and provided to You under this Agreement.
It's also plain and simple to see why those things are created in the first place. It's because open source has problem with cloud where big players not involved with the project cash out on it by simply selling it as is (as managed service) and by doing it they also automatically strip original authors from any chances of competing.
This effort is targeted solely on cloud providers so original authors of the project get a chance at having viable, sustainable business model.
It's not targeted at users. It's targeted at providers.
SSLPv1 was added into dual licensing to allow open solutions to allow to exist – ie. projects that extend redis but don't monetize on it.
ps. OSI doesn't have (or will ever have?) licenses that are compatible with this new era of cloud providers because it equates end user with cloud provider. This is wrong and people will have to invent new adjectives/nouns to describe what they mean by open source contribution + not allowed to leech on us (compete with us through cloud offering without giving us a cut).
[0] https://opensource.org/blog/the-sspl-is-not-an-open-source-l...