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

[Eric Schultz]

I find this argument unconvincing and the result patently against the
plain understanding of the OSD.

If SSPL is to be accepted, that means that you can incorporate
restrictions and requirements into network implicated copyleft that
you could never add to copyleft based on distribution. It's a loophole
that allows everything that the OSD and FSD were intended prevent. All
a person has to do is say your copyleft applies to networks and then
you can say something like "if you use this and your company provides
abortion coverage to employees, you must provide the entire source
code to all the software you use to everyone in the world." One could
claim "that's so different; we're only talking about cloud computing!"
but I'm wholly unconvinced there is a logical difference between the
two as it applies to the OSD. I believe you can smuggle any offensive,
oppressive restriction in as long as you say "but it only applies if
you put it on a network" if the SSPL is accepted.

Maybe someone is okay with exploring these restrictions but I'm not.
This license should be withdrawn and/or rejected.

Eric
On Mon, Nov 5, 2018 at 9:02 PM Kyle Mitchell <kyle at kemitchell.com> wrote:
>
> As promised, my stab at a systematic review of OSD criteria
> for rules regulating the design of copyleft terms:
>
> https://writing.kemitchell.com/2018/11/05/OSD-Copyleft-Regulation.html
>
> I believe SSPLv1 conforms.  It does nothing the Definition
> prohibits.  But on the points that make SSPL interesting,
> that may say more about the Definition than the license.
>
> I limited my review to the text of OSD, comparisons to DFSG,
> historical context, and license approvals.  Criteria 3, 8,
> and 10 express clear limits on copyleft design.  Criteria 1,
> 5, 6, and 9 set limits if we start with limits to set,
> assume invariantly that they _have_ to go somewhere in OSD,
> and resolve to do what's necessary to available text to get
> them there.
>
> A fair reading of the Definition doesn't set any closed
> boundary for copyleft within open source.  For example, it
> doesn't clearly address when copyleft can trigger, or what
> code it can reach.  Given its age, its context, and its
> purpose in its time, expecting clear answers to questions
> that hadn't really been asked yet is unfair to those who
> wrote, reviewed, and approved the Definition.  Given the
> novelty of the issues, twenty years of developments, and the
> talent now assembled, it's also unfair to pretend OSD
> authoritatively means more than it transparently says,
> precluding present-tense debate.
>
> I'd venture to say most everyone agrees there _should_ be
> effective limits on open source copyleft.  Discussion of
> where they should lie will remain needlessly difficult, to
> read and to write, so long as every point has to be
> force-fit between OSD's lines.  For the sake of debate, I'd
> rather acknowledge, collectively, that OSD criteria describe
> very strong, even uncomfortably strong copyleft licenses,
> that we've very good reasons to keep debating beyond
> established conformance, but that we're invoking undefined
> behavior by doing so.  Let's address transparently what
> additional criteria or process OSI will apply, and think on
> how to message them.
>
> Beyond a few drafting points, I hold one substantial
> reservation about SSPLv1, in the "offering ... primary
> purpose" item of the disjunction at the end of the first
> paragraph of section 13.  I have my reasons.  But I can only
> read them _into_ OSD with purpose.  I can't read them _out_
> of OSD with objectivity.  I'd rather just write what I think,
> as best I can write it.  But that's a contribution to chaos,
> unless that kind of input leads somewhere.
>
> As a final SSPL-specific note, I agree that SSPL meets
> criteria 5, 6, and 9, but not for the reason given in the
> SSPL FAQ.  As I describe more fully in the section of my
> post linked below, I find it hard to read either a
> licensing-jargon or a legal distinction between
> "restriction" and "condition" into OSD.  I think it's
> perfectly possible, and natural, to read those criteria to
> miss copyleft entirely, rather than to regulate copyleft,
> but only when its rules are structured or styled as
> "restrictions".
>
> https://writing.kemitchell.com/2018/11/05/OSD-Copyleft-Regulation.html#restriction-versus-condition
>
> --
> Kyle Mitchell, attorney // Oakland // (510) 712 - 0933
>
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org



-- 
Eric Schultz, Developer and FLOSS Advocate
wwahammy.com
eric at wwahammy.com
@wwahammy
Pronouns: He/his/him