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

[Florian Weimer]

* 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?