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

[Kyle Mitchell]

On 2018-11-09 15:11, Bradley M. Kuhn wrote:
> Carlo Piana wrote at 23:38 (PST) on Tuesday:
> > Honestly, despite I don't like SSPL very much, I don't find it
> > discriminates.
>
> The fundamental problem IMO is that we are reasonably sure that MongoDB
> plans to abuse the copyleft system with the SS Public License -- refusing
> themselves to be bound by it while using it as a lever to force "customers"
> into buying proprietary licenses.

"Copyleft" does not mean copyleft as specifically employed
by FSF, for software freedom as defined by FSF.  FSF's own
writing describes copyleft as a generic means, a tool, and
not as an end in itself, not software freedom.  More than a
few of RMS' pieces acknowledge the dual-use potential of
GPL, including for dual licensing:

https://www.gnu.org/philosophy/pragmatic.en.html

Neither has OSI limited its approvals to copyleft terms
serving FSF's activist ends, or weak copyleft licenses
derived from FSF's approach.  "Reciprocal" or "copyleft",
the effect is the same.  From Sleepycat, the earliest I
know, on.

> One of the fundamental problems with all the definitions (OSD, etc.) we've
> created up until now is that they seek to evaluate a license on its textual
> face, and not consider how it might be used.  We've now seen situations
> (proprietary relicensing being the most common) where licenses that are in
> the spirit of FLOSS and meet the OSD can *also* be used to negatively impact
> the software freedom of the users by the twisting of a license by a single
> copyright holder.  The SS Public License takes this from "bad" to "worse" in
> that it's a license drafted to make compliance so difficult that any
> informed user will either avoid the code entirely, or buy that proprietary
> license that MongoDB dangles at them alongside SS Public License.
> Uninformed users will have it worse -- they'll just fall into the trap and
> face a shake-down to buy a proprietary license.

FSF is the best-known single copyright holder of
GPL-licensed projects.  You're proposing a process that
discriminates against people and groups---single copyright
holders of copyleft projects other than FSF and vetted
allies---despite every modern GPL offering itself up as a
generic license for use by other licensors.

As for shakedowns, the submitter has stated an intent to
make SSPLv1 essentially permissive for users integrating
licensed work, e.g. MongoDB, into applications, as distinct
from offering that work as unintegrated services to others.
I also have concerns about the language selectively applying
strong-copyleft to spare that use case.  But drafting a
permissive grant is no sin, and license-review is a plenty
good place to discuss it.

