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

[Kyle Mitchell]

On 2018-11-08 09:11, Matija Šuklje wrote:
> On sreda, 07. november 2018 21:52:46 CET Smith, McCoy wrote:
> > I continue to believe LZPL & SSPL *do* violate OSD 9, because
> > they impose restrictions on other software – i.e., they dictate
> > the license and rights to that software, requiring LZPL or SSPL
> > – *even when* that software in no way exercises the rights
> > granted by those licenses
>
> I see OSD 9 as the big issue here as well.
>
> It is true that (A)GPL – which are listed by OSI as an Open Source
> license – already demands for build scripts etc. needed to build
> and run the program to be released as well as part of its
> “Corresponding Source”, but the scale of SSPL’s “Service Source
> Code” is much much broader. The big difference is that (A)GPL
> requires these build scripts (etc.) only to be supplied with the
> main Program and their source code to be made available (or
> offered) – regardless under which license.

I think we agree that the issue is how much software open
source copyleft can reach.  But I couldn't disagree more
strongly with the idea that squeezing an answer into or out
of OSD 9 is how we best go about answering that question.

To make OSD 9 relevant, we have to disregard "distributed".
To do that, we have to disregard the example, too, since it
emphasizes distribution.  What's left is the heading with
"place restrictions" instead of "restrict".

In answering our question about copyleft reach, our whole
bounty for selective reading is "other software".  That's
all there is.  The word "software" might be useful against a
license that requires distributing and licensing other kinds
of work, like business plans or documentation.  But given a
copyleft license that reaches software, "other" wouldn't be
any help at all deciding whether it reaches too far.  It
would tell us that there _is_ some line, but literally
nothing about where to draw it, or why.

If the rule is "other software", read broadly, we have a
GPLv2 problem.  I'd say changes and possibly additions to
the licensed, copyleft software would count as "the same
software".  No problem there.  But applications built with a
library?  If I build a dental records management application
with a GPLv2 file format parser, wouldn't my application be
"other software"?  But that can't be right.  We must be
making a mistake elsewhere.

In short, even if we're willing to abuse or simply ignore
OSD 9's text, in favor of the heading, the most it can tell
us about open source copyleft's permitted reach is that
there _is_ some limit, somewhere.  When we talk about what
that limit should be, or why, we're not speaking from OSD
anymore.  We're talking about what we think OSD _should_
say, not about what it does say.

> The SSPL, on the other hand, demands that all “Service Source
> Code” is made available via the internet under SSPL-1.0 as well.
>
> The “System Libraries” and “general-purpose tools or generally
> available free programs which are used unmodified in performing
> those activities but which are not part of the work” carve out
> from the “Corresponding Source” (§ 1 in both SSPL-1.0 an
> AGPL-3.0) may help here to some extent in practical compliance,
> but I doubt it will (or IMHO should) be enough for OSI.

There are many loopholes in AGPLv3.  I've taken to calling
two of them "API Loophole" and "Container Loophole".

The API Loophole argues that combination in a single service
application via IPC calls over standardized interfaces falls
outside the terms AGPLv3 defines to set copyleft reach.
Call it "network linking", to distinguish from static and
dynamic linking.

The Container Loophole argues that even if AGPLv3's
definitions do reach the service application as a whole, the
definitions designed to stop copyleft reach short of the
system level stop AGPLv3 from reaching across machine and
container boundaries, to reach the service application as a
whole.  That's a major limitation for service applications
compromised of networks of independently deployed service
components, each comprising a program running in its own
virtualized or containerized operating system environment,
in turn.

In such service applications, both MongoDB and the
business-logic programs building on it often run on their
very own Linux instances.  Under AGPLv3, each of those
instances acts as a kind of shell, as an arguable copyleft
reach boundary.  The Linux instances may or may not be
hosted on one and the same other Linux instance, closer to
bare metal.  But the business-logic program, often a web
service, can't run without Mongo being deployed into its
network, any more than an installed program can run without
the libraries it dynamically links to installed on its
system.

SSPLv1 is more directly concerned with the API Loophole than
the Container Loophole, because SSPLv1 doesn't actually want
to apply strong copyleft to service-and-application
integrators.  It wants to apply strong copyleft selectively
to those offering the licensed software as an unintegrated,
generic, managed service component.  But it has to deal with
the Container Loophole all the same, because managed service
deployments and systems relevant to managed service
components, like monitoring and logging facilities, are
often made of independent virtualized or containerized
system instances, too.

In the end, the reason for allowing open source copyleft to
reach across network linking is the same reason to allow
reach across dynamic linking.  Allowing open source copyleft
to reach across some technical means of software
combination, but not others, allows copyleft code to end up
in nonfree applications.

The same is true of drafting to particular means of
combination, whether in technical terms, as in LGPLv2.1, or
in legal terms, as in GPLv2.  That approach makes sense when
weakness is the goal, as in EPL or MPL.  When strength is
the goal, better to state the point as it is meant and will
be understood, without needless coupling to particular legal
or technical details.  That SSPL takes that approach makes
it _feel_ like a bigger leap from GPL-style copyleft.  But
not if you reread the GPL preambles, and then ask how you'd
draft the license to follow, knowing what we know today.

The reason for allowing open source copyleft to reach
outside code providing the core end-user functionality to
code facilitating management, deployment, execution, and
development is the same reason to allow (A)GPLv3 to reach
scripts for installing, running, and modifying.  Software
freedom means not just freedom to study, but also freedom to
run, adapt, and further develop.  Our ideas of free software
and open source stem from those technical practicalities,
not from reverence for copyright law or its concepts, like
"derivative work" or the 106 rights.

-- 
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933