5 ms·

The good thing about this is that since the companies are copyright holder of the code, if this creates issues, the licenses can be rewritten and modified in or

The good thing about this is that since the companies are copyright holder of the code, if this creates issues, the licenses can be rewritten and modified in order to be as sharp as possible in the use cases they want to avoid (which is... two/three users in the world :D).

jcgrillo 2y ago
This is a great point, it'll probably take the better part of the next decade for all this to shake out. It'll be interesting to see where it goes.
zokier 2y ago
the issues of sspl have been frequently and loudly been brought up previously, and nothing has happened. just to reiterate, this section is ridiculously expansive: > “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available. it is practically impossible for anyone to comply with that, to provide source code for every single program (without limitation) that they happen to use anywhere. of course none of the major sspl-using vendors are even pretending to themselves to follow these rules. sspl would be much better license if it just simply forbids providing services, instead of hiding behind this thin veneer of fake copyleft. > You can even still sell Redis as a service if you want, as long as you release all the orchestration systems under the same license (something that nobody would likely do, but this shows the copyleft approach of the license). note that this is not right, the "copyleft" is not limited to orchestration systems, it covers all programs that you use
- ndiddy 2y ago
  I believe that the original reason why they didn't just say "you're not allowed to provide this program as a service" is that MongoDB were trying to get SSPL approved by the OSI. The OSI didn't approve it because as you mention, it's basically impossible for a cloud provider to actually attempt to comply with the SSPL. Not only would they have to release the code to all software used to make the program available, they would have to do so under the SSPL. I'm not sure why MongoDB didn't change the wording when they gave up on getting the license classified as "open source".
- ryukafalz 2y ago
  > it is practically impossible for anyone to comply with that, to provide source code for every single program (without limitation) that they happen to use anywhere. It is practically impossible to comply, yes, but not just because you'd need to provide the source code to all the software you're using. The thing that really makes it impossible to comply with is that you must release all of that software under the SSPL. This could be reasonably interpreted to preclude the use of FOSS software, like Linux, that you do not have the authority to relicense under the SSPL. I wrote a blog post[0] about this a while back, but I think this is fixable if you allow the other software in the stack to be released under another FOSS license (and you could still require its disclosure). [0] https://www.terracrypt.net/posts/the-sspl-is-not-a-reasonable-copyleft-license-but-it-maybe-could-be.html https://www.terracrypt.net/posts/the-sspl-is-not-a-reasonabl...
- vvillena 2y ago
  Redis puts Redis into the open, and companies exposing Redis put everything they use to expose Redis into the open too. The key enabler in that whole business is still Redis, so the knowledge exchange appears fair.
jchw 2y ago
I'm sorry, but how is this a good answer? If you really only care about "two/three users in the world" and don't want users to worry about legal implications, why not explicitly write that in the license? It doesn't matter how good your intentions are, in the long run, it's not you or Redis, inc. we have to trust, it's anyone who potentially inherits the rights of these licensed IPs, at which point the courts will not rule on what your feelings are of what the license was meant to do but instead what was actually written and agreed to. That's why an existing, well-understood and symmetrical copyright license is going to beat out weirdo "business" licenses any day, and why they will never be considered OSI-compliant, which is fine, because if we all really hated big tech they're already allergic to the AGPL anyway. I know I'm not going to score any points by disagreeing with you here of all places, but I genuinely wonder if you really do believe this or if you mostly just don't care to actually confront the reality. This whole thing could be a nothingburger forever, or, alternatively, Redis, Inc. could some day be acquired by Oracle. Absolutely no way for any of us to know for sure. Unfortunately, that leaves me with little other option but to stick to the forks.
- jcgrillo 2y ago
  > Redis, Inc. could some day be acquired by Oracle This is truly the nightmare scenario, and it'll be interesting to see how it plays out when such a thing happens. Not saying specifically with these two companies, but so far these licenses aren't particularly tested, and it seems we just can't really know what will actually happen without running the experiment.
  - stephenr 2y ago
    TBH oracle have been better stewards of MySQL since they bought Sun than Redis the company has been of Redis for the last five or so years.
    - jchw 2y ago
      I personally have wondered if Oracle's behavior with MySQL is partly motivated by the fact that if they try to rug-pull it will most likely just push all of the cloud providers over to MariaDB anyways, which has been doing just fine, and I think is already supported by Amazon RDS anyways. Ultimately I am totally fine with a fork-heavy ecosystem, the only thing I would erase if I could is the normalization of signing CLAs, as I think they make the normally-symmetrical prospect of contributing to open source projects highly asymmetrical, and the consequences are not always so obvious to people.
