>>From: Simon Phipps <simon.phi...@opensource.org> >>Sent: Monday, February 24, 2020 10:09 AM >>To: McCoy Smith <mc...@lexpan.law>; license-discuss@lists.opensource.org >>Subject: Re: [License-discuss] "Fairness" vs. mission objectives
>>Note that we already accept requests from the license steward to deprecate a >>license, either because they consider it no longer appropriate (as I myself >>did for the SISSL a decade or so ago) or because it has been superceded. This >>conveys a clear message that the license should not be used for new uses, >>without harming legacy applications (which are indeed often minimal). Yes, voluntary deprecation has been around for a while (I’ve done it on behalf of my former employer as well). But is somewhat dependent on the maintainer to appreciate the value of deprecation to the community vs their own interests in keeping their license in a non-deprecated, OSI-approved, state. >>What I'd propose here is that we explore a process for deprecation of >>licenses by someone other than the license steward. Maybe it would start >>with a substantiated request endorsed by several regular list members, and >>then follow the same discussion-followed-by-committee-review process as >>approval. The decision to involuntarily deprecate a license would then >>finally be reviewed by the Board. I think that is a logical next step. If you’re going to do it, I think for the sake of completeness and transparency, you should start with licenses where there is a clear and agreed-to non-conformance with the OSD, and the notification to the steward points that out and the license steward gets a chance to respond (including possibly doing a rev to take out the problematic part, and list the problematic license as superseded – as many licenses have done in the past – or also just agreeing to the deprecation).
_______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
