Source available
OpenRoots and Server Side Public License
Incompatible for derivatives. Treat as aggregate only unless counsel approves a narrow, separated architecture.
Inbound
noSSPL material entering an OpenRoots work
SSPL extends copyleft-style obligations to the software used to offer a service. An OpenRoots instrument does not impose that network-service source-release obligation and cannot pass it through without changing the bargain.
Outbound
noOpenRoots material entering a SSPL project
OpenRoots material cannot enter an SSPL-covered derivative because the revenue royalty, AI training licence, and competing-offering restriction are additional conditions SSPL cannot absorb cleanly.
Mechanism
Where the pairing holds and where it breaks.
A matrix cell tells you the answer. These are the clauses that produce it.
Derivative works
One combined, distributable artifact.Do not merge code under the two instruments. The obligations are structurally different and recipients would not receive a coherent permission set.
Composite distribution
Both shipped side by side, not merged.Separate-process aggregation is the safer pattern. Keep notices, packages, and service boundaries explicit so SSPL obligations do not get blurred into the OpenRoots portion.
Patent position
Express grants and termination triggers.SSPL inherits the MongoDB-era copyleft pattern. OpenRoots carries its own defensive patent structure and does not converge to Apache-2.0 by time alone, so patent review should be project-specific.
The royalty
Where the Canopy obligation bites.SSPL is not a revenue-sharing instrument. It conditions network service use on source-release obligations; OpenRoots permits production use and prices large-scale commercial use.
Current permanent terms
What holds for as long as the release exists.No automatic conversion occurs. The incompatibility remains unless the OpenRoots licensor separately relicenses the material.
Other pairs