<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=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jun 3, 2019, at 11:00 AM, Thorsten Glaser <<a href="mailto:tg@mirbsd.de" class="">tg@mirbsd.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I don’t think the current OSD bad. It’s common to have interpretation<br class="">aids without needing to completely change the rules.<br class=""></div></div></blockquote><div><br class=""></div>Arguably that is, should be, or could be what <a href="https://opensource.org/osd-annotated" class="">https://opensource.org/osd-annotated</a> is for already.</div><div> </div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">I would suggest that this process be followed up with a re-review of<br class="">licenses which were historically approved, but that don't fit within<br class="">community values. It will always seem arbitrary if a new license is<br class="">rejected based on a problem that applies to an existing approved license.<br class=""></blockquote><br class="">It will, but I feel strongly that disapproving licences that were<br class="">once approved and where fine, according to understanding (OSD and<br class="">community) back then (and where no bad things occurred during or<br class="">to force the approval) will be problematic; many people rely on<br class="">the OSI label, and changing the licence of an existing project is<br class="">an exercise in futility. (That being said, some FSF licences might<br class="">not survive this, either… I’m not a fan of those myself, but they<br class="">have their place.) Many people operate under the assumption that<br class="">a once-approved licence, approved under good faith, will not be<br class="">disapproved later.<br class=""></div></div></blockquote><div><br class=""></div><div>Implications of revocation should be considered carefully as I also believe it could easily do more harm than good. That’s not to say that there isn't room to better categorize and/or tag licenses beyond the 9 currently at <a href="https://opensource.org/licenses/category" class="">https://opensource.org/licenses/category</a> </div><div><br class=""></div><div>One minimal step might be to expand “Licenses that have been voluntarily retired” to “Voluntarily retired and / or not recommended for use licenses”, and having a process defined for actively expressing a desire that a particular OSS-approved license not be used. These along with “Superseded licenses” should be the listed last on the page, probably with an explanation.</div><div><br class=""></div><div>On that note, “Other/Miscellaneous licenses” and “Uncategorized Licenses (sic)” should be combined as currently presented. It would also seem to me that the list would be better served with tags instead of top-level categories as there are not necessarily mutually exclusive properties.</div><div><br class=""></div><div>Cheers!</div><div>Sean</div><div><br class=""></div></div></body></html>