[License-review] Approval: Server Side Public License, Version 2 (SSPL v2)

[Kyle Mitchell]

I very strongly disagree, overall.  But I also agree very
strongly on one specific point:

OSI ought to clarify the process.

Will it invent new procedural rules, slowing copyleft
license development with a de facto proving period of months
or years, at the feet of self-appointed authorities not OSI
itself, seemingly invented to stymie SSPL specifically?

Does current process afford opponents of any license,
including authors of prior licenses revised or implicitly
criticized by new submissions, indefinite filibuster, and
therefore effective veto?

Will OSI process or criteria discriminate, based on what
kind of person or group submits a license, such as whether
they're a foundation or a firm, or how they plan to use or
promote their proposed license?

Eliot mentioned very early on:

  If it is not what all communities want, then is it enough
  that some do?

http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-October/003672.html

We still don't know.  Which is another way of saying we
still don't know whether this process really wants to be
technical---conformance to OSD, discussion of how to revise
or supplement OSD, perhaps legal analysis---or to fall back
on the plainly political.  Or what that political process
may be.

On 2018-11-21 16:11, Bradley M. Kuhn wrote:
> Such a situation, of course, would have been an
> irrecoverable disaster for any normal inbound=outbound
> FLOSS project.

There's no community principle I'm aware of that FLOSS
projects _must_ follow inbound=outbound.  That certainly
isn't FOSS history.  Many popular and important projects do
not.  Organizations developing especially copyleft projects
have especially tended to take contributor license
agreements and even outright copyright assignments, as does
FSF.  Organizations developing permissive projects do, too.

OSD 3 makes clear that an open source copyleft license must
_allow_ derived works on the same open source terms.
Clearly, open source copyleft licenses can go further, and
_require_ the same terms.  I've written on this, and also my
view that open source copyleft licenses can _also_ allow
licensing on other open source licenses, here:

https://writing.kemitchell.com/2018/11/05/OSD-Copyleft-Regulation.html#allow-the-same-terms-for-derived-works

We're seeing some new flexibility there in SSPLv2.

> The only reason the situation *might* be salvageable here
> is that MongoDB is completely opposed to putting
> themselves on equal footing with their users; they refuse
> to even be bound by the terms of the SS Public License
> themselves.

How do you know?  I see two reasons to think not.

First, they've submitted the terms as a general form.  I
could use the same terms for my own project today.  If
MongoDB's engineers happen upon my work tomorrow, they'll
face the same question as every other potential licensee.
They may choose to use my SSPL code in systems they're ready
to make open source.

Second, their copyleft implementation will itself create
situations where MongoDB sees patches it might want to take
under SSPL.  SSPL doesn't mandate a CLA back to MongoDB. The
terms will govern their decision making, their rights to
software.  They are, after all, public license terms.

There's simply no requirement that license stewards or
licenses operate in perfect symmetry, IP-wise or otherwise,
or that projects eschew corporate centers of gravity,
for-profit or otherwise.  To use the terms above, did
Sleepycat ever intend to be bound by the Sleepycat license,
TrollTech by QFPL, or Technical Pursuit by RPL?  Did
Funambol intend to be bound by AGPL3?  All approved, and for
good reason.

> As an undergraduate in the early 1990s, one evening I was
> complaining to my roommate, Michael Tietjen, about the
> inefficiency of legislative bodies like the US Congress --
> arguing that so much time was wasted while nothing was
> accomplished. Tietjen countered with an excellent argument
> which immediately convinced me to change my position: no
> one should live in a society where the laws can change
> overnight; laws should be reasonably predictable by the
> populace to plan their lives.  Changes in laws need time
> to propagate before promulgation, so they're well
> understood before they are enacted.
>
> FLOSS licenses often serve as the de-facto laws of our
> community.

Laws apply to everyone, whether they opt in or not.  Those
who don't like SSPL can avoid having SSPL apply to them by
avoiding SSPL-licensed code.

Whole swathes of open source users and developers avoid
GPLv2 in this way.  GPLv2 is no law, as far as they're
concerned.

> Licensing changes to projects should be planned, discussed
> by all stakeholders as equals, and have ample time to
> gestate.  MongoDB has done the opposite here: whipsawing
> changes to actual legal terms of an actual project faster
> than the community can effectively digest them and plan.

If among "stakeholders" you include users of MongoDB,
stakeholders in MongoDB's database are anything but equal.
It's MongoDB's code.  The terms of their license are the
terms of their generosity.  Public licenses of the open sort
are by definition take-it-or-leave-it.

Perhaps I read too much into "changes to projects" here, but
I would emphatically reaffirm:  Software developers,
including companies that develop software, have the right to
license their own, original work on terms of their choice.
I happen to believe that they _should_ choose terms as open
as they can as often as they can.  A change from
_advocating_ open licensing to _demanding_ or pretending to
_dictate_ it would be ruinous.

> After doing so twice, MongoDB twice came asking OSI for a
> fast, post-hoc rubber stamp.

I believe I've read this a number of times now, here on
license-review.  I've seen no such demand in public
correspondence.  Did I miss a particular message?

v2 responds to comments I know I've seen here on
license-review.  And not on points where I recall MongoDB
soliciting feedback, initially.  That's rolling with the
process, not barreling through it.

> [1] It's been made clear by OSI officers that license-review is *not* a place
>     designed for license drafting work, but rather is for evaluation of
>     licenses that have already been through a thorough drafting process.

>From the process doc's submitter instructions:

  5.  Submit a formal request to license-review.  For new
      licenses, this should happen before they are finalized
      to allow for any necessary changes

https://opensource.org/approval

A great deal of back-and-forth on my submission requested
and weighed textual revisions.  The process actually
resulted in a blank-slate rewrite, inspiration for which I
remain grateful.  All the while, the complaints I heard were
that license-review made a poor revision-control system, and
commentators had trouble finding the most recent language.
Eliot has wisely batched up changes, and versioned each
revision so far.

If I've missed a recent announcement from OSI officers here
on license-review, please link it.  I follow as attentively
as I can, but a full-time law practice requires skimming
here and there.

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