Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I look at the SSPL and don't see plain license terms. I see vague restrictions almost designed to provide opportunity for exciting future litigation.


It's dual licensed.

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.

[0] https://redis.com/legal/rsalv2-agreement


> If your product is open source, then you choose SSLPv1 and you're safe.

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.


I stand corrected for this sentence saying that SSLPv1 is open source license, it's not OSI approved [0], even if people using it claim it's open source (it was created by MondoDB IIRC and adopted by others).

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.
Plain and simple.

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...


> 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:

Notice how they deliberately don't define "service" or at any point specify "the functionality of the Software".

> 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 is, quite obviously, highly subjective. I (and many others) don't think there's a problem, VC-backed companies think there's a problem. Go ask (for example) the Linux, Postgres, Memcached or any of the CNCF folk about whether there's a problem.

> It's not targeted at users. It's targeted at providers.

Providers are also users.

> 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).

It's also pretty insulting to the thousands (millions?) of open source projects that choose to adopt an OSI-approved open source licence to suggest that they somehow don't understand what they're doing or are "doing it wrong".

If you're worried about not getting a cut when cloud providers use your software to make money.... don't release it under an open source licence. This isn't hard?


> If you're worried about not getting a cut when cloud providers use your software to make money.... don't release it under an open source licence. This isn't hard?

End use != provide.

Open code, open contributions, open non-commercial applications matter.

It's a simple 2 dimensional space on:

Usage(Use, Provide)

Setting(Commercial, Non Profit)

With single false cell on Provide & Commercial.

Copyright holders should be allowed to choose this option. I don't see why the whole fuss about why not.

If you don't want to use it on your copyrighted work, don't.

It doesn't mean others are not allowed, does it?


You seem extraordinarily sure that the definition of "provider" or "provides a service" (or even "end user") is universally and objectively understood by all, and yet you can't point me to the place where Redis (or anyone else) spells this out. Curious.

> Copyright holders should be allowed to choose this option. I don't see why the whole fuss about why not.

I agree. As long as they define their terms. Redis haven't. That's the point.


It's clearly stated in Definitions section (for Modify, Modified, or Modification).

It draws clear distinction between merely USING the software in its original form and ADAPTATION or DERIVATION that requires copyright permission.

It plainly, simply and directly implies that using it is fine and distributing modifications is not. It also says that unmodified version is fine to distribute commercially ("... other than making an exact copy").




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: