<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" id="owaParaStyle"></style>
</head>
<body fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">(Comment below, I've heavily edited to focus in, please read earlier portions of the thread for context)<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<div><br>
</div>
<div style="font-family:Tahoma; font-size:13px"></div>
</div>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px"><font size="2" face="Tahoma" color="#000000"><b><br>
</b></font></div>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px"><font size="2" face="Tahoma" color="#000000">On
</font><font size="2" face="Tahoma" color="#000000"><font size="2" face="Tahoma" color="#000000">Sunday, March 29, 2020 2:06 PM,
</font></font><font size="2" face="Tahoma" color="#000000"><font size="2" face="Tahoma" color="#000000"><font size="2" face="Tahoma" color="#000000">Henrik Ingo wrote:
</font></font></font><br>
<div>
<blockquote>
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Mar 27, 2020 at 10:22 PM Josh Berkus <josh@berkus.org < Caution-mailto:josh@berkus.org > > wrote:<br>
</div>
</div>
<div class="gmail_quote"><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<br>
1. license does not in fact conform to the OSD (was erroneously approved)<br>
<br>
2. does not appear to be used for any currently available/working<br>
software *and is redundant with more popular licenses* (added condition<br>
mine).<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<div dir="ltr">
<div class="gmail_quote">
<div>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:</div>
<div>
<ol style="font-family: Times New Roman; font-size: 12pt;">
<li>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.</li><li>We keep hearing about 'license proliferation'. Focusing in on the rarely used 'bad' licenses will help with this.</li></ol>
<div>Note that I believe that the process should <b>only</b> 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
<b>terrible</b> 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 <b>clearly</b> articulate which of the OSD principles are being violated, and
<b>how</b> 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.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Cem Karan<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>