[License-review] Approval: Server Side Public License, Version 1 (SSPL v1)
Bradley M. Kuhn
bkuhn at ebb.org
Fri Nov 9 23:10:01 UTC 2018
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.
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.
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.)
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.
I realize the OSI, under its own current rules and historical precedents,
seems trapped into evaluating the SS Public License in light of its
stand-alone text and the text of the OSD, and cannot easily separately
evaluate possible uses of the license and condemn those (although I wish the
OSI would do so). It seems to me that MongoDB is banking on OSI falling
into that trap.
> 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. 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?
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.
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.
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.
As a community, we seem have erred when we said: "verify that the license of
the software you get is on OSI-, FSF-, and DSFG- approved, and all will be
fine". Fact is, a licensing being approved by OSI, FSF, and Debian is a
*necessary* but not *sufficient* condition to determine what software
freedom is truly respected in a real way by a given project, particularly
when you face a sole-copyright-holder scenario.
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 certainly did not understand the problematic policy implications of what
Aladdin (and their successors) were doing with Ghostscript and what MySQL AB
was doing with MySQL until the mid-2000s. To my recollection, I do not
recall anyone during that time frame writing about the issue and considering
its policy implications carefully. Mostly, users during the late 1990s and
early 2000s were just confused about the proprietary relicensing business
model and how it worked. I was an expert in the field by that time, and I
recall being confused myself because it just wasn't clear what was happening
to users in its earliest days. I thus didn't see in-depth discussion until
the late 2000s (probably somewhere around 2006 or so).
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.
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.
Luis Villa wrote at 09:31 (PST) on Tuesday:
>> This discussion will be healthiest if we can grapple with that honestly
>> instead of tying ourselves in knots to deny it.
I think it would even healthier to admit the political realities of how
MongoDB is trying to pressure the OSI to give MongoDB the marketing
endorsement of "OSI-Approved" for their license that *no one* (including
MongoDB) is planning to be bound by, and figure out what OSI needs to change
to avoid being gamed by open-washing companies in this way.
[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.
--
Bradley M. Kuhn
Pls. support the charity where I work, Software Freedom Conservancy:
https://sfconservancy.org/supporter/
More information about the License-review
mailing list