Hacker News Reader

Comment by nine_k | Hacker News Reader

The meat of the change:

SSPL explicitly states that anybody who wants to offer MongoDB as a service — or really any other software that uses this license — needs to either get a commercial license or open source the service to give back the community.

Looks like a pretty straightforward extension of GPL principles, by replacing the linking of licensed code to remotely calling the licensed code.

It can have a lot of implications for service providers and commercial developers alike, depending on the way commercial licenses will work. (Some DB licenses have pretty stifling clauses, like Oracle's or MS SQL's.)

View on HN

The trick question here is - "Open Source the service" - under what license? Does it also have to be SSPL, or it can be any OpenSource license?

MongoDB was already under the AGPL (which adds the copyleft via network provision) so I suspect there is a bigger difference than that.

AGPL requires you to share the changes to the licensed software you make available, that is, changes to the MongoDB itself.

It was like LGPL in the local case: you alter the library and make it available through the software you link with it, so you have to share the changes you've made to the library, but not the rest of the linked code.

With SSPL, it's like the full GPL in the local case: if you take the licensed software, and link it (via rpc / network) to your other software, you must share not only any changes you've made to the licensed part, but the whole thing that uses it.

Another tricky question is where the border line is. If I write a wrapper that interfaces with MongoDB and repackages its data, then makes them remotely available to the rest of my service, do I only need to share the wrapper? If not, and any network connection that substantially uses an SSPL piece counts, then do I have to share my internal monitoring system? Am I even allowed to connect closed-source data analysis tools to an SSPL database? Etc.

> if you take the licensed software, and link it (via rpc / network) to your other software, you must share not only any changes you've made to the licensed part, but the whole thing that uses it.

Slight modification makes this accurate to the SSPL: if you take the licensed software, and link it (via rpc / network) to your other software which you use to offer the SSPL licensed software as a service, you must share...

> Another tricky question is where the border line is.

Ultimately the trigger of the SSPL is whether what you offer publicly is the SSPL-licensed software as a service. It doesn't trigger the SSPL if you make MongoDB available as a service to your application internals as long as what you're making available publicly is not "a service the value of which entirely or primarily derives from the value of the Program or modified version..."

Playing a devil's advocate. Suppose somebody made a clean-room implementation of a MongoDB driver that contacts MongoDB, then passes the data to a MongoDB-compatible interface that shares no code with MongoDB. This wrapper is duly shared. Can that guy then offer a SaaS MongoDB-compatible DB by exposing this driver, connected to a real MongoDB, without a commercial license?

As we notice, all that SSPL would require to share is shared in this case.

Then a wholly-owned subsidiary could build various value-added services on top of that MongoDB-compatible thing without a commercial license. This of course would fail if the wrapper would need to be licensed under SSPL, too.

The SSPL neatly sidesteps that workaround. It does not specify anything about the provenance of code, or the extent to which code is shared with the licensed software's code.

If you offer a service based on the licensed software, and the value of the service being publicly provided entirely or primarily derives from the licensed software, every bit of code -- the clean-room driver, the compatible interface, the admin scripts, UI for management, etc. -- used to offer that service must be made available under the SSPL.

Reply on news.ycombinator.com