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

Thu Oct 25 06:16:20 UTC 2018

I don't really see that this is discussion of SSPL. Please move it to the
discussion list instead of license review.

On Wed, Oct 24, 2018 at 10:31 PM Kyle Mitchell <kyle at kemitchell.com> wrote:

> 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
>
> _______________________________________________
> License-review mailing list
> 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/20181024/114b08d3/attachment-0001.html>