<div dir="ltr">On Thu, Jan 5, 2017 at 12:57 PM Richard Fontana <<a href="mailto:fontana@opensource.org">fontana@opensource.org</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As some know, NOSA 2.0 [1] has been languishing in a limbo review<br class="gmail_msg">
state for an extremely long time.<br class="gmail_msg">
<br class="gmail_msg">
In my opinion, NOSA 2.0 is, in its current form, an overly complex and<br class="gmail_msg">
badly drafted license. I cannot gain enough confidence that it meets<br class="gmail_msg">
the letter and spirit of the Open Source Definition, without<br class="gmail_msg">
substantial revision, which the license steward seems disinclined to<br class="gmail_msg">
undertake. This is just my view and does not reflect any sort of<br class="gmail_msg">
consensus view, although I am not sure one could really demonstrate a consensus view on the other side. (It should be noted that Luis Villa,<br class="gmail_msg">
a former OSI board member and one of my personal heroes,</blockquote><div><br></div><div>Hah! ;) <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> actually did recommend early on that the OSI approve NOSA 2.0, but this never went to a vote. [2])<br class="gmail_msg"></blockquote><div><br><div>I have not looked at NOSA in some time so I can't speak to how I'd think about that specific license today.<br></div><br></div><div>However, as some context to my previous push for approval: my sense was that, except in egregious cases, being poorly written and/or duplicative was sufficient to delay and push for improvements, but not (ultimately) to block adoption. In particular, since there was no political will to deprecate old licenses which did not meet "new" standards, I thought that the best route was to ultimately approve licenses that were professionally drafted, presented to OSI in good faith, and appeared to be in compliance with the OSD.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I later discovered that outright license rejection, though it seems to have been uncommon if it occurred at all in the past several years, was sometimes done earlier in the OSI's history.<br class="gmail_msg"></blockquote><div><br></div><div>I think rejection is perfectly appropriate for licenses that obviously violate the OSD or other <i>clear, written, (ideally) objective</i> OSI policies. However, the OSD is frequently ambiguous or vague (e.g., patent grant?), other rules are completely unwritten (e.g., quality standards), and others were never actually adopted as rules (e.g., non-proliferation report). Rejecting on any of those grounds is problematic.<br><br></div><div>Each of these have at least some fixes available (e.g., could address drafting by requiring professional legal involvement and/or a public drafting process). But ultimately any fixes must involve OSI saying "some OSD-compliant licenses are better than others", so unless the org indicates there is some stomach for that, I won't waste much time discussing the other fixes.<br><br></div><div>Luis<br></div></div></div>