> On Jun 3, 2019, at 11:00 AM, Thorsten Glaser <t...@mirbsd.de> wrote: > > I don’t think the current OSD bad. It’s common to have interpretation > aids without needing to completely change the rules.
Arguably that is, should be, or could be what https://opensource.org/osd-annotated <https://opensource.org/osd-annotated> is for already. >> I would suggest that this process be followed up with a re-review of >> licenses which were historically approved, but that don't fit within >> community values. It will always seem arbitrary if a new license is >> rejected based on a problem that applies to an existing approved license. > > It will, but I feel strongly that disapproving licences that were > once approved and where fine, according to understanding (OSD and > community) back then (and where no bad things occurred during or > to force the approval) will be problematic; many people rely on > the OSI label, and changing the licence of an existing project is > an exercise in futility. (That being said, some FSF licences might > not survive this, either… I’m not a fan of those myself, but they > have their place.) Many people operate under the assumption that > a once-approved licence, approved under good faith, will not be > disapproved later. 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 https://opensource.org/licenses/category <https://opensource.org/licenses/category> 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. 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. Cheers! Sean
_______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
