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

[Kyle Mitchell]

On 2018-10-24 21:10, Brendan Hickey wrote:
> On Wed, Oct 24, 2018, 16:52 Kyle Mitchell <kyle at kemitchell.com> wrote:
> > 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.
>
> You're reaching here. While OSD 9 certainly protects distribution of other
> software, the enumeration of this freedom should not necessarily be
> construed to limit its scope. Even if Bruce never intended for the titles
> to be anything but merely descriptive, that ship has long since sailed. No
> one spoke up because we didn't think an example limited the principle.

OSD 9 fails to express the point.  And it doesn't express
any guidelines for reading beyond its text or between its
lines, either.  I agree with your earlier points to this
list on originalism and authorial privilege.

The past aside, now that the point is properly
front-and-center, there are folks ready to debate it.

A point on derivative works, below, is also relevant here.

> Again I'll point to Mongo's own explanation for why the SSPL compiles with
> OSD 9: "The SSPL does not place any restrictions on the use of any other
> software, only conditions." No one who thought #9 turned on distribution
> would make this argument. They would simply say, "Clause 13 does not rely
> on distribution, so OSD #9 isn't relevant." You might ask what difference
> it makes what Mongo thinks. In this case, they'd really prefer that OSD #9
> not apply. We have a sophisticated, motivated actor who is rejecting a
> narrow interpretation. That's some fairly strong evidence that people who
> have been paying attention didn't believe the explanatory text served to
> limit the scope of OSD 9. Besides, at the end of the day the board uses
> their judgement when deciding what to approve. They aren't beholden to a
> particular interpretation.

The Mongo folks can speak for themselves.

> > 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 protects software that does not constitute a derived work, be it
> proprietary or open. This principle delineates of the boundaries of open
> source licensing. Imposing restrictions on anything but derived works is a
> step too far. A compiler that legally encumbers its output might be nifty,
> but it ain't open source. (It's also a terrible idea for any number of
> practical reasons.)

I believe OSI was right to approve GPLv3, AGPLv3, and their
definitions of "Corresponding Source", which go beyond
copyright derivative works.  The thrust of GPLv3 copyleft
isn't legally but practically and ethically motivated.  If
derivative works alone don't afford freedom for the software
users receive, derivative works aren't enough.

> Keep in mind the OSD is not a license, it is not a
> contract, it is not a legal document even in the vaguest
> sense.

It's very apparent to me that OSD is not a legal document.

To exactly this point, it would be very strange for a
non-legal document to set the limit of copyleft reach with a
term defined by statute, and subject to case law
elaboration.  Especially without using "derived
work"---still not the statutory term "derivative work", but
appearing elsewhere in OSD---in OSD 9.  To say nothing of
"terms" or even "copyleft".

Hypothetically, the law could limit copyleft conditions to
derivative works.  So far, at least in the US, it hasn't.
There was some discussion about the legal doctrine of
copyright misuse.  I have the same doubts about that theory
expressed by others.

OSD isn't a legal opinion, either.  OSD could describe
licenses that the law does not permit.  It would fall on
drafters, not OSI, to satisfy both legal and OSD constraints
in written terms.

> Pretending that it's anything other than a manifesto is a
> mistake.  If there are holes in that manifesto, we should
> fix them rather than clinging forever to some particular
> embodiment of principles.

Again to your earlier points, the manifesto embodied a
shared understanding among more than just those involved in
its preparation or promulgation, either as DFSG or as OSD.

If you want to embody a new understanding, propose new
language.  Language limiting copyleft reach to derivative
works as defined by US copyright law will not achieve
consensus.  Both activist and business users of strong
copyleft licenses, as well as current users and maintainers
of software under licenses going beyond, will oppose.

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