4 ms·

Seems like there’s no talk on why they picked SSPL over BSL? I like BSL because it always eventually transitions to an ordinary open source license. So over ti

Seems like there’s no talk on why they picked SSPL over BSL? I like BSL because it always eventually transitions to an ordinary open source license. So over time all BSL licensed code will actually be open source. That seems to not be the case with SSPL? Good post on BSL: https://perens.com/2017/02/14/bsl-1-1/ https://perens.com/2017/02/14/bsl-1-1/

remram 6y ago
BSL doesn't let you use software "in production" at all. So you wouldn't be able to offer search on your website with Elasticsearch at all, whether you could be construed to be reselling it or not, and whether your whole stack is opensource or not. Also the SPDX identifier for it is BUSL since BSL was already taken by the Boost Software License.
- VoxPelli 6y ago
  Not true that it doesn’t allow production usage, it just doesn’t do it by default. The intention is that it’s up to the one using the BUSL to specify to which degree production usage is allowed: “The Licensor may make an Additional Use Grant, above, permitting limited production use.” Eg. Sentry allows all non-SaaS production deployments of their BUSL licensed code, which is pretty much the same goal as here, but with BUSL the code will be actually open source eventually whereas here it will stay in this extended AGPL-like license forever?
  - remram 6y ago
    I see. It's a really wide range of licenses then.
VoxPelli 6y ago
Also, note that Google prohibits all use of SSPL just like it prohibits use of AGPL: https://opensource.google/docs/thirdparty/licenses/#agpl-affero-gpl-and-sspl-not-allowed https://opensource.google/docs/thirdparty/licenses/#agpl-aff... It also prohibits use of Business Source Licensed software, but as source code under that license will always after at most 4 years transition to a GPL compatible license, all such code will eventually be possible to use at Google and one can easily maintain a GPL-compatible fork that merges code in as the BUSL expires, thus enabling a good exchange between BUSL and open source, whereas no such exchange is possible with SSPL, its forever stuck in a AGPL like license and most companies generally stay far far away from AGPL.

remram 6y ago

BSL doesn't let you use software "in production" at all. So you wouldn't be able to offer search on your website with Elasticsearch at all, whether you could be construed to be reselling it or not, and whether your whole stack is opensource or not. Also the SPDX identifier for it is BUSL since BSL was already taken by the Boost Software License.

VoxPelli 6y ago
Not true that it doesn’t allow production usage, it just doesn’t do it by default. The intention is that it’s up to the one using the BUSL to specify to which degree production usage is allowed: “The Licensor may make an Additional Use Grant, above, permitting limited production use.” Eg. Sentry allows all non-SaaS production deployments of their BUSL licensed code, which is pretty much the same goal as here, but with BUSL the code will be actually open source eventually whereas here it will stay in this extended AGPL-like license forever?
- remram 6y ago
  I see. It's a really wide range of licenses then.

VoxPelli 6y ago

Also, note that Google prohibits all use of SSPL just like it prohibits use of AGPL: https://opensource.google/docs/thirdparty/licenses/#agpl-affero-gpl-and-sspl-not-allowed https://opensource.google/docs/thirdparty/licenses/#agpl-aff... It also prohibits use of Business Source Licensed software, but as source code under that license will always after at most 4 years transition to a GPL compatible license, all such code will eventually be possible to use at Google and one can easily maintain a GPL-compatible fork that merges code in as the BUSL expires, thus enabling a good exchange between BUSL and open source, whereas no such exchange is possible with SSPL, its forever stuck in a AGPL like license and most companies generally stay far far away from AGPL.