[License-review] For approval: The Cryptographic Autonomy License (Beta 4)
Pamela Chestek
pamela at chesteklegal.com
Sat Feb 8 14:26:10 UTC 2020
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
pamela at chesteklegal.com
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 <mccoy at lexpan.law> wrote:
>
> *>>From:* License-review
> <license-review-bounces at lists.opensource.org
> <mailto:license-review-bounces at lists.opensource.org>> *On Behalf
> Of *Richard Fontana
> *>>Sent:* Friday, February 7, 2020 1:12 PM
> *>>To:* Eric Schultz <eric at wwahammy.com <mailto:eric at wwahammy.com>>
> *>>Cc:* License submissions for OSI review
> <license-review at lists.opensource.org
> <mailto:license-review at lists.opensource.org>>
> *>>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
> License-review at lists.opensource.org
> <mailto:License-review at lists.opensource.org>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
>
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20200208/d3387671/attachment.html>
More information about the License-review
mailing list