Hacker News Reader

Comment by kam | Hacker News Reader

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".

View on HN

In 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.

You 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.

So there's no big cloud offering MySQL-as-a-Service, right?

And nobody uses Linux for their *-as-a-Service offering, no?

I 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.

Reply on news.ycombinator.com