[License-discuss] Evolving the License Review process for OSI

[Smith, McCoy]

>>From: License-discuss [mailto:license-discuss-bounces at lists.opensource.org] On Behalf Of Thorsten Glaser
>>Sent: Monday, June 3, 2019 8:01 AM
>>To: license-discuss at lists.opensource.org
>>Subject: Re: [License-discuss] Evolving the License Review process for OSI

>>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.

I think this can be a bit incongruous when there is a license on the list that by its text fails on or more of the OSD elements.  I believe there may be a few that do (I recall many years ago reading a few of the more obscure licenses and puzzling at how they met the OSD).  The problem with "grandfathering" such licenses is that they can be used as precedent for new license submitters as to why their non-OSD compliant licenses must also be approved.

>>If new findings occur with currently-approved licences that are not making it completely unusable, they ought to be kept, perhaps in a “grandfathered, problematic, actively derecommended for new works” category.

Per the observation above, might there also be room for a "grandfathered, non-OSD compliant, new works using this license are not Open Source" category?

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.