[License-review] Approval: Server Side Public License, Version 1 (SSPL v1)

[Nigel T]

As a 3rd party consumer of web services I often have no idea how upstream components are licensed...and shouldn’t have to know.

SSPL seeks to close the loophole of systems made of composed services but 3rd party users of these systems aren’t always final end users.

Company A provides a service backed by MongoDB under the SSPL license.  Company B used Company A services to provide a different service.  Since B depends on the database functionality of MongoDB within Service A does SSPL section 13 requirements extend to them?

If so it reaches too far and is a copyleft landmine for everyone.  Nobody but SSPL adherents can afford to use any web service because somewhere some upstream service could potentially be encumbered by SSPL.  

Disclaimers that MongoDB users via the Apache APIs and SAAS providers aren’t encumbered is immaterial as that doesn’t appear in the license itself and IMHO not supported by the wording of section 13 in the license.  Other users of the SSPL license might not provide those FAQ exceptions.

If not then section 13 is kind of pointless as MongoDB Atlas competitors aren’t necessarily competing on software features of the supporting code but reliability and cost.  You might be able to get Amazon itself to stop competing if the AWS infrastructure code must be released because of SSPL but not another vendor that doesn’t care about releasing their code but lives on AWS.  

If SSPL requires releasing AWS code by the 3rd party competitor then yes, you are trying to stifle all commercial competitors and create a monopoly for Atlas using this license since they can never meet SSPL conditions even if they release all of their own code because the license conditions covers code that isn’t a derivative work of MongoDB.

I’m not philosophically opposed to this but SSPL’s intended business functionality is to be a CC-SA-NC type license which explicitly doesn’t meet the OSD.  IMHO Mongo should be transparent about this and not try to claim or imply it is open source or compliant with the OSD in its FAQ.

Even if the only ones blocked are Amazon and other cloud providers it fails.

Is there anyone advocating in favor of the license that can support an argument that it doesn’t violate 6 and/or 9?  Handwaving through repeated assertion by the submitter doesn’t count.

> On Oct 20, 2018, at 2:45 AM, Florian Weimer <fw at deneb.enyo.de> wrote:
> 
> * Bruce Perens:
> 
>> Brendan, I concur with you that OSD number 6 and number 9 are not complied
>> with. However, some of your hypothetical cases are moot because of the
>> operating system and system libraries exception which they have copied from
>> the GNU family of licenses.
> 
> Section 13 extends the requirement to license under the SSPL the build
> tools (“Corresponding Source for all programs that you use to make the
> Program or modified version”). Build tools or language run-times can
> qualify as System Libraries as far as the Program is concerned.  But
> in section 13, the requirement for Corresponding Source is applied to
> the build tools themselves (not just the Program), so we need to ask
> what is Corresponding Source for *them*.  The way the System Libraries
> are defined (“The "System Libraries" of an executable work include
> anything, other than the work as a whole […]”), a program cannot be
> its own system library.
> 
> This means that you have to relicense the build tools.
> 
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org