5 ms·

Check mongoDB's SSPL FAQ (https://www.mongodb.com/licensing/server-side-public-license/faq#when-to-use https://www.mongodb.com/licensing/server-side-public-lice

by Reelin 7y ago

Check mongoDB's SSPL FAQ (https://www.mongodb.com/licensing/server-side-public-license/faq#when-to-use https://www.mongodb.com/licensing/server-side-public-license...). As far as I'm concerned, SSPL is superior to AGPL in that it catches all the bits that make your software actually work, forcing you to include them as part of the offering. I honestly don't understand the apparent objection to referring to a license with such a clause as open source - all it does is close a (major imo) loophole.

detaro 7y ago
> “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.” So I can't run a service for it on VPS at a hosting provider, because I can not share the source to the backup system, hypervisor and load-balancer they use? Are firmware-blobs in my kernel-drivers ok? That seems extremely open and far-reaching, to the point that one could argue that it clearly is intended to forbid offerings as a service, even if it pretends not to. EDIT: after looking up details about the "comical debate" (quote article), that indeed appears to have been one of the arguments. Not surprising the article badmouths the OSI, but doesn't actually engage with or even dare mention their arguments.
- Reelin 7y ago
  Upon rereading the bit you quoted, I agree that could be an issue. I had initially misinterpreted "all such that a user could run an instance of the service using the Service Source Code you make available" to mean it was limited to any essential supporting bits you had implemented that might have otherwise been made proprietary (much to the detriment of a user trying to actually use the source code you provided). It does seem to be overreaching, but I also maintain that the AGPL has a major loophole as things currently stand. Edit: From the sibling comment, it seems that SSPLv2 tries to address this.
ryukafalz 7y ago
From my reading of SSPL v1, it would seem extremely difficult to use in concert with other free software; it requires you to distribute all software[0] you're using to run your service under the SSPL. The trouble is, you can't do that if you're using any other software in your environment that's licensed under another copyleft license such as the GPL. Does this apply all the way down to the Linux kernel? Who knows! SSPL v2 appears to be an attempt to correct this[1], by explicitly excluding system components and allowing other FSF/OSI approved licenses if you're unable to release something under the SSPL yourself. But note that not even MongoDB, the project that the SSPL came from, is using v2 at the moment. The GPL and AGPL have been around longer and have much more of a community behind them, and both versions of the SSPL are incompatible with them. At least for the time being, I'm inclined to stick with the AGPL for network services, because I like having access to all the GPL/AGPL code out there. Maybe someday I'll take a look at SSPL v2; I wouldn't touch SSPL v1 with a 10-foot pole. [0] "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" [1] http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-November/003836.html http://lists.opensource.org/pipermail/license-review_lists.o...
- Reelin 7y ago
  It seems there are indeed serious issues with SSPLv1 that I was unaware of. That being said, the loophole in the AGPL that they are attempting to address is also a serious issue. The rewording in v2 > “storage software and hosting software” changed to “host orchestration software” seems to be fairly reasonable though, unless I've misunderstood things once again? > But note that not even MongoDB, the project that the SSPL came from, is using v2 at the moment. From the page you linked, > If this version is approved by OSI, we plan to apply it to the next release of our MongoDB software, which is currently available under version 1.0. so it seems they really do just want to address the current loophole in the AGPL.
  - ryukafalz 7y ago
    >> “storage software and hosting software” changed to “host orchestration software” >seems to be fairly reasonable though, unless I've misunderstood things once again? It's better, though note that the terms in the list referenced there aren't strictly defined. >> If this version is approved by OSI, we plan to apply it to the next release of our MongoDB software, which is currently available under version 1.0. >so it seems they really do just want to address the current loophole in the AGPL. Sure, I'll give them the benefit of the doubt on that. But the fact that they haven't switched over by now signals to me that they're not yet confident in the newer version of the license; if they're not, I can't say I am either. And it's worth noting that SSPL v2 was withdrawn from the OSI review process back in March: https://opensource.org/LicenseReview032019 https://opensource.org/LicenseReview032019

by Reelin 7y ago

detaro 7y ago

> “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.” So I can't run a service for it on VPS at a hosting provider, because I can not share the source to the backup system, hypervisor and load-balancer they use? Are firmware-blobs in my kernel-drivers ok? That seems extremely open and far-reaching, to the point that one could argue that it clearly is intended to forbid offerings as a service, even if it pretends not to. EDIT: after looking up details about the "comical debate" (quote article), that indeed appears to have been one of the arguments. Not surprising the article badmouths the OSI, but doesn't actually engage with or even dare mention their arguments.

Reelin 7y ago
Upon rereading the bit you quoted, I agree that could be an issue. I had initially misinterpreted "all such that a user could run an instance of the service using the Service Source Code you make available" to mean it was limited to any essential supporting bits you had implemented that might have otherwise been made proprietary (much to the detriment of a user trying to actually use the source code you provided). It does seem to be overreaching, but I also maintain that the AGPL has a major loophole as things currently stand. Edit: From the sibling comment, it seems that SSPLv2 tries to address this.

ryukafalz 7y ago

From my reading of SSPL v1, it would seem extremely difficult to use in concert with other free software; it requires you to distribute all software[0] you're using to run your service under the SSPL. The trouble is, you can't do that if you're using any other software in your environment that's licensed under another copyleft license such as the GPL. Does this apply all the way down to the Linux kernel? Who knows! SSPL v2 appears to be an attempt to correct this[1], by explicitly excluding system components and allowing other FSF/OSI approved licenses if you're unable to release something under the SSPL yourself. But note that not even MongoDB, the project that the SSPL came from, is using v2 at the moment. The GPL and AGPL have been around longer and have much more of a community behind them, and both versions of the SSPL are incompatible with them. At least for the time being, I'm inclined to stick with the AGPL for network services, because I like having access to all the GPL/AGPL code out there. Maybe someday I'll take a look at SSPL v2; I wouldn't touch SSPL v1 with a 10-foot pole. [0] "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" [1] http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-November/003836.html http://lists.opensource.org/pipermail/license-review_lists.o...

Reelin 7y ago
It seems there are indeed serious issues with SSPLv1 that I was unaware of. That being said, the loophole in the AGPL that they are attempting to address is also a serious issue. The rewording in v2 > “storage software and hosting software” changed to “host orchestration software” seems to be fairly reasonable though, unless I've misunderstood things once again? > But note that not even MongoDB, the project that the SSPL came from, is using v2 at the moment. From the page you linked, > If this version is approved by OSI, we plan to apply it to the next release of our MongoDB software, which is currently available under version 1.0. so it seems they really do just want to address the current loophole in the AGPL.
- ryukafalz 7y ago
  >> “storage software and hosting software” changed to “host orchestration software” >seems to be fairly reasonable though, unless I've misunderstood things once again? It's better, though note that the terms in the list referenced there aren't strictly defined. >> If this version is approved by OSI, we plan to apply it to the next release of our MongoDB software, which is currently available under version 1.0. >so it seems they really do just want to address the current loophole in the AGPL. Sure, I'll give them the benefit of the doubt on that. But the fact that they haven't switched over by now signals to me that they're not yet confident in the newer version of the license; if they're not, I can't say I am either. And it's worth noting that SSPL v2 was withdrawn from the OSI review process back in March: https://opensource.org/LicenseReview032019 https://opensource.org/LicenseReview032019