Fabio Manganiello on Nostr: Btw I’m wondering how this license may impact use-cases where the component A ...
Btw I’m wondering how this license may impact use-cases where the component A released under #SSPL is not used directly by software B, but software B uses C (or it forks C), which in turn uses A (i.e. if the license is transitive).
An example: in #Platypush I use #Redis quite heavily - as an in-memory cache, as a pub/sub framework for inter-process communication, and as a memory queue.
Platypush is already FOSS, but it’s released under a relatively permissive MIT license. (I’ve pondered a lot over the pros/cons of MIT vs. *GPL when licensing a product like Platypush, in the future I may also considering switching to AGPL, but for now MIT is a good trade-off).
This means that people are free to copy the code of a Platypush plugin into their projects. Or use its plugins as libraries for their own integrations. Or extend it with their own plugins. Or make a fork and expose it as a service on their cloud. And the MIT license doesn’t require anybody to redistribute the full source.
But Platypush also uses Redis, which is now under SSPL.
What should company X, which has made their closed fork of Platypush with a bunch of proprietary integrations, and maybe distribute it as a service, do now? They are basically exposing a closed service that uses Redis under the hood, which violates SSPL. But the service itself is a fork of an open service released under MIT, so there’s no violation from that point of view.
In other words, does SSPL override other more permissive licenses every time a product is exposed as a service?
An example: in #Platypush I use #Redis quite heavily - as an in-memory cache, as a pub/sub framework for inter-process communication, and as a memory queue.
Platypush is already FOSS, but it’s released under a relatively permissive MIT license. (I’ve pondered a lot over the pros/cons of MIT vs. *GPL when licensing a product like Platypush, in the future I may also considering switching to AGPL, but for now MIT is a good trade-off).
This means that people are free to copy the code of a Platypush plugin into their projects. Or use its plugins as libraries for their own integrations. Or extend it with their own plugins. Or make a fork and expose it as a service on their cloud. And the MIT license doesn’t require anybody to redistribute the full source.
But Platypush also uses Redis, which is now under SSPL.
What should company X, which has made their closed fork of Platypush with a bunch of proprietary integrations, and maybe distribute it as a service, do now? They are basically exposing a closed service that uses Redis under the hood, which violates SSPL. But the service itself is a fork of an open service released under MIT, so there’s no violation from that point of view.
In other words, does SSPL override other more permissive licenses every time a product is exposed as a service?