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

[Kyle Mitchell]

On 2018-10-24 11:10, Josh Berkus wrote:
> On 10/23/2018 01:57 PM, Brendan Hickey wrote:
> > Bruce,
> >
> > While your intent is worth considering, we needn't fall into the trap of
> > originalism. The OSD as promulgated over the past twenty or so years
> > doesn't specify that the titles are merely descriptive. With the passage
> > of time so too passes any authorial privilege.
> >
> > McCoy's understanding of the text as providing examples rather than
> > limitations hardly seems implausible. For my own part, I understood the
> > OSD headings as statements of principle with the text serving as dicta.
> > In the case of OSD #9, the text calls out mere aggregates while leaving
> > out non-derivative works.
>
> Agreed.  The spirit of the rule is well-encapsulated by the title.

For reasons I'll address shortly, with more structure, in a
promised blog post, I strongly disagree.  That is to say, I
agree with Bruce's assessment that OSD 9 simply doesn't
address the issue.

OSD 9 clearly protects distributors from license compliance
troubles triggered "in transit".  In that, it's comparable
to hazardous material shipping regulations for common mail
and cargo carriers, which resonates with the metaphor in the
DFSG heading: "contamination".  In effect, it shields the
volunteer and commercial distributors Debian relies upon to
this day, and those who followed their lead for other
communities.

Being clear from the text, OSD 9 supports a claim of
consensus on that point.  Anyone who objected to that
meaning would have known to speak up.

OSD 9's language is _not_ a clear protection for proprietary
software producers from copyleft.  Some might like it to be,
and to replace "other software" with something more
administrable.  Some might like to add more examples, to
stretch the text that's already there.

OSD 9's current language can't support a claim of consensus
for what some would choose to read or put into it.  That is
where we stand now.

> Where I find SSPL to violate OSD9 isn't so much cloud services, but the
> assertion that the SSPL applies to 3rd-party code tested, debugged, or
> packaged using SSPL code.   While that's not "distributing with" it's
> definitely "applies to other software".
>
> 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.

I wrote the license I did to make copyleft effective for
kinds of software that developers happen to run to build
other software, rather than extend or distribute to build
other software.  In other words, developer tools.  I'm very
aware that FSF has consciously avoided that outcome, notably
via libgcc, though for reasons I still can't quite square
with other FSF writing on popularity and compromise.

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.

Inevitability of license Ragnarok on account of that
implementation detail is a hard case to make, given that
history.  Developers grok plenty well what "free for open
source" means.  They're surprised, if at all, only by the
fact that such a license is possible without the
self-imposed freedom- or 106-based complexity of past
copyleft licenses, developed over time by accretion of
specific conditions and loophole closures, rather than by
addressing the intended effect top-down, from a clean slate.

> I propose that we update OSD9 with these additional examples.

I oppose.

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.

The Free Software Foundation has long self-regulated its
copyleft implementations, to avoid falling afoul of
doctrinal prohibitions from its definition of software
freedom, notably private changes ("freedom 4") and at least
a rhetorical commitment to freedom 0 absolutism.  The
resulting licenses have suited the purposes of activists who
accept the FSF's doctrine as received.  They've also been
imperfectly repurposed by activists who reject FSF
compromises, and by developers and business firms driving
bargains for patches back, denying work to competitors,
benefiting the open community in competition with
proprietary software, and facilitating dual licensing plays.

OSI has approved licenses from other copyleft user
communities, drafted for their purposes, rather than FSF's,
and ignoring limits FSF imposes on itself.  Those who prefer
FSF's more stringent self-regulation can look to its list of
approved licenses, or apply the Rule of Three.  But I would
argue, as others have here, that FSF self-regulation of
copyleft handicaps its ability to respond to software
services and network APIs, among other developments.  Those
other developments matter a great deal to the rest of the
copyleft license user community.

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