<div dir="ltr">I don't really see that this is discussion of SSPL. Please move it to the discussion list instead of license review.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 24, 2018 at 10:31 PM Kyle Mitchell <<a href="mailto:kyle@kemitchell.com">kyle@kemitchell.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-10-24 21:10, Brendan Hickey wrote:<br>
> On Wed, Oct 24, 2018, 16:52 Kyle Mitchell <<a href="mailto:kyle@kemitchell.com" target="_blank">kyle@kemitchell.com</a>> wrote:<br>
> > OSD 9 clearly protects distributors from license compliance<br>
> > troubles triggered "in transit". In that, it's comparable<br>
> > to hazardous material shipping regulations for common mail<br>
> > and cargo carriers, which resonates with the metaphor in the<br>
> > DFSG heading: "contamination". In effect, it shields the<br>
> > volunteer and commercial distributors Debian relies upon to<br>
> > this day, and those who followed their lead for other<br>
> > communities.<br>
><br>
> > Being clear from the text, OSD 9 supports a claim of<br>
> > consensus on that point. Anyone who objected to that<br>
> > meaning would have known to speak up.<br>
><br>
> You're reaching here. While OSD 9 certainly protects distribution of other<br>
> software, the enumeration of this freedom should not necessarily be<br>
> construed to limit its scope. Even if Bruce never intended for the titles<br>
> to be anything but merely descriptive, that ship has long since sailed. No<br>
> one spoke up because we didn't think an example limited the principle.<br>
<br>
OSD 9 fails to express the point. And it doesn't express<br>
any guidelines for reading beyond its text or between its<br>
lines, either. I agree with your earlier points to this<br>
list on originalism and authorial privilege.<br>
<br>
The past aside, now that the point is properly<br>
front-and-center, there are folks ready to debate it.<br>
<br>
A point on derivative works, below, is also relevant here.<br>
<br>
> Again I'll point to Mongo's own explanation for why the SSPL compiles with<br>
> OSD 9: "The SSPL does not place any restrictions on the use of any other<br>
> software, only conditions." No one who thought #9 turned on distribution<br>
> would make this argument. They would simply say, "Clause 13 does not rely<br>
> on distribution, so OSD #9 isn't relevant." You might ask what difference<br>
> it makes what Mongo thinks. In this case, they'd really prefer that OSD #9<br>
> not apply. We have a sophisticated, motivated actor who is rejecting a<br>
> narrow interpretation. That's some fairly strong evidence that people who<br>
> have been paying attention didn't believe the explanatory text served to<br>
> limit the scope of OSD 9. Besides, at the end of the day the board uses<br>
> their judgement when deciding what to approve. They aren't beholden to a<br>
> particular interpretation.<br>
<br>
The Mongo folks can speak for themselves.<br>
<br>
> > OSD 9's language is _not_ a clear protection for proprietary<br>
> > software producers from copyleft. Some might like it to be,<br>
> > and to replace "other software" with something more<br>
> > administrable. Some might like to add more examples, to<br>
> > stretch the text that's already there.<br>
> ><br>
><br>
> OSD 9 protects software that does not constitute a derived work, be it<br>
> proprietary or open. This principle delineates of the boundaries of open<br>
> source licensing. Imposing restrictions on anything but derived works is a<br>
> step too far. A compiler that legally encumbers its output might be nifty,<br>
> but it ain't open source. (It's also a terrible idea for any number of<br>
> practical reasons.)<br>
<br>
I believe OSI was right to approve GPLv3, AGPLv3, and their<br>
definitions of "Corresponding Source", which go beyond<br>
copyright derivative works. The thrust of GPLv3 copyleft<br>
isn't legally but practically and ethically motivated. If<br>
derivative works alone don't afford freedom for the software<br>
users receive, derivative works aren't enough.<br>
<br>
> Keep in mind the OSD is not a license, it is not a<br>
> contract, it is not a legal document even in the vaguest<br>
> sense.<br>
<br>
It's very apparent to me that OSD is not a legal document.<br>
<br>
To exactly this point, it would be very strange for a<br>
non-legal document to set the limit of copyleft reach with a<br>
term defined by statute, and subject to case law<br>
elaboration. Especially without using "derived<br>
work"---still not the statutory term "derivative work", but<br>
appearing elsewhere in OSD---in OSD 9. To say nothing of<br>
"terms" or even "copyleft".<br>
<br>
Hypothetically, the law could limit copyleft conditions to<br>
derivative works. So far, at least in the US, it hasn't.<br>
There was some discussion about the legal doctrine of<br>
copyright misuse. I have the same doubts about that theory<br>
expressed by others.<br>
<br>
OSD isn't a legal opinion, either. OSD could describe<br>
licenses that the law does not permit. It would fall on<br>
drafters, not OSI, to satisfy both legal and OSD constraints<br>
in written terms.<br>
<br>
> Pretending that it's anything other than a manifesto is a<br>
> mistake. If there are holes in that manifesto, we should<br>
> fix them rather than clinging forever to some particular<br>
> embodiment of principles.<br>
<br>
Again to your earlier points, the manifesto embodied a<br>
shared understanding among more than just those involved in<br>
its preparation or promulgation, either as DFSG or as OSD.<br>
<br>
If you want to embody a new understanding, propose new<br>
language. Language limiting copyleft reach to derivative<br>
works as defined by US copyright law will not achieve<br>
consensus. Both activist and business users of strong<br>
copyleft licenses, as well as current users and maintainers<br>
of software under licenses going beyond, will oppose.<br>
<br>
-- <br>
Kyle Mitchell, attorney // Oakland // (510) 712 - 0933<br>
<br>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div>