3 ms·

> 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 par

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

nine_k 8y ago
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.
- metheus 8y ago
  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.

nine_k 8y ago

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.

metheus 8y ago
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.