[License-review] OSD #9 would not make SSPL OSD-incompliant

[Kyle Mitchell]

On 2018-10-24 18:10, Josh Berkus wrote:
> On 10/24/2018 04:33 PM, Kyle Mitchell wrote:
> > On 2018-10-24 14:10, Josh Berkus wrote:
> >>>> This question is particularly important because there are a number of
> >>>> non-OSS licenses in the Javascript community that also make this claim
> >>>> (you test your code using my code, it's under my license). This is the
> >>>> reason why the FSF has been careful to define GPL licenses as not
> >>>> applying on mere use, since that's a minefield and will definitely lead
> >>>> to license ragnarok.
> >>>
> >>> I wrote at least one of the licenses I think you're alluding
> >>> to, and proposed an old version of it to OSI for review.  I
> >>> would be interested to learn of the others.
> >>
> >> Yes, and I critiqued that license for the same reasons.  However, ZRPL
> >> at least only requires the release of source code (under any terms),
> >> rather than licensing it under its own license, the way the SSPL does.
> >
> > I haven't done a specific review, but I'm not aware of any
> > other proposed or approved copyleft license that affords a
> > choice of terms for derivative works,
> > compatibility-relicense exceptions aside. In at least that
> > dimension, SSPLs run with the pack of copyleft licenses.
> > Zero stood apart.
>
> Yeah, we've had a few of these recently, and I'd like to see a
> choice-of-derivative-works license pass, because that feels very useful
> to me.

I wholeheartedly agree that it's a useful approach.
Fundamentally, it lets us write open-only licenses without
so high a compatibility-combinatorics cost.

Could I trouble you to point me some of the other licenses
proposing that kind of rule, apart from Zero?  It's entirely
possible I saw them, but hung up on other issues.

> > This begs a few important policy questions about specific
> > choices copyleft rules make, versus combinations of those
> > choices, but I'd rather address those in a structured way,
> > on the blog.
>
> Please link it when you do!

Will do.  I'm very tempted to paste in from the draft, but I
like what Van did, and how it was received.

> > The ability to utilize open code in closed projects is the
> > purpose of permissive licenses.  Strong copyleft licenses,
> > conversely, have always _prevented_ use of open code in
> > closed projects, by the most popular means for doing so in
> > their days.
> > RMS, in _Copyleft: pragmatic idealism_:
> >
> >   I make my code available for use in free software, and not
> >   for use in proprietary software, in order to encourage
> >   other people who write software to make it free as well.
> >   I figure that since proprietary software developers use
> >   copyright to stop us from sharing, we cooperators can use
> >   copyright to give other cooperators an advantage of their
> >   own: they can use our code.
> >
> > I don't think RMS would approve of SSPL.  But I think that's
> > because he sees his moral commitment to, and definition of,
> > software freedom as imposing a limit on how strong a
> > copyleft license he can use.
> >
> > Open source has always encompassed both permissive and
> > copyleft.  Asking folks who believe "free for open source"
> > isn't itself open source about copyleft more generally goes
> > to exactly this point.
>
> So I think we're getting split on two different definitions of closed
> projects.  There's "software I develop for myself and don't distribute
> or sell" and there's "software I develop for my/my company's own
> internal use".
>
> Historically, copyleft has been compatible with the latter.  The
> extension of copyleft into "mere use" makes it incompatible.  Surely
> there must be some way to address SAAS-as-distribution without doing so?

This almost came up between Bruce and I a few weeks ago on
this list, when I asked about whether OSI would mend the
schism with FSF on licenses that require contributing back
"private changes".

I think Bruce and I might agree that private-changes
licenses like old Plan 9, Watcom, and RPL closed the
loophole far more resiliently and effectively than
SaaS-as-distribution, without creating a line-drawing
problem about which uses trigger, and which don't.  Once you
draw such a line, it becomes, to some extent, gameable, like
other lines that copyleft rules have to draw.  It's worse in
a sense, since there aren't legal terms or concepts from
which to borrow clarity.

As for SSPL, Eliot and Mongo might argue that the loopholes
they're seeing exploited in AGPLv3 resulted from FSF's
position on private changes limiting how it could approach
section 13.  Hence their departure.

I like your distinction between personal and organizational
private changes.  It's not a distinction I believe FSF
makes.  There's possibly a distinction in copyright law,
since copyright covers "distribution to the public", and not
distribution in private, subject to confidentiality
controls, for various reasons having to do with the prior US
copyright law that the current Copyright Act replaced.  But
it may be that a copyright license can ignore all of that
for software, since even private distribution entails
reproducing in copies, which copyright controls, whether
public or private.

> > Why would open source cover licenses that effectively keep
> > closed developers away if "build with" means "ship a copy to
> > install and run" or "use to provide network service", but
> > not other kinds of "building with", so prevalent today?
> >
> > To be clear, I don't care to reopen the debate on Zero
> > specifically.  I am _very_ interested to reopen more general
> > policy questions that Zero posed, especially whether "open
> > source" limits copyleft, and if so, what those limits are,
> > and why.
>
> Yes, and I don't think that we can address the SSPL without addressing
> those questions.  Given that the same causes will keep coming up, we
> will keep seeing license proposals like these.

I agree.

> >> When it comes right down to it, you are an attorney, and not a developer.
> >
> > https://www.npmjs.com/~kemitchell
>
> Well played, sir, well played!  Indeed so.

Your developer opinion remains just as valid as mine.  And
neither of our opinions, based on personal experience, can
stand valid on their own, for the whole community.

I can't remember who taught me the mantra, but I try hard to
remind myself:  Nobody sees the whole open source community.
That's impossible.

> >> With the SSPL, I'm honestly less concerned about its effect on
> >> closed-source development (because MongoDB is already AGPL) and more
> >> concerned about its effect on other software licenses.  The SSPL as I
> >> read it is intended to be uber-viral, where anything that touches the
> >> SSPL code becomes itself SSPL-licensed, even if it was under a different
> >> OSS license.
> >>
> >> We are well-served by the current diversity of licenses in the
> >> ecosystem.  Attempts to create "one license to rule them all" are not
> >> something that the OSI should be endorsing.  Nor is certifying licenses
> >> designed out of the gate to create incompatibilities.
> >
> > Dev tool makers who want "free for free software" terms are
> > not well served.  Neither are back-end system makers like
> > Mongo, especially those who want terms that permit
> > combination in applications internally.
>
> Keep in mind that you're speaking to someone who spent 18 years working
> on PostgreSQL.  I remain unconvinced that stronger copyleft is required
> for database developers to have a business model.

Very fair point.  By many standards, Mongo itself has
already succeeded.  Very arguably the most important "open
source IPO" of the current cohort.  And Elastic filed.

I would back up, though, and ask not whether "free for free
software" is necessary to facilitate this-or-that business
model for one kind of project or another, but rather whether
"free for free software" licenses are open source software
licenses generally.  In other words, specific legal
implementations aside, does that functional specification
describe an "open source" license?  Do we have to talk in
terms of legal implementation details to express the limit
of open source copyleft?

The overall arc of strong-copyleft licensing seems to be:

1.  Write a license that's effectively free for open
    development, and unavailable to closed development.

2.  Accumulate useful software under those terms.

3.  Watch software fact and fashion change.

4.  Witness mounting incentives for pricey legal analysis
    and vulnerabilities created by change open up loopholes.

5.  Watch knowledge of the loopholes proliferate.

6.  Patch the license, with minimal diff, to close the new
    loophole.

7.  Fight for approval of the new license and relicensing of
    existing projects, debating numerous old, once
    apparently settled points before reaching the new
    substance, and enduring much drama all the while.

8.  If successful, see the new license bring available terms
    back into "free for open" spec.

Repeat.  And I would argue that a minimal diff in step 6
ensures the next repetition will come sooner.

> > But if OSI decides that "open source" means open developers
> > have to share dev tools and back-end services with
> > proprietary developers, that places a serious handicap on
> > open source development in competition with closed.  They
> > can use our best tools, but we can't use theirs.
>
> I understand this argument.  However, it's also true that no work of
> software is original; every bit of software written today depends on a
> large infrastructure of older software.  It's lovely to think of
> enforcing your "copyleft-on-steriods" license when you're the author,
> but far less exciting to think of the day in which you can find no
> complete toolchain that works for your OSS project because everything is
> under an incompatible, network-effect, license.
>
> *That* is what I call a handicap on open source development.

Absolutely.  There are other failure modes.  And their
analysis ends up feeling far more license-proliferation
problem than license-criteria problem.

If there's a saving grace, I think it's that top-down
analysis may be neither necessary nor particularly
desirable.  Network effects themselves produce
consolidation.  Those choosing licenses face incentives to
opt into large networks, even if the other applicable terms
don't suit their needs optimally.  But ill-fitting terms can
become their own onerous problem, at the other extreme.

I think an older blog post of mine is right on point here:

https://blog.licensezero.com/2018/05/13/commons-club.html

Especially from "Network" down.

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