<div dir="ltr"><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><span style="font-size:16px">But for God's sake don't tell the open software community,<br></span><span style="font-size:16px">of all people, that their identity's defined by an opaque,<br></span><span style="font-size:16px">bureaucratic rite on a mailing list, overtly camouflaging an<br></span><span style="font-size:16px">arbitrary decision process that can't be changed, no matter<br></span><span style="font-size:16px">how frustrating it may be. I couldn't defend that. I don't<br></span><span style="font-size:16px">know anyone my age or younger who'd want to try.<br><br></span></blockquote><img class="gmail-ajT" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif" style="font-size: 16px; opacity: 0.3;">This is overstated. The OSI board has usually discussed on this public list the reasons for rejection, when there are practical reasons for rejection that are not explicitly stated in the OSD. The reasons I just set down are not put forth as an addition to the OSD, just a statement of what some perfectly reasonable concerns should be. I think we can develop such a list without ever insisting that it be made a modification to the OSD, and also without insisting that the OSI board limit themselves to a programatic interpetation of the OSD.<br><div><br></div><div> Thanks</div><div><br></div><div> Bruce</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 19, 2017 at 9:09 PM, Kyle Mitchell <span dir="ltr"><<a href="mailto:kyle@kemitchell.com" target="_blank">kyle@kemitchell.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2017-10-19 22:10, John Cowan wrote:<br>
> On Thu, Oct 19, 2017 at 7:58 PM, Kyle Mitchell <<a href="mailto:kyle@kemitchell.com">kyle@kemitchell.com</a>> wrote:<br>
> > Might I ask what those policy grounds are?<br>
> ><br>
> > A number of folks, on the list and off, have mentioned<br>
> > policy considerations separate from OSD conformance. Not<br>
> > everyone seems to agree OSI should do more than apply OSD,<br>
> > but in conversation with most of those who do, I'm at a<br>
> > loss. There doesn't seem to be any document setting out<br>
> > what OSI's additional policy constraints are, or what, if<br>
> > any, relationship they have to OSD itself.<br>
> ><br>
><br>
> That's deliberate. Jurisprudentially, the OSD is in the nature of a code,<br>
> but OSI's (self-assumed) jurisdiction is in the nature of equity: it<br>
> approves licenses based on what the Board members believe to be right and<br>
> just. Licenses that violate the code will not be adopted (although in some<br>
> cases licenses have been approved that on some readings don't agree with<br>
> it), but there is no guarantee that licenses that conform to the code will<br>
> be adopted. This is a fact about how OSI operates, and while it may be<br>
> frustrating, there is nothing you or anyone else can do about it.<br>
<br>
</span>Good to hear from you again, John.<br>
<br>
Two thoughts here, one concrete and one more general:<br>
<br>
First, if this is indeed a fact of how OSI operates, it<br>
ought to say so publicly, on <a href="https://opensource.org/approval" rel="noreferrer" target="_blank">https://opensource.org/<wbr>approval</a><br>
and elsewhere. And it ought to be careful that "right and<br>
just", however defined, color well within the lines of its<br>
nonprofit and tax-exempt statuses, its stated mission. The<br>
obvious prescription there is legal advice and transparency,<br>
in that order, and in appropriately measured quantities.<br>
<br>
I come in peace, in admiration for OSI and what it's<br>
achieved. That's why I bothered in the first place. If OSI<br>
needs to press pause on this process to look after that<br>
weightier one, so be it. But OSI cannot and should not<br>
become a closet (c)(6) that _defines_ Open Source to include<br>
values-forward, copyleft-empowered community spirit, while<br>
in practice _approving_ only terms that certain kinds or<br>
sizes of business players, users, or constituents prefer.<br>
<br>
Second, as a practical matter, law and equity merged long<br>
ago, both in England and in the United States. The old<br>
maxims of equity still float around, show up in court<br>
opinions now and then, because they're fun and sound<br>
prestigious. But it's long left legal propriety to glance<br>
over rule by men, rather than by laws, under the cover of<br>
vague, discretionary fallbacks kept intentionally vague. We<br>
expect written opinions and adherence to precedent on equity<br>
matters, too. It's that transparency thing again.<br>
<br>
On a practical level, you're absolutely right. If L0-R ends<br>
up OSD-conformant, but not OSI approved, there will be<br>
little I can do about it but point back to this<br>
license-review thread, and admit that I myself tried and<br>
failed to suss out the difference. I don't want to end up<br>
there. It's bad enough telling the folks who<br>
enthusiastically share L0's _noncommercial_ option as a<br>
solution to "open source sustainability" that they should<br>
read <a href="http://opensource.org" rel="noreferrer" target="_blank">opensource.org</a> and mind their capitalization.<br>
<br>
If the Definition needs to be refined or amended, let's<br>
start that project. I'll chip in. If OSI needs a<br>
living-document statement of additional policies and values<br>
to uphold in its approval process, I'll help there, too.<br>
Even if it ends up cutting L0-R out.<br>
<br>
But for God's sake don't tell the open software community,<br>
of all people, that their identity's defined by an opaque,<br>
bureaucratic rite on a mailing list, overtly camouflaging an<br>
arbitrary decision process that can't be changed, no matter<br>
how frustrating it may be. I couldn't defend that. I don't<br>
know anyone my age or younger who'd want to try.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Kyle Mitchell, attorney // Oakland // <a href="tel:%28510%29%20712%20-%200933" value="+15107120933">(510) 712 - 0933</a><br>
______________________________<wbr>_________________<br>
License-review mailing list<br>
<a href="mailto:License-review@opensource.org">License-review@opensource.org</a><br>
<a href="https://lists.opensource.org/cgi-bin/mailman/listinfo/license-review" rel="noreferrer" target="_blank">https://lists.opensource.org/<wbr>cgi-bin/mailman/listinfo/<wbr>license-review</a><br>
</div></div></blockquote></div><br></div>