<div dir="ltr">On Sun, Apr 9, 2017 at 11:57 AM Philippe Ombredanne <<a href="mailto:pombredanne@nexb.com">pombredanne@nexb.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On Thu, Apr 6, 2017 at 6:19 PM Philippe Ombredanne <<a href="mailto:pombredanne@nexb.com" class="gmail_msg" target="_blank">pombredanne@nexb.com</a>><br class="gmail_msg">
> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> On Thu, Apr 6, 2017 at 5:21 PM, Luis Villa <<a href="mailto:luis@lu.is" class="gmail_msg" target="_blank">luis@lu.is</a>> wrote:<br class="gmail_msg">
>> > On Tue, Jan 10, 2017, 11:07 AM Luis Villa <<a href="mailto:luis@lu.is" class="gmail_msg" target="_blank">luis@lu.is</a>> wrote:<br class="gmail_msg">
>> >><br class="gmail_msg">
>> >> Hey, all-<br class="gmail_msg">
>> >> I promised some board members a summary of my investigation in '12-'13<br class="gmail_msg">
>> >> into updating, supplementing, or replacing the "popular licenses" list.<br class="gmail_msg">
>> >> Here<br class="gmail_msg">
>> >> goes.<br class="gmail_msg">
>> [...]<br class="gmail_msg">
>> > Yet another (inevitably flawed) data set:<br class="gmail_msg">
>> > <a href="https://libraries.io/licenses" rel="noreferrer" class="gmail_msg" target="_blank">https://libraries.io/licenses</a><br class="gmail_msg">
>><br class="gmail_msg">
>> With the merit that the all the underlying code is FLOSS.<br class="gmail_msg">
>><br class="gmail_msg">
>> Another possible source --always biased-- could be Debian's popcon and<br class="gmail_msg">
>> some cross ref with debsources.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
On Fri, Apr 7, 2017 at 11:54 AM, Andrew Nesbitt <<a href="mailto:andrew@libraries.io" class="gmail_msg" target="_blank">andrew@libraries.io</a>> wrote:<br class="gmail_msg">
> "inevitably flawed", would be great to get some feedback on how/why it's<br class="gmail_msg">
> flawed so I can improve it?<br class="gmail_msg">
><br class="gmail_msg">
> System level package managers are in the pipeline for the end of the year,<br class="gmail_msg">
> but there are so fewer packages there that I can't see it moving the needle<br class="gmail_msg">
> much<br class="gmail_msg">
<br class="gmail_msg">
Andrew: my comment on "inevitably flawed" was to echo Luis point that any<br class="gmail_msg">
open source  license popularity contest is likely to be flawed and biased one<br class="gmail_msg">
way or another regardless of the data set that is considered as a basis.<br class="gmail_msg"></blockquote><div><br></div><div>Hi, Andrew-<br></div><div>For some reason your email never made it through to me; just saw Philippe's response coming through.<br><br></div><div>I added "inevitably flawed" as a shorthand to fend off the basic critiques that always accompany mentions of surveys on this list. The primary critiques are:<br></div><div><ul><li>What's the "right" set of data sources to draw from? By deciding to include (or leave out) any particular repo, you inevitably impact license popularity, and also inevitably you can't include them all.</li><li>What's the "right" metric for popularity? projects? files? LOCs? usage of projects? For example, if two projects are of the same complexity, but one is widely used and the other hardly used at all, should they count the same? What if one is very simple, the other very complex?</li><ul><li>What about unmaintained/old code? <br></li></ul><li>What's the "right" level to scan at? Top-level project-declared LICENSE file? Or per-file throughout the tree? (Note that often those two measures don't agree with each other.)</li></ul><p>I feel that there are no right or wrong answers to these questions; different surveys have different purposes. But others disagree: every time we discuss this subject here, someone pops up and says "no, this service does it wrong, they should do X instead". Because no service can please everyone, I know yours displeases someone :)</p><p>[There is also a question as to whether or not proprietary methodologies should be completely ignored, or taken as another data point with an appropriate grain of salt. I don't think that question is possible to answer for OSI yet, but it probably does have right/wrong answers.]<br></p><p>Hope that clarifies where I was coming from- would be happy to chat whenever if this doesn't.<br></p><p>Luis<br></p></div></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div class="gmail_signature"><div dir="ltr"><div><i><a href="http://lu.is" target="_blank">Luis Villa: Open Law and Strategy</a><br></i></div><i>+1-415-938-4552</i></div></div></div></div>