[License-discuss] Retroactively disapproving licenses

[McCoy Smith]

> -----Original Message-----
> From: Nicholas Matthew Neft Weinstock <nweinsto at qti.qualcomm.com>
> Sent: Thursday, December 15, 2022 11:01 AM
> To: chris at dibona.com; license-discuss at lists.opensource.org;
> mccoy at lexpan.law
> Subject: RE: [License-discuss] Retroactively disapproving licenses
> 
> One of the parts of my job is reviewing commercial contracts.  Some of those
> contracts include references to Open Source.  For example, they might say
> something like "Supplier will provide a list of all 3rd party software included
> in the product that is under an Open Source License."  Or "Contractor may
> only use 3rd party code subject to an Open Source License, not Commercial
> or Freeware licenses."  In the majority of these contracts, the definition of an
> "Open Source License" references the list of OSI-Approved Licenses.  I think
> this is a good thing for OSI, as it enhances the organization's public image
> and influence.

I sort of feel like if you're using this sort of clause, and limiting it to only OSI-approved licenses, you're leaving a huge gap (compare the list of SPDX licenses to the OSI-approved licenses, for example).
Nevertheless, I can't see a justification for keeping a license on the list if it in fact it does not meet the OSD. And, as I think some have argued on the approval list before, it opens you up for the argument that "you approved this OSD-non-compliant license in the past, so you should approve *my* OSD-non-compliant license now."

> My suggestion is to think of the official list as a historical statement.  This is a
> list of licenses that OSI has ever approved.  Then within that list, maybe there
> could be a designation for licenses that the OSI board no longer supports.
> 
This has been at least one suggestion for how to deal with licenses that are non-compliant. My guess is that you'd do something like what has been done for deprecated licenses -- say past uses are grandfathered, but that future uses are not recommended, and that projects that have used licenses deemed non-compliant are strongly encouraged to change to a different, compliant, license.