3 ms·

SSPL is not really comparable IMO. Check my comment here https://news.ycombinator.com/item?id=39862916 https://news.ycombinator.com/item?id=39862916 : > SSPL i

by rany_ 3y ago

SSPL is not really comparable IMO. Check my comment here https://news.ycombinator.com/item?id=39862916 https://news.ycombinator.com/item?id=39862916 : > SSPL includes most of the AGPLv3 ... but modifies its provisions for software that is conveyed over a network—requiring that anyone who offers the functionality of SSPL-licensed software to third-parties as a service must release the entirety of their source code, including all software, APIs, and other software that would be required for a user to run an instance of the service themselves, under the SSPL. In contrast, the AGPL v3's equivalent provision covers only the licensed work itself. This just goes beyond anything reasonable IMO, they set terms that no-one could comply with so you need to negotiate to have it under a different license.

notpushkin 3y ago
> the entirety of their source code, including all software, APIs, and other software that would be required for a user to run an instance of the service themselves, under the SSPL And why is that unreasonable?
- rany_ 3y ago
  Do you really think this is a good faith offer? It is just extortion, at least the AGPLv3 applies to the AGPLv3 software you're using ONLY.
  - rakoo 3y ago
    This is extortion if you want to not share back. For Libre software maximalists, this is a good thing: considering you can't do anything without others, it is only normal that you share what you do with others.
  - notpushkin 3y ago
    I do think that when the shared code scope is limited correctly, this is a good faith offer. For example, if you offer my product under SSPL as a service, I would expect that you share: - all your changes to the product - all infrastructure code you use to deploy the product for your customers - all billing code you use to bill for the product But I would not expect you to release code for e. g. services based on other products (open source or otherwise), or your whole billing stack, or your internal services you use for customer support for example. Just the code that you use with my particular product. Now, SSPL is a bad license for numerous reasons (many of the concerns in the OP article are valid!) and this is why I've decided against it on my project [1], but I think the basic premise of it is completely valid. [1]: https://lunni.dev/ https://lunni.dev/, licensed AGPL-3.0
    - rany_ 3y ago
      I think the bigger issue is that you'll basically be at the mercy of the courts on how far you need to go with it. The scope isn't well defined IMO and it really couldn't be. Do I need to open source components that I don't have any control over and are proprietary? The questions are endless...
      - notpushkin 3y ago
        Yeah, that's part of the problem, too. Although it's also a problem with GPL and the likes: you can't integrate closed-source components from third parties with GPL software.
chii 3y ago
It might literally be impossible to comply with SSPL - if you use a closed source piece of software to perform some other backoffice/billing/ERM software, you literally don't have the capability to release to comply. SSPL also deals with selling the software under license as a service, but it does not define _exactly_ what is included as pertaining to being SaaS. It only gives you some examples. This means the actual test can only be determined in a civil suit.

by rany_ 3y ago

notpushkin 3y ago

> the entirety of their source code, including all software, APIs, and other software that would be required for a user to run an instance of the service themselves, under the SSPL And why is that unreasonable?

rany_ 3y ago
Do you really think this is a good faith offer? It is just extortion, at least the AGPLv3 applies to the AGPLv3 software you're using ONLY.
- rakoo 3y ago
  This is extortion if you want to not share back. For Libre software maximalists, this is a good thing: considering you can't do anything without others, it is only normal that you share what you do with others.
- notpushkin 3y ago
  I do think that when the shared code scope is limited correctly, this is a good faith offer. For example, if you offer my product under SSPL as a service, I would expect that you share: - all your changes to the product - all infrastructure code you use to deploy the product for your customers - all billing code you use to bill for the product But I would not expect you to release code for e. g. services based on other products (open source or otherwise), or your whole billing stack, or your internal services you use for customer support for example. Just the code that you use with my particular product. Now, SSPL is a bad license for numerous reasons (many of the concerns in the OP article are valid!) and this is why I've decided against it on my project [1], but I think the basic premise of it is completely valid. [1]: https://lunni.dev/ https://lunni.dev/, licensed AGPL-3.0
  - rany_ 3y ago
    I think the bigger issue is that you'll basically be at the mercy of the courts on how far you need to go with it. The scope isn't well defined IMO and it really couldn't be. Do I need to open source components that I don't have any control over and are proprietary? The questions are endless...
    - notpushkin 3y ago
      Yeah, that's part of the problem, too. Although it's also a problem with GPL and the likes: you can't integrate closed-source components from third parties with GPL software.

chii 3y ago

It might literally be impossible to comply with SSPL - if you use a closed source piece of software to perform some other backoffice/billing/ERM software, you literally don't have the capability to release to comply. SSPL also deals with selling the software under license as a service, but it does not define _exactly_ what is included as pertaining to being SaaS. It only gives you some examples. This means the actual test can only be determined in a civil suit.