<div dir="ltr"><div>It's nice that the purpose is acknowledged to be "software freedom". However, people wanting a programatic definition of that will be disappointed.</div><div><br></div><div>    Thanks</div><div><br></div><div>    Bruce<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 6, 2018 at 9:41 PM Richard Fontana <<a href="mailto:richard.fontana@opensource.org">richard.fontana@opensource.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">At a recent meeting, the OSI Board discussed requests to clarify the<br>
license approval process (documented at<br>
<a href="https://opensource.org/approval" rel="noreferrer" target="_blank">https://opensource.org/approval</a>). We've drafted the guidelines below,<br>
which we aim to follow when reviewing licenses, to ensure that a<br>
license will be approved only if it conforms to the Open Source<br>
Definition and provides software freedom.<br>
<br>
"Decision Date" for a license normally means (a) 60 days after a<br>
license is initially submitted for review, and (b) 30 days after<br>
submission of a revised version of a license that was previously<br>
submitted for review. A license is considered to be submitted for<br>
review if it follows the process set forth at<br>
<a href="https://opensource.org/approval" rel="noreferrer" target="_blank">https://opensource.org/approval</a>. While we will try our best to adhere<br>
strictly to this 60/30 day Decision Date definition, circumstances may<br>
require us to extend the Decision Date further.<br>
<br>
On the Decision Date, the OSI will announce one of four possible decisions:<br>
<br>
1. Defer for another 30-day discussion cycle, if community discussion<br>
of conformance of the license to the OSD remains active<br>
<br>
2. Approve, if (a) there is sufficient consensus emerging from<br>
community discussion that approval is justified, and (b) the OSI<br>
determines that the license conforms to the Open Source Definition and<br>
guarantees software freedom<br>
<br>
3. Reject if (a) the OSI determines that the license cannot<br>
practically be remedied to adequately guarantee software freedom, or<br>
(b) there is sufficient consensus emerging from community discussion<br>
that the license should be rejected for substantive reasons, or (c)<br>
the license is problematic for nonsubstantive reasons (for example, it<br>
is poorly drafted or significantly duplicative of one or more existing<br>
OSI-approved licenses)<br>
<br>
4. Withhold approval, if (a) the OSI determines that approval would<br>
require reworking the license and (b) the license submitter appears<br>
willing and able to revise the license constructively<br>
<br>
We would appreciate your comments.<br>
<br>
- Richard<br>
<br>
_______________________________________________<br>
License-discuss mailing list<br>
<a href="mailto:License-discuss@lists.opensource.org" target="_blank">License-discuss@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br>
</blockquote></div>