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

Tue Nov 6 04:38:46 UTC 2018

It really comes down to a question of freedom vs. profit. Some are calling
this "network copyleft", but the proposals I've seen go against the
principles behind copyleft. So I think we should call them "network
profitleft". The point is to sacrifice some freedom (IMO really quite a
lot) in the name of enabling a business method, so that developers can
profit from a dual-licensing scheme on software that is likely to be used
by cloud services. Profit is not evil. Nor is it an overriding good, and
thus we aren't required to support every business method that comes along.
Freedom is the basis of Open Source and we should thus deny the SSPLv1 for
giving up crucial freedoms, but everyone is free to use the license as long
as they don't claim that it's Open Source.

    Thanks

    Bruce

On Mon, Nov 5, 2018 at 8:02 PM Eric Schultz <eric at wwahammy.com> wrote:

> 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
>
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20181105/06240008/attachment-0001.html>