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

[Eliot Horowitz]

It was not our intention that compilation would constitute making “the
functionality of the Program or a modified version available to third
parties as a service.” We think that interpretation is farfetched. We
will consider whether this requires clarification.
On Thu, Oct 18, 2018 at 2:58 AM Florian Weimer <fw at deneb.enyo.de> wrote:
>
> * Eliot Horowitz:
>
> > First, I want to thank everyone for their responses, even those who
> > strongly disagree with our point of view. I have tried to answer most
> > of the questions in this one response, if I have overlooked something
> > or am doing something against etiquette, please let me know.
>
> I should start by saying that I work as a toolchain engineer at Red
> Hat, and while I'm not involved in packaging or running the software,
> the company is likely impacted in some way by the relicensing.
>
> The opinions and recollections written down here are my own, though.
>
> (I'm also active sometimes in Debian.)
>
> > Our intention is absolutely to have a conversation with this community
> > and we will carefully consider changes to the license that may be
> > suggested in these discussions. Our hope is that by building on an
> > existing license that was the subject of extensive work and
> > discussion, less review will be needed. We understand your concern
> > with applying the license to the code before having gone through this
> > process. Unfortunately it was necessary for us as a public company to
> > do so.
> >
> > We think it is time for an extension of copyleft.
>
> I don't necessarily disagree.  I think the GPLv3 weakened copyleft
> significantly because of the cloud computing exception.
>
> > I think we can all agree that the GPL is not intended to be used by
> > proprietary libraries. When you link to a GPL'd library, copyleft
> > applies to your entire program. This is how many people today
> > understand the applicability of the GPL. This made a lot of sense 30
> > years ago, when GPL was first written, and has been beneficial to the
> > community. In the modern era, however, very few programs are actually
> > linked, in the sense of a programmatic link at build or compile time.
> > Most modern applications are constructed by combining components as
> > services which talk over the network via structured APIs. So we
> > believe that the nature of the copyleft must evolve for the modern
> > world. In the SSPL, we believe the concept of copyleft ought to apply
> > to the pieces that make the original program run, but not everything
> > else that touches it.
>
> This is not a new problem at all.  There once was considerable debate
> whether you could have software running on Emacs which was not
> licensed under the GPL.
>
> > An example might be useful. libmysqlclient is a GPL’d library file,
> > and therefore copyleft provisions of the GPL apply to any program that
> > links to libmysqlclient. The mysql command line interpreter is one
> > such program, and it, too, is a GPL’d program. If someone wrapped the
> > mysql command line in a network service (say, a trivial bidirectional
> > proxy that “shelled out” to mysql), nothing in the GPL causes copyleft
> > provisions to apply in a way that provides benefit to the community.
>
> You can also connect directly to the database with a custom client.
> Such clients exist:
>
>   <https://github.com/mysqljs/mysql>
>
> (Note sure if that's the way people actually use MySQL from Nodejs,
> but you get the idea.)  SQL databases are also often advertised as
> implementing standardized interfaces, making the exchangeable to some
> degree.
>
> > This is the sort of loophole we have understood that the AGPL was
> > intended to address, namely, to ensure that some copyleft provisions
> > applicable to software will be meaningful in the case of software
> > provided as a service. Unfortunately, we believe there’s ambiguity in
> > the AGPL sufficient to easily sidestep its copyleft provisions via
> > architectural considerations.
>
> There are several things that were odd about your use of the AGPL:
>
> * Your software does not contain a mechanism to download its own
>   sources once you have a (possibly authenticated) network connection
>   to it.  I think the AGPL was originally intended for situations
>   where you could change index.php in a URL to index.phps and view the
>   relevant source code, which used to be very easy to achieve with PHP
>   web servers (not so anymore because PHP itself has evolved).
>   Without such a built-in compliance mechanism, I don't think it's
>   reasonable to apply the AGPL to a piece of software.
>
> * Most of the client libraries seem to be licensed on the Apache
>   License, version 2.0.
>
> * My recollection is that you told your community that the AGPL didn't
>   apply to them if they used your software in the back end.  Users of
>   your software did not have to add source code distribution
>   mechanisms for your software to their web applications.
>
> > For example, if I have an AGPL key value store library and I combine
> > it with a network library and a management UI, then the copyleft
>
> Again, the main problem here is that the original AGPL software has no
> built-in compliance mechanism, and it does not directly interact with
> the network.
>
> > provisions of the AGPL apply to this use of the network library and
> > the management UI, because of linkage. However, if someone splits out
> > the management UI to a separate component that only interacts with the
> > combined key-value store and network library over a socket or other
> > IPC mechanism, it is unclear whether existing licenses’ copyleft
> > provisions apply to that split-out management UI. For a program that
> > is used only as a network service, we want to be sure that all
> > components that make up the service, e.g. management and backup, are
> > included in the scope copyleft provision of the SSPL.
>
> I think this is very hard to do, with any license.  It's very
> difficult to prevent others from enhancing an existing program with a
> separate program.  People have tried, but successfully?  I don't know.
>
> Is your management and backup solution currently available under the
> AGPL?  I find it difficult to believe that someone would see a
> business opportunity, ripping out an existing component of an AGPL
> system and replace it with something proprietary.
>
> > In short, we believe that in today’s world, linking has been
> > superseded by the provision of programs as services and the connection
> > of programs over networks as the main form of program combination. It
> > is unclear whether existing copyleft licenses clearly apply to this
> > form of program combination, and we intend the SSPL to be an option
> > for developers to address this uncertainty.
>
> True.  The AGPL does not extend to the entire system.  But (if my
> recollection is correct) this is not what you intended in the first
> place.  And your comment below suggsts that even today, you do not
> want your users to turn their programs into free software and ship
> sources.
>
> The latter part is the main reason why I think you are not totally
> upfront regarding your intentions.  This does not seem to be about
> making more free software available.
>
> You seem to have some rules about who is a good user and who is a bad
> user.  But as far as I can see, these rules are *not* primarily about
> how these users license the software they write.  It's something else.
>
> > We are not intending to drive all users to a commercial license. In
> > fact, by limiting the applicability of section 13 to offering the
> > functionality of the licensed software as a third party service, we
> > are hoping the SSPL will be less scary than the AGPL for those who use
> > SSPL software for other types of SaaS applications. For our software
> > in particular, this is consistent with our prior guidance that
> > applications interfacing through our Apache 2 licensed drivers are not
> > subject to the copyleft provisions of our license. If there is
> > ambiguity on this in the license, we would consider suggestions on
> > ways to clarify.
>
> I still don't know if you want distributions to stop packaging your
> software.  The packages are offered to end users (third parties), and
> compiling the software is a service related to the software.
> GNU/Linux distributions use the GNU toolchain and therefore cannot
> make available under the SSPL the tools used to build the software.
> The System Library exception does not apply to (say) GCC when
> considering GCC itself.
>
> All distributions use proprietary software (non-free TCP stacks) to
> distribute pre-compiled packages.  This is actually something I
> dislike very much, but is it really your battle to fight?