That is a fair concern, but I think it could be mitigated. As a threshold matter, the licenses I look at as being possibly worthy of de-classification don't seem to be wisely used. For those few affected, there could be a deprecation period, and some of them could be revised.
Thanks, Van __________________________ Van Lindberg [email protected] m: 214.364.7985 On Sat, Feb 8, 2020, 8:28 AM Pamela Chestek <[email protected]> wrote: > As suggested, moving to license-discuss. > > My concern with delisting is that someone will have relied on the approval > and it would be unfair, and a bad look for OSI, to suddenly pull the rug > out. > > Pam > > Pamela S. Chestek > Chestek Legal > PO Box 2492 > Raleigh, NC 27602 > [email protected] > 919-800-8033 > www.chesteklegal.com > On 2/7/20 5:04 PM, VanL wrote: > > With the mild proviso that this discussion really should be on > license-discuss, I also think a deprecation committee is a great idea. > > - Van > > On Fri, Feb 7, 2020 at 3:30 PM McCoy Smith <[email protected]> > <[email protected]> wrote: > >> *>>From:* License-review <[email protected]> *On >> Behalf Of *Richard Fontana >> *>>Sent:* Friday, February 7, 2020 1:12 PM >> *>>To:* Eric Schultz <[email protected]> >> *>>Cc:* License submissions for OSI review < >> [email protected]> >> *>>Subject:* Re: [License-review] For approval: The Cryptographic >> Autonomy License (Beta 4) >> >> >> >> >>I agree with this. I would feel better if the OSI had some process for >> reviewing and potentially delisting or at least deprecating approved >> licenses based on problematic experiences with a >>license that were not >> foreseeable at the time of approval. >> >> >> >> >>Richard >> >> >> >> I second the idea of a License Deprecation Committee, a la the License >> Proliferation Committee of ’04. In fact, you could make it a License >> Proliferation and Deprecation Committee to address both issues (assuming >> there are people who believe license proliferation is now a problem). >> >> >> >> Given that there have been existing licenses on the list that have been >> argued as precedent for recent submissions which were rejected or opposed, >> at a minimum there ought to be a serious look at some of the historical >> approvals to test whether those approvals would survive under current >> standards. I can think of at least one license currently on the list which >> I’ve looked at recently where I can’t justify it as consistent with the OSD >> (or at least my understanding thereof) or the approval process as currently >> run. That’s not a situation that I believe ought to exist and can play >> into the perception that OSI approval is inconsistent and/or arbitrary. >> _______________________________________________ >> License-review mailing list >> [email protected] >> >> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org >> > > _______________________________________________ > License-review mailing > [email protected]http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org > > _______________________________________________ > License-discuss mailing list > [email protected] > > http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org >
_______________________________________________ License-discuss mailing list [email protected] http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
