(Comment below, I've heavily edited to focus in, please read earlier portions of the thread for context)
On Sunday, March 29, 2020 2:06 PM, Henrik Ingo wrote: On Fri, Mar 27, 2020 at 10:22 PM Josh Berkus <[email protected] < Caution-mailto:[email protected] > > wrote: 1. license does not in fact conform to the OSD (was erroneously approved) 2. does not appear to be used for any currently available/working software *and is redundant with more popular licenses* (added condition mine). I would like to postpone the activity on #2. Let's first focus on licenses that have actual problems. Arguably, if a license isn't being used anyway, it cannot be an urgent problem. I'd actually argue the opposite; let's survey the currently approved licenses to gather all that do not conform to the OSD first, then sort those from least used to most used, and deal with them in that order. This is advantageous for at least the following reasons: 1. This is a new process; we're likely to make mistakes while executing it, or will discover that the idea of decertification itself is flawed. Let's contain the damage as far as possible during the learning phase. 2. We keep hearing about 'license proliferation'. Focusing in on the rarely used 'bad' licenses will help with this. Note that I believe that the process should only be about licenses that don't conform to the OSD; using it as an excuse for pruning back licenses due to license proliferation concerns is a terrible abuse of OSI's power. I personally believe that because of how complex the law is (more so due to varying jurisdictions) and due to the fact that the law is constantly changing, there will always be a need for new licenses. Thus, for any license that is proposed for decertification we should be able to clearly articulate which of the OSD principles are being violated, and how they are violated by the license. This reasoning should be annotated to the license in a clearly discoverable manner (e.g., each license has its own page), with very specific explanations of which license clauses are in violation of the OSD, and why. This acts as both a historical record of the reasoning, and a guide to others that wish to create new licenses of what not to do in their own language. Thanks, Cem Karan
_______________________________________________ The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Official statements by the Open Source Initiative will be sent from an opensource.org email address. License-discuss mailing list [email protected] http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
