|
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.o... |
> “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.