<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">>What problem are you trying to solve here?  It doesn't seem like a</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">>problem we actually have.</span><br>
<div style><font face="arial, sans-serif">If really there is no problem, Josh, then forget my suggestion of "simple certificate". I don't  want to invent a false problem to propose a wrong solution!</font></div>
<div style><font face="arial, sans-serif">Anyway there is at least one problem: the poor quality of most new submitted licenses.</font></div><div style><font face="arial, sans-serif">On this point, the suggestion of a more formal "license submission as a check list" including the points I mentioned in my 6 June mail could probably improve the situation.</font></div>
<div style><font face="arial, sans-serif">In the current situation of license proliferation, an additional point could be added to the list:</font></div><div style><font face="arial, sans-serif">- detail how far software code covered by your proposed licence could benefit to other FOSS communities and be merged/reused in projects covered by other OSI approved licenses.   </font></div>
<div style><font face="arial, sans-serif">P-E.</font></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/6/12 Josh Berkus <span dir="ltr"><<a href="mailto:josh@postgresql.org" target="_blank">josh@postgresql.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
> This was not at all my idea, if you read me correctly: I suggested the<br>
> rapid deliverance of an "OSD compliance certificate" (even if the license<br>
> does not improve / revolutionate the FLOSS ecosystem). The certificate will<br>
> be the evidence that the licence is open source (facilitating the adoption<br>
> by the first followers).<br>
> OSI may then take more time to classify eventually the license as<br>
> "OSI-approved" once a representative level of projects will use it (as the<br>
> case may be).<br>
<br>
</div>What problem are you trying to solve here?  It doesn't seem like a<br>
problem we actually have.  I'll also point out that popularity is no<br>
guarantee of validity.  For example, the "Beerware" license is extremely<br>
popular, but is completely unenforceable.<br>
<br>
First, let me agree with Rick and point out that the only licenses we've<br>
approved in the last year were new versions of old approved licenses.<br>
Every other proposed license we've seen has been rejected as either (a)<br>
not OSD-compliant, or (b) very poorly conceived and written, or (c)<br>
wholly duplicative of an existing license.  As far as I'm concerned,<br>
that part of the process is working fine.<br>
<br>
What's not working fine is how people *feel* about the rejection<br>
process.  What happens currently in the worst case is:<br>
<br>
(1) Crayon license submitter (CLS) emails their "clever" idea for a new<br>
license to this list.<br>
<br>
(2) We point out some of the shortcomings in the license and reject it.<br>
<br>
(3) CLS becomes indignant and accuses us of personal enmity and/or<br>
incompetence.<br>
<br>
(4) CLS attempts to lobby and/or harass us into submission.  This<br>
doesn't work.<br>
<br>
(5) We are contemptuous of CLS.  CLS hates us.<br>
<br>
(6) CLS decides to use their "license" anyway.<br>
<br>
My thinking was that an explicit process where the submitter *had* to<br>
consult an attorney before submitting ... and where the only reply we'd<br>
give to one who didn't was to point to that requirement ... would cause<br>
the CLS to talk to an attorney first who would at least point out that<br>
the license they're sending is badly written and unenforceable.  Or,<br>
more likely, get hung up on finding an attorney and never write their<br>
crayon license in the first place.<br>
<br>
However, I think enough people on here have pointed out that CLS's are<br>
ignoring any kind of reasonable process anyway, so adding process<br>
requirements won't work; they'll simply ignore them.<br>
<br>
In a way, this is actually the process working as designed.  As the<br>
number of possible new licenses which are OSD-compliant, original and<br>
sensible approaches the vanishing point, increasingly the only<br>
submissions we're going to see are going to be from the ill-informed and<br>
impulsive.  So maybe there's no fixable problem here, at all.<br>
<span class="HOEnZb"><font color="#888888"><br>
--Josh Berkus<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@opensource.org">License-review@opensource.org</a><br>
<a href="http://projects.opensource.org/cgi-bin/mailman/listinfo/license-review" target="_blank">http://projects.opensource.org/cgi-bin/mailman/listinfo/license-review</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Patrice-Emmanuel Schmitz<br><a href="mailto:pe.schmitz@googlemail.com">pe.schmitz@googlemail.com</a><br>tel. + 32 478 50 40 65
</div>