> On 31 Jan 2019, at 01:21, John Harris <johnmh@xxxxxxxxxxxxx> wrote: > > 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 "making >> 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 > License. > 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 licence. > 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 Interface" >> 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 Components" as >> well as "System Libraries", but it's not what they've written in the >> 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; merely >> 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 Libraries" >> 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. > > Fair enough. > >> 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 >> example. > > 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. -- Simon Farnsworth _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
