
SSPL Was Not Commons Clause - janvdberg
https://writing.kemitchell.com/2019/06/13/SSPL-Not-Commons-Clause.html
======
eesmith
I recently gave a talk at a local programmer meeting about free and open
source licenses and how they affect revenue opportunities.

This led me to a more in-depth look at SSPL and at the Commons Clause.

My (amateur and shallow) analysis was about the same as what Kyle E. Mitchell
writes (though mine was more amateurish and shallow).

I concluded that Fedora was wrong in arguing that SSPL was not open source
because it "is intentionally crafted to be aggressively discriminatory towards
a specific class of users"

This seemed to be a call out to the guideline that a FLOSS license could not,
for example, prohibit its used in 'the military' or 'nuclear power
facilities'.

However, at the broad level, the GPL 'is intentionally crafted to be
aggressively discriminatory towards' the class of users who would further
restrict software freedoms. So that along isn't enough justification.

Elsewhere it was clear that that class was meant to be "cloud providers".

I disagreed with that too. The GPL discriminates against "operating system
vendors" too, before there were any operating system vendors who decided to
include GPL'ed software.

This "class of user" argument against the SSPL seemed to conclude that it was
impossible to be a cloud vendor without using proprietary software.

I'm glad then to read "That speaks directly to MongoDB’s history. MongoDB,
Inc. began as 10gen, a startup attempting to offer a fully open source cloud."
as it fit into my understanding.

~~~
kemitchell
I took a lot of hope from this comment, not so much because you agreed with
me, but because you seem to have come to your own conclusions _independently_.
As I hope comes through the post, I wish more folks had dug in deep, rather
than engaging with the surface of Mongo's proposal.

If you're interested in more writing on licensing and business models, might I
self-cite a couple more for you?

[https://blog.licensezero.com/](https://blog.licensezero.com/) \--- blog for
my project, License Zero, which offers the back-office of a dual licensing
operation to small and independent developers as a service

[https://indieopensource.com/](https://indieopensource.com/) \--- nascent
place for more writing, and explainers, about various business models that
work for solo/indie devs

~~~
eesmith
In part of my preparation, I dug up MongoDB's old blog post on why they chose
the AGPL.

It came across like it was part of the pattern of dual licensing - use the
least profit-friendly license to get people to pay for a commercial license.
It didn't come across like they wanted to support freedom.

This practice seems a bit shady, in that I get the impression that many people
use AGPL for FUD purposes. (Rather like how MySQL used GPL FUD to sell
commercial licenses.)

But I am also reminded that there seems to be this view that big companies
should be able to do whatever they want, including making money, while little
"open source" companies and independent developers must remain poor - I mean,
"pure".

I think both perceptions contributed to the backlash.

I honestly think that something like the SSPL is our best chance to have free
software remain free as systems move to the cloud.

~~~
kemitchell
> I dug up MongoDB's old blog post on why they chose the AGPL.

Link me to it? I think I know which one you have in mind, but I'm not quite
sure.

~~~
eesmith
Thank you for asking me to double-check.

I was wrong. I confused MongoDB with Redis.

The earliest MongoDB AGPL post in Archive.org is
[https://web.archive.org/web/20090515015736/http://blog.mongo...](https://web.archive.org/web/20090515015736/http://blog.mongodb.org/post/103832439/the-
agpl) . It clearly is concerned with software freedom and doesn't mention
funding.

(Though it does comment 'the goal is that you have to contribute those
modifications back to the community.' But AGPL doesn't require contributions
'back to the community', only to the downstream users, yes?)

The blog post I was thinking of, for Redis, is archived at
[https://web.archive.org/web/20180825041319/https://redislabs...](https://web.archive.org/web/20180825041319/https://redislabs.com/blog/why-
redis-labs-modules-are-agpl/) titled "Why Redis Labs’ Modules are AGPL".

It makes the odd statement "Therefore, we wanted to make sure no one else can
resell them for commercial purposes."

I say 'odd' since anyone _could_ resell them for commercial purposes under the
AGPL, yes?

It _also_ has "In other words, if you modify a Redis Labs Module source code,
the goal is that you have to contribute those modifications back to the
community."

So .. does AGPL really require contributions of modifications back to the
community, as both Redis and Mongo wrote? If so, that's quite at odds with the
GPL.

~~~
kemitchell
Folks almost universally understand licenses by reputation, rather than by
reading them. That's particularly understandable when it comes to AGPL, which
is terrible to read. By _reputation_ , AGPL is the "free for free software" or
"you must share back" license, even though that's not what it says.

The gap between reputation and reality afflicts both sides, developers and
users. So MongoDB had to spend a lot of time sending _users_ letters
reassuring them that they didn't have to release their app code, even though
they're commercial software companies making commercial apps with a (then)
AGPL database. And so Redis Labs, on the developer side, held AGPL out as
essentially noncommercial, and probably got away with it most of the time,
since many of their potential users and customers misunderstood AGPL the same
way they did.

Some confusion about licenses like AGPL can be exploited opportunistically,
and is. But much of that confusion arises quite without self-serving FUD, due
to interplay between industry realities and license terms. I blogged about
some of those recently, too:

[https://writing.kemitchell.com/2019/06/15/Industry-
Environme...](https://writing.kemitchell.com/2019/06/15/Industry-
Environment.html)

You're right that nothing in any GPL license _requires_ handing patches back
to developers as such. But in practice, they often function that way. By
giving users source code and a GPL license, you're giving users permission to
hand that source back to the developers. Often enough, that's exactly what
happens, especially now that the Web makes it so easy to do.

There's still some risk in confusing the practical effect of a license with
what it requires. But very well known developers and projects, like Linux, get
away with it, at least to some extent:

[https://youtu.be/1Mg5_gxNXTo?t=47m20s](https://youtu.be/1Mg5_gxNXTo?t=47m20s)

Linus is wrong in that video, when he says that GPL means "I give you source
code, you give me your changes back, we’re even." But being wrong isn't
costing him too much. Others using the same license are't so fortunate.

For more on patches back and the GPLs:

[https://writing.kemitchell.com/2018/08/28/Unhappy-
Coincidenc...](https://writing.kemitchell.com/2018/08/28/Unhappy-
Coincidences.html#software-freedom-doesnt-mean-patches-back)