> I think it's impossible to evaluate the SS Public License outside of this
> political context.  I can't really imagine a non-nefarious use of the SS
> Public License.  I also don't find value in studying the purely academic
> question of whether it meets the OSD, because I think the entire process
> used by MongoDB to force this license into an unfairly tight OSI evaluation
> schedule should yield rejection on pure procedural grounds.  (My suggestion
> upthread that MongoDB withdraw and redraft in a community process was
> heavily +1'd and never disagreed with, BTW.)

I disagree with the proposal to withdraw, and with the idea
that commentators here can vote out by drive-by +1 as a
matter of raw process, without stating and defending reasons
susceptible to debate.

I disagree with the notion that commentators can block a new
license by announcing some new, self-serving barrier to
entry, like a special community drafting process requirement
for copyleft licenses, put forward like a bill of attainder.

I am not aware of any public request for special expedited
or abbreviated review.

I have written that I believe SSPLv1 conforms to the
Definition.

I see nothing nefarious in dual licensing, or in using
strong copyleft to prevent free riding by competitors who
won't meet the licensor's generosity by contributing on
similarly generous terms.  I see quite a bit of good in
encouraging software companies to make contributing
significant source code on open terms the form of gift in
their potlatch.

> In other words, whether the SS Public license is "discriminatory" in its
> text is a debatable point that is hardly worth debating.  MongoDB's business
> model that they've used until now *is* discriminatory because they have more
> power than others over the codebase.  It's a legal use of copyright [0], but
> a nefarious and corrupt one -- just like using copyright to proprietarize
> software in the first place.  The OSD doesn't speak to this, and it's one of
> the reason that the OSI, FSF, and Conservancy collaborated on the drafting
> of the Principles of Community-Oriented GPL Enforcement -- as they addressed
> the gap in written community norms.

Any license condition creates a power differential between
the developer and users.  Eliminating power differentials
between the developer and other developers merely amplifies
existing power differentials between them.  If you want free
software out of small and even smaller public commercial
concerns, which at least OSI decidedly has, reducing every
license discussion to developer-user is blinkering.

The Principles serve their audience well.  Bravo,
colleagues.  But nothing about open source copyleft compels
every licensor to share that purpose or strategic approach.
FSF, SFLC, and other community enforcement bodies may share
an interest with larger and use-biased industrial concerns
in conciliation and defusing GPLv2-based risk in large,
shared projects.  They may prefer a world where we can all
march down to our Best Buy and buy a nonfree Linux device,
without headlines that Artifex-like companies are dragging
the foreign makers to court.  Maybe see a patch from those
makers, now and then.

At the same time, there is code hiding in proprietary
companies that could be free, and company-sponsored open
source that would avoid going closed-proprietary, under the
right set of strong-copyleft terms.  Terms that enable them
to segment effectively, to share as broadly as they can
permissively, without serving up the key products of their
collective efforts to firms that will end their lease on
financial life, and won't share alike.  Terms that enable
them to segment terms without artificially segmenting their
software, as we see with "open cores" on unobjectionably
free/open terms, or hybrids of technical and legal
segmentation, as we see in CockroachDB.  Terms that enable
companies to make the better choice among selling exceptions
and proprietary extensions or versions.

Those licensors will C&D, and they will sue. That is the
leverage they have.  Accumulating community goodwill by
funding open contributors on open projects for years costs
more than they have, and they haven't existed for that many
years.  Are we telling them to go nonfree, so their business
will be protected long enough to gain sway in
community-oriented governance, and then get back to us?

If we look to industry only as a source of working
situations that approximate grant- and donation-funded work,
we look right past most of the industry, and most hired
programming talent.  We look right past the smaller
companies where engineers who share our values enjoy
discretion.  MongoDB has been open source for almost ten
years.  The company was open-source-allied and
open-source-driven before they wrote the database.

We should examine what they propose on its merits, not on
theirs.  But vilifying them her is its own kind of bad
precedent.

> > If business users on all sides want this, but activists on all sides
> > don't, is that still enough?
>
> I don't think "business users on all sides" want the SS Public License.
> Exactly *one* business (and their paid law firm lawyer) are in control of
> and advocating for the SS Public License.

"Paid law firm lawyer" is ad hominem.  Were her arguments
sound?  Could the drafting be improved?

We should let other businesses speak for themselves.

> I don't see anyone else giving
> support to the SS Public License.  Can you point to posts I might have
> missed where other companies, individuals, or *anyone* has advocated that
> the SS Public License is a *good* license that will serve the public good?

I support the license.  It will serve the public good by
enabling more small, upstart companies to develop and
release on terms that let others use, study, change, share,
and build upon.  I also expect that such terms will serve as
a licensing waystation for many company-based projects that
eventually become permissively or consistent-copyleft
licensed, as we've seen with prior, business-drafted,
strong-copyleft terms that gave their proponents room to
establish business positions affording platforms for bigger
generosity.

To put it short: I'd rather see the kind of firm adopting
Commons Clause, a mixed permissive-proprietary license,
adopt something like SSPLv1, a hybrid permissive-copyleft
license.

> Interestingly, MongoDB is unwilling to even be bound by the SS Public
> License terms themselves, just as they have never been bound by the Affero
> GPL terms either because they demand CLAs that permit proprietary
> relicensing.  MongoDB themselves don't think being bound by the terms of the
> SS Public License is good for them, so I suspect that brings the count down
> to *zero* of those who look forward to being bound by the terms of the SS
> Public License.  Contrast this with other copylefts, where there are large
> groups of developers and users who are glad to be bound by its terms.

That's a criticism of CLAs and IP consolidation, not SSPLv1.

Appeals to nonexistent popularity for new licenses are
circular.  As far as I know, MongoDB submitted SSPLv1 here
as soon as they published its terms, making them available
to other licensors for the first time.  I don't think anyone
would be better served by telling them to make it popular
first.

> MongoDB could easily disprove my points here by coming forward and saying
> they'll be using inbound=outbound for their software from now on, and they
> are going to follow the license themselves too -- dropping the proprietary
> relicensing business model, accepting patches under SS Public License from
> the public, and attempt to build a true egalitarian community under the SS
> Public License.  I expect that commitment is not forthcoming.

Tongue-in-cheek: Why would you expect it to be?  Do you
think they wrote and submitted SSPLv1 to announce they're
abandoning their successful business model?  That the
largesse of public finance has enabled them to discover
their true calling: serving as a closet, cost-sharing
501(c)(6) facilitator for their competitors?

Their strong-copyleft use case is different.  I read quite
clearly that you object to that use case.  But I don 't
think you've tied it to OSI policy, principles, or history.

> What this situation has confirmed for me is something that Fontana suggested
> in his 2012 talk that I referenced earlier in this thread: it's likely the
> entire "license evaluation process" that we use is inherently flawed, as it
> cannot detect many other meta-license issues that are important to software
> freedom of users.

I understand the OSI license review process as reaching for
a broader consensus than FSF review, in particular.  But I
don't see any written guidance, from FSF or OSI, to prohibit
IP consolidation, dual licensing, or business-focused terms
more generally.  I see the opposite.

> Kyle Mitchell wrote at 12:19 (PST) on Tuesday:
> >>> Copyleft has always been dual-use technology.
>
> "Always" is pretty strong statement.  Can you point to proprietary
> relicensing being done under, say, with GPLv1 in the 1980s?
>
> s/always/for a long time/, I generally agree with your statement.  Like any
> tool that's generally available to all, copyleft has been used by good
> actors and bad actors for a variety of purposes.
>
> However, AFAIK (and I know this history pretty well), the first proprietary
> relicensing system was when Ghostscript switched from the Aladdin Public
> License to the GPL and began doing GPL enforcement for profit, circa the
> mid-1990s.  MySQL AB of course refined and popularized this model in the
> late 1990s into the early 2000s.

I'd be interested to learn who RMS quoted in "Copyleft:
pragmatic idealism".  That quote was apparently from "many
years ago" at the time, which was no later than 2000.

https://web.archive.org/web/20000303214900/http://www.gnu.org/philosophy/pragmatic.html

I believe Luis has mentioned a colleague who claims to have
advised on pre-MySQL/Ghostscript deal.

> My point in talking about *when* the community really began to understand
> proprietary relicensing practices and their policy implications is that I am
> pretty sure an in-depth understanding of these policies came well after the
> OSD was written and after much license-eval community precedent had been
> set.

Others around at that time would need to say.  But see my
list of licenses in next response, all from the late 1990s
and early 2000s.

RMS' piece on selling exceptions mentions considering and
advising on selling exceptions as early as the 1990s:

https://web.archive.org/web/20100304150726/http://www.gnu.org/philosophy/selling-exceptions.html

> I also believe this marks the first time that the OSI has ever looked at a
> license where the *only* likely use of the license will be proprietary
> relicensing.  I think that makes it a unique case.

It's not clear to me at all that the only use case here is
proprietary relicensing.  Sure, MongoDB does that:

https://www.mongodb.com/commercial-license

But its not by far their main line of business.  From S-1:

   Our primary subscription package is MongoDB Enterprise
   Advanced, our comprehensive offering for enterprise
   customers that can be run in the cloud, on-premise or in
   a hybrid environment.  MongoDB Enterprise Advanced
   includes our proprietary database server, advanced
   security, enterprise management capabilities, our
   graphical user interface, analytics integrations,
   technical support and a commercial license to our
   platform.  We also offer MongoDB Atlas, our cloud hosted
   database-as-a-service, or DBaaS, offering that includes
   comprehensive infrastructure and management of our
   Community Server offering.

That being said: Sleepycat, QFPL, RPL.

> [0] One of the most innovative things to happen in copyleft drafting is
>     Fontana's addition of §7 to copyleft-next:
>     https://github.com/copyleft-next/copyleft-next/blob/master/Releases/copyleft-next-0.3.1#L81
>     which prevents this problem entirely.  I doubt I'd support any future
>     copyleft license that doesn't include a similar clause.

That section of copyleft-next has the same kind of
_political_ problem as SSPLv1 section 13.  It splits the
historic coalition of strong-copyleft licensors.

SSPLv1's selective application of strong-copyleft to
unintegrated service provision makes it useless to software
freedom activists.  Likewise, copyleft-next section 7 makes
copyleft-next useless to upstart companies that want to dual
license, as a primary line of business or incidental part of
contracts for other products and services.  The next
Berkeley DB couldn't use it.  If a business proposed it to
OSI, I'd expect it to be an established player developing
the software as a loss-leader, not an upstart developing
their core product.

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