<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><div class="">On Mon, Jun 3, 2019 at 11:32 AM Smith, McCoy <<a href="mailto:mccoy.smith@intel.com" class="">mccoy.smith@intel.com</a>> wrote:</div><div class=""><div class=""><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class="">[...] might there also be room for a "grandfathered, non-OSD compliant, new works using this license are not Open Source" category?<br class=""><br class="">I'd be interested in volunteering if there ever were a committee to review the current list to identify any listed licenses that do not (or might not) conform to the OSD.<br class=""></blockquote></div></div><div><br class=""></div>A potential starting point could be the 49 license spdx lists as being OSI-approved but not FSF-approved: <a href="https://spdx.org/licenses/" class="">https://spdx.org/licenses/</a></div><div><br class=""></div><div>Of course, some of those are simply licenses that haven’t undergone FSF review, but a good start regardless. It would be informative to see if there is a common reason where there are discrepancies as that likely will point to either a difference in “freedom” or process criteria. If the prior, that may help with annotating the OSD w.r.t. “software freedom” and the OSI.</div><div><br class=""></div><div>Cheers!</div><div>Sean</div><div><br class=""></div></div></body></html>