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

[Kyle Mitchell]

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.

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.

> > Conditions on preparation of derivative works and
> > distribution to the public---freedom 1 and freedom 3,
> > loosely---already lay a "minefield", but have not led to
> > license Ragnarok.  I concede that stronger copyleft
> > conditions on reproduction in copies incidental to
> > execution---freedom 0---and preparation of derivative works
> > without distribution---freedom 1 alone---will lay more
> > mines, as any stronger copyleft license does, to fill holes
> > in the intended defensive perimeter.  That makes copyleft
> > strategically effective for more kinds of software.  That's
> > true of network copyleft, which triggers on use, whether the
> > terms say "use" or not.
>
> I don't know of any approved "network" license which doesn't require
> modification of the original work as well in order to trigger.
> Certainly the AGPL requires it.  Which license are you thinking of?

Have a look at the definition of "External Deployment" in
OSL 3.0, for example.

> > Ask developers whether "free for open source" means free for
> > use on closed projects.  Ask them whether "free for open
> > source" itself counts as open source.  If they say "no",
> > tell them what copyleft is, and ask whether it can ever
> > count as open source.
>
> Speaking as someone who was a software developer for 20 years, you are
> quite mistaken.  The ability to utilize OSS tools in a non-modifying way
> on closed-source internal projects drives the entire economy of
> independent contract developers.  In fact, it was my original reason for
> getting involved in OSS in the first place; the nickle-and-dime
> marketplace of pay-$50-for-each-library-you-use sucked and prevented
> rapid development of solutions by small teams.  This is why I opposed
> your LicenseZero, because I believe it to be the death of sharing code
> for Javascript.  I know more JS developers who feel the same than agree
> with you.

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.

RMS goes on:

  Not everyone who uses the GNU GPL has this goal.  Many
  years ago, a friend of mine was asked to rerelease a
  copylefted program under noncopyleft terms, and he
  responded more or less like this:

    "Sometimes I work on free software, and sometimes I work
    on proprietary software---but when I work on proprietary
    software, I expect to get paid."

  He was willing to share his work with a community that
  shares software, but saw no reason to give a handout to a
  business making products that would be off-limits to our
  community.  His goal was different from mine, but he
  decided that the GNU GPL was useful for his goal too.

Strong copyleft licenses were written to deny the use of
free code to closed developers, to create a competitive
advantage for open developers.  It just so happens that
copyleft licenses---including Zero and now SSPL---work both
for that purpose, and as the basis of dual licensing plays.
Any license that excludes closed projects, for activist,
strategic, or business reasons, can also work as the public
license for a dual licensing play.

OSI has approved licenses for specific developers who very
clearly wanted to dual license.  And also for activists,
like FSF, that never intended to sell exceptions.  OSI has
also approved licenses that explicitly mention dual
licensing, like Artistic.

You don't need a license that triggers copyleft on dev-tool
use to exclude closed developers from using _any_ code in
closed projects.  You can already do that for some kinds of
code with old, approved copyleft licenses.  In the case of
front-end JavaScript in particular, even first-generation,
distribution-based copyleft licenses work swell, because
JavaScript gets distributed to site visitors with
app-specific code.

You _do_ need a stronger copyleft license to cover back-end
libraries.  The answer there is OSL, maybe RPL.  You _do_
need a stronger copyleft license to cover dev tools.  As far
as I know, that license didn't exist until Zero.  You _do_
need a stronger copyleft license to cover freestanding
back-end systems.  Like SSPL, at least in general approach.

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.

> When it comes right down to it, you are an attorney, and not a developer.

https://www.npmjs.com/~kemitchell

I was a 1099 web dev before law school.  Mostly content
management systems and educational multimedia.

I remain active in legal automation, like commonform.org,
publicdomainchronicle.org, and SPDX validation code and
utilities for for Node/npm and a small bit for RubyGems, as
well as browser-based peer-to-peer applications, like
proseline.com.  I wrote both the server (Node.js) and CLI
(Go) for License Zero.  The former is licensed on the
strong-copyleft terms that I wrote, without any offer to
sell exceptions.

None of that matters.

> 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.

All copyleft licenses that require work within the reach of
their copyleft rules to be licensed under the same terms
compound compatibility issues.  That has been true of every
new strong-copyleft license without a very generous and
explicit compatibility bridge, like we see with EPL 2.0.  It
was true of GPLv3, in the context of GPLv2.

> Where ragnarok kicks in is, imagine that there are several such
> extreme-copyleft licenses.  The SSPL, the ZZZPL, The PLPLPL.  So I want
> to analyze my GPLv3 code with an SSPL program, and then compile it using
> a PLPLPL program.  But I can't, not without creating a situation where
> the software can't be legally distributed at all.
>
> The winner, in such a situation, is proprietary software.  And that's
> directly against the mission of the OSI.

License incompatibility due to diverse copyleft licenses
approved by OSI already prevents useful combinations.

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.

Some folks don't want open to compete with closed,
especially at the ready-to-use application level.  But I
don't think it was OSI's consensus mission to relegate
openness to components, tools, or infrastructure in the
service of proprietary development, or to "deprecate"
copyleft for new work, going forward.

I do think it remains OSI's mission to encourage software to
be open.  The question copyleft poses is the extent to which
that can mean _requiring_ software to be open, through
intellectual property license terms, rather than merely
hoping it will be, or lobbying that it should be.

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