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

Tue Nov 6 18:39:50 UTC 2018

Bruce Perens wrote:
> 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".

There is nothing wrong with profit. We pay our bills that way.

More important in the context of this OSI list, it is the licensee rather than the licensor who requires that "profitleft" model. If (e.g.) Alphabet/Google would allow some more of their online software to be shared under network copyleft principles, that would perhaps mean more free software. In the meantime, while the big network companies are afraid to share this way, network copyleft is a profitable FOSS license model for underpaid developers.

And the software is still FOSS! That is a good business model.

/Larry

From: License-review <license-review-bounces at lists.opensource.org> On Behalf Of Bruce Perens
Sent: Monday, November 5, 2018 8:39 PM
To: License submissions for OSI review <license-review at lists.opensource.org>
Subject: Re: [License-review] Approval: Server Side Public License, Version 1 (SSPL v1)

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 <mailto: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 <mailto: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 <mailto: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 <http://wwahammy.com> 
eric at wwahammy.com <mailto:eric at wwahammy.com> 
@wwahammy
Pronouns: He/his/him

_______________________________________________
License-review mailing list
License-review at lists.opensource.org <mailto: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/20181106/fa42f3ca/attachment-0001.html>