3 ms·
Are there any known instances where a company offering Mongo or another SSPL-licensed app as a service has complied with section 13 by releasing the “Service So
by kam 6y ago
Are there any known instances where a company offering Mongo or another SSPL-licensed app as a service has complied with section 13 by releasing the “Service Source Code” of everything supporting the service?
If not, that basically confirms the OSI's rejection of the SSPL as an open source license -- If that provision is too onerous to be followed, it might as well say "you can't offer this as a service".
- lacker 6y agoYou could say the same about the GPL - the practical effect is almost never to make a company release their previously-proprietary source code, the practical effect is to make companies not use it in the first place. Which is fine, as long as it's clear what the rules are, and the rules seem clear enough to me.
- ahachete 6y agoSo there's no big cloud offering MySQL-as-a-Service, right? And nobody uses Linux for their *-as-a-Service offering, no?
- slaymaker1907 6y agoI don't think this is correct. It definitely seems like code that would otherwise be proprietary does end up being open sourced in the case of the Linux kernel with certain drivers.
- choeger 6y agoIn principle this should not be a big problem. See how Red Hat successfully works with GPL code. I think the big issue is that all Sass Providers considered themselves free from such pesky license details like copyleft, because they don't distribute software. I think the biggest problem with the SSPL is its vagueness when it comes to liabilities and its broad reach when it comes to contagion. In principle, a copyleft license that covers service providers is long due, but it better be a good and practical one.