coldtea 2y ago
For the companies who "are copyright holders of the code" the uncertainty and litigation potential is not a bug, it's a feature.
- collingreen 2y ago
  This feature could actually be the overwhelming value of acquiring the copyright. When trillion dollar companies go to war with each other this kind of thing is a fantastic weapon in the arsenal.

jcgrillo 2y ago

This is a great point, it'll probably take the better part of the next decade for all this to shake out. It'll be interesting to see where it goes.

zokier 2y ago

the issues of sspl have been frequently and loudly been brought up previously, and nothing has happened. just to reiterate, this section is ridiculously expansive: > “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available. it is practically impossible for anyone to comply with that, to provide source code for every single program (without limitation) that they happen to use anywhere. of course none of the major sspl-using vendors are even pretending to themselves to follow these rules. sspl would be much better license if it just simply forbids providing services, instead of hiding behind this thin veneer of fake copyleft. > You can even still sell Redis as a service if you want, as long as you release all the orchestration systems under the same license (something that nobody would likely do, but this shows the copyleft approach of the license). note that this is not right, the "copyleft" is not limited to orchestration systems, it covers all programs that you use

ndiddy 2y ago
I believe that the original reason why they didn't just say "you're not allowed to provide this program as a service" is that MongoDB were trying to get SSPL approved by the OSI. The OSI didn't approve it because as you mention, it's basically impossible for a cloud provider to actually attempt to comply with the SSPL. Not only would they have to release the code to all software used to make the program available, they would have to do so under the SSPL. I'm not sure why MongoDB didn't change the wording when they gave up on getting the license classified as "open source".
ryukafalz 2y ago
> it is practically impossible for anyone to comply with that, to provide source code for every single program (without limitation) that they happen to use anywhere. It is practically impossible to comply, yes, but not just because you'd need to provide the source code to all the software you're using. The thing that really makes it impossible to comply with is that you must release all of that software under the SSPL. This could be reasonably interpreted to preclude the use of FOSS software, like Linux, that you do not have the authority to relicense under the SSPL. I wrote a blog post[0] about this a while back, but I think this is fixable if you allow the other software in the stack to be released under another FOSS license (and you could still require its disclosure). [0] https://www.terracrypt.net/posts/the-sspl-is-not-a-reasonable-copyleft-license-but-it-maybe-could-be.html https://www.terracrypt.net/posts/the-sspl-is-not-a-reasonabl...
vvillena 2y ago
Redis puts Redis into the open, and companies exposing Redis put everything they use to expose Redis into the open too. The key enabler in that whole business is still Redis, so the knowledge exchange appears fair.

jchw 2y ago

I'm sorry, but how is this a good answer? If you really only care about "two/three users in the world" and don't want users to worry about legal implications, why not explicitly write that in the license? It doesn't matter how good your intentions are, in the long run, it's not you or Redis, inc. we have to trust, it's anyone who potentially inherits the rights of these licensed IPs, at which point the courts will not rule on what your feelings are of what the license was meant to do but instead what was actually written and agreed to. That's why an existing, well-understood and symmetrical copyright license is going to beat out weirdo "business" licenses any day, and why they will never be considered OSI-compliant, which is fine, because if we all really hated big tech they're already allergic to the AGPL anyway. I know I'm not going to score any points by disagreeing with you here of all places, but I genuinely wonder if you really do believe this or if you mostly just don't care to actually confront the reality. This whole thing could be a nothingburger forever, or, alternatively, Redis, Inc. could some day be acquired by Oracle. Absolutely no way for any of us to know for sure. Unfortunately, that leaves me with little other option but to stick to the forks.

jcgrillo 2y ago
> Redis, Inc. could some day be acquired by Oracle This is truly the nightmare scenario, and it'll be interesting to see how it plays out when such a thing happens. Not saying specifically with these two companies, but so far these licenses aren't particularly tested, and it seems we just can't really know what will actually happen without running the experiment.
- stephenr 2y ago
  TBH oracle have been better stewards of MySQL since they bought Sun than Redis the company has been of Redis for the last five or so years.
  - jchw 2y ago
    I personally have wondered if Oracle's behavior with MySQL is partly motivated by the fact that if they try to rug-pull it will most likely just push all of the cloud providers over to MariaDB anyways, which has been doing just fine, and I think is already supported by Amazon RDS anyways. Ultimately I am totally fine with a fork-heavy ecosystem, the only thing I would erase if I could is the normalization of signing CLAs, as I think they make the normally-symmetrical prospect of contributing to open source projects highly asymmetrical, and the consequences are not always so obvious to people.

coldtea 2y ago

For the companies who "are copyright holders of the code" the uncertainty and litigation potential is not a bug, it's a feature.

collingreen 2y ago
This feature could actually be the overwhelming value of acquiring the copyright. When trillion dollar companies go to war with each other this kind of thing is a fantastic weapon in the arsenal.