<div dir="ltr"><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, Jan 10, 2017 at 1:56 PM Richard Fontana <<a href="mailto:fontana@sharpeleven.org" class="gmail_msg" target="_blank">fontana@sharpeleven.org</a>> wrote:<br class="gmail_msg"></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Jan 10, 2017 at 04:07:53PM +0000, Luis Villa wrote:<br class="gmail_msg">
<br class="gmail_msg">
> *Supplementing with high-quality, value-adding options*<br class="gmail_msg">
> To encourage progress, while still avoiding proliferation, I'd suggest a<br class="gmail_msg">
> second list of licenses that are good but not (yet?) popular. <br class="gmail_msg"></blockquote><div><snip> <br></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I like the general idea, and I suppose it corresponds to what the OSI<br class="gmail_msg">
was trying to do with the partial updating of the 2006 popular list. I<br class="gmail_msg">
would rather have #3 be "must be determined to be well drafted and of high quality" without giving specifics (despite the additional<br class="gmail_msg">
subjectivity this would introduce). </blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">I'd still suggest pushing for collaboratively drafted, which could include "merely" incorporating substantial feedback from license-review, as in the case of UPL, but ideally would rise to the GPL/MPL level of community discussion.<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Perhaps where there has not been a non-OSI public discussion, "well drafted and high quality" could implicitly or explicitly be part of the OSI discussion and evaluation.<br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Looking at the whole history of<br class="gmail_msg">
open source licensing, it is hard to make the case that involvement of<br class="gmail_msg">
an attorney is a likely indicator of higher quality. :)<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg">Touché ;)</div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><br><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> If a new license meets #1, but not #3 and #4, then OSI's formal policy<br class="gmail_msg">
> should be to approve, but bury it in one of the other proliferation list<br class="gmail_msg">
> groups. (Those groups are actually quite good, and should be fairly<br class="gmail_msg">
> non-controversial — once you have a good policy for what gets in the more<br class="gmail_msg">
> "favored" groups.) I don't think a new "deprecated" group is necessary -<br class="gmail_msg">
> the proliferation categories are basically a good list of that already.<br class="gmail_msg">
<br class="gmail_msg">
I actually think we should take a fresh look at these proliferation<br class="gmail_msg">
categories.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Interesting! Any changes in particular? No objection to that in principle, but they've always seemed decent to me.<br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A bigger problem is that ... OSI came to be a place where one would bring licenses that are not being used yet -- which in some cases could mean licenses that never end up being used.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Interesting, and obviously correct, observation. Getting out of that trap is a bit of a catch-22, though: lots of the reason anyone cares about OSI at all is that it is seen as a bit of a "seal of approval" for unusual/unused licenses. If you say "no, we don't approve until used" then there is very little incentive for anyone to bother to bring the license later, once adoption has occurred. Perhaps that is not a problem, or perhaps that is solved(lessened?) by making clear that there is "this passes our lowest bars" v. "this is actually recommended".<br><br></div><div class="gmail_msg">Two relevant reads since I started this initial thread:<br></div><div class="gmail_msg"><ul><li><a href="http://redmonk.com/sogrady/2017/01/13/the-state-of-open-source-licensing/">Redmonk</a>; interesting on a number of fronts but perhaps most interestingly noting that the weak copyleft family has somewhat dropped out of the middle between permissive/strong copyleft.</li><li><a href="https://www.whitesourcesoftware.com/whitesource-blog/open-source-software-licenses-trends/">Top 10 open source licenses</a> from WhiteSource. Top 5 are same as Black Duck, but BlackDuck has Perl at #6 and ISC at #7 (despite being deprecated by ISC!) and MS-PL doesn't make the top 10; WhiteSource doesn't have ISC or Perl and has MS-PL at #7.<br></li></ul></div><div class="gmail_msg">Luis<br class="gmail_msg"></div></div></div></div></div>