On 31 Jan 2019, at 01:21, John Harris <johnmh(a)splentity.com>
On Wednesday, January 30, 2019 8:10:13 PM EST Simon Farnsworth wrote:
> I do if I'm using it to provide a service that could be construed as
> the functionality of the Program … available to third parties as a
> service", under section 13 of the SSPL. As MongoDB's functionality includes
> retrieval of documents and document fragments, it's possible to construe
> the licence as covering anything that involves retrieval of a document or
> document fragment from a server (so all web applications, for example).
Yeah, that's not what section 13 actually says.
If you make the functionality of the Program or a modified version available
to third parties as a service, you must make the Service Source Code available
via network download to everyone at no charge, under the terms of this
What exactly is "the functionality of the Program" in the case of MongoDB?
Document storage and retrieval are two components of that functionality, and as written,
it can be construed as meaning that if you provide document retrieval or document storage
from MongoDB in your service, then you "make the functionality of the Program
…available to third parties as a service".
I suspect this isn't what they mean, but it's what they've written in their
While the license certainly doesn't require anything that uses
MongoDB as a
backing store to be free software, you should definitely make that free
software under the terms of a license such as the AGPL.
Where are you licensed to practice law? And is this legal advice that I can rely on your
professional liability insurance for? Note that this statement is the exact opposite of
one I've had from a real lawyer whose liability insurance kicks in if they're
wrong - using MongoDB as a backing store could well be enough to require you to supply the
whole service, including Major Components like the Linux kernel, under SSPL. AGPL is
unacceptable - the terms say SSPL, and AGPL and SSPL are not identical.
> This may not be what's intended, but it's a reasonable
reading of the
> licence as written, and it could get expensive to argue in court that
> covering all document retrieval was not intended.
Perhaps. The easiest option is to just use only free software.
Worse than that - the only option if section 13 kicks in is to use only SSPL
licensed software, as you have to supply the majority of your source code *under the
SSPL*. Not just supply source code, but licence it under SSPL terms. AGPL may be Free
Software, but it's not acceptable here.
>>> I do not have sufficient rights to relicence the Linux kernel under the
>>> SSPL - it's not GPLv2 compatible - and the Linux kernel is one part of
>>> a service I might choose to offer using only Free Software from Fedora's
>>> repos, plus an SSPL licensed component.
>> Yeah, none of that matters. See section 1.
> I've read section 1 - Linux implements more than just a "Standard
> as per that section (it goes beyond POSIX or any interface specified by an
> Official Standards Body, and is not specified for a particular programming
> language). Because of the way section 1 is drafted, "System Libraries" are
> excluded from section 13, but *not* "Major Components"; the kernel in this
> case is a major component, and is thus only definitively excluded if it
> implements a "Standard Interface".
While I disagree, if you're worried about that just don't use grsecurity and
you're fine. Oh, and don't use proprietary kernel modules.
Or xfs, or ext4, or mmap, as they all supply things beyond just Standard
Interfaces as per the licence. And it's not enough to just release source - you are
required to supply the source to everything you supply under SSPL terms, which means that
you must have the rights to relicense all source you're supplying under the SSPL.
> This may be an oversight - they may intend to exclude "Major
> well as "System Libraries", but it's not what they've written in
> licence text. Only an item "which is not part of that Major Component" or
> which "serves only to enable use of the work with that Major Component, or
> to implement a Standard Interface" are excluded from the SSPL's reach.
> But not according to the text of the SSPL; for MongoDB specifically, the FAQ
> may act as "estoppel", but it's not part of the licence as written;
> providing document storage or retrieval provides "the functionality of the
> Program … to third parties". If I do that as a service - e.g. pulling out
> billing records from MongoDB - I'm "mak[ing] the functionality of the
> Program or a modified version available to third parties as a service", and
> I'm covered by section 13 and have to distribute all but "System
> as source under the SSPL. This *includes* "Major Components", as section 1
> doesn't actually exclude them.
Yes, I think SSPLv2 is going to be coming around soon to address that.
> Again, this may not be what they intended, but it's what the text of the
> licence says, and I would rather not rely on having to claim that what they
> wrote is not what they meant in order to succeed in court.
> Given these issues with the drafting of the licence, and the need to rely on
> MongoDB's FAQ to argue that, in the MongoDB case, the FAQ acts as estoppel,
> I can see why Fedora legal would consider the licence non-free. You've made
> claims for it that aren't backed by the actual text of the licence, for
Sure, but my interpretation of the License is based both on my comprehension
and on the intent set by the FAQ.
And mine is based on discussing the issues with lawyers, who told me that my
programmer-naïve view (which matched yours initially) was wrong, and that as written
today, if I store a document in MongoDB, then provide document retrieval from MongoDB as
part of a service on a Linux machine, I could be required to ship Linux kernel code to the
users of my service under SSPL terms, and I would have to do so without either infringing
copyright or accepting the GPL terms on redistributions.
The FAQ implies that all of this is a foul up by MongoDB Inc, and is not what they
actually intend, but that doesn't protect me if MongoDB is sold to a company like
Oracle that doesn't respect the intentions of its predecessor.
In particular, the ambiguity as written looks to be intended for use to stop you removing
parts of MongoDB functionality from your API, or from using MongoDB with an incompatible
API layer over the top, but there's nothing stopping MongoDB's future owners from
going further with it.