Yet another (inevitably flawed) data set: <br><a href="https://libraries.io/licenses">https://libraries.io/licenses</a><div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 10, 2017, 11:07 AM Luis Villa <<a href="mailto:luis@lu.is">luis@lu.is</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">[Apparently I got unsubscribed at some point, so if you've sent an email here in recent months seeking my feedback, please resend.]<br class="gmail_msg"><br class="gmail_msg"><div class="m_-1542782175245002492inbox-inbox-gj m_-1542782175245002492inbox-inbox-s2 gmail_msg"><div class="m_-1542782175245002492inbox-inbox-ap m_-1542782175245002492inbox-inbox-s2 gmail_msg"><div class="m_-1542782175245002492inbox-inbox-pA m_-1542782175245002492inbox-inbox-s2 gmail_msg"><div class="m_-1542782175245002492inbox-inbox-he m_-1542782175245002492inbox-inbox-s2 gmail_msg"><div class="m_-1542782175245002492inbox-inbox-b5 m_-1542782175245002492inbox-inbox-xJNT8d gmail_msg"><div class="m_-1542782175245002492inbox-inbox-uyb8Gf gmail_msg"><div class="gmail_msg"><div class="m_-1542782175245002492inbox-inbox-F3hlO gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Hey, all-<br class="gmail_msg"></div>I
promised some board members a summary of my investigation in '12-'13
into updating, supplementing, or replacing the "popular licenses" list.
Here goes.<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><b class="gmail_msg">tl;dr<br class="gmail_msg"></b></div><div class="gmail_msg">I
think OSI should have an data-driven short license list with a
replicable and transparent methodology, supplemented by a
new-and-good(?) list that captures licenses that aren't yet popular but
are high quality and have some substantial improvement that advances the
goals of OSI.<br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><b class="gmail_msg">Purposes of non-comprehensive lists<br class="gmail_msg"></b></div>If
you Google "open source licenses", OSI pages are the top two hits.
Historically, those pages were not very helpful unless you already knew
something about open source. Having a shorter "top" list can help make
the OSI website more useful to newcomers by suggesting a starting place
for their exploration and education about open source. <br class="gmail_msg"><br class="gmail_msg">In
addition, third parties often look to OSI as a trusted (neutral?)
source for "top" or "best" licenses that they can incorporate into
products. (The full OSI-approved list is not practical for many
applications.) For example, if OSI had an up-to-date short list, it
might have been the basis for GitHub's license chooser.<br class="gmail_msg"><p class="gmail_msg">A
list that is purely based on popularity would freeze open source in a
particular time, likely making it hard for new licenses with important
innovations to get adoption. However, a list based on more subjective
criteria is hard to create and update.<br class="gmail_msg"></p><p class="gmail_msg"><b class="gmail_msg">Past attempts</b></p><p class="gmail_msg">The
proliferation report attempted to address this problem by categorizing
existing licenses. These categories were, intentionally or not, seen as
the "popular or strong communities list" and "everything else". Without a
process or clear set of criteria to update the "popular" list, however,
it became frozen in time. It is now difficult to credibly recommend the
list to newcomers or third parties (MPL 1.1 is deprecated; no mention
of Blackduck #4 GPL v3; etc.).<br class="gmail_msg"></p><p class="gmail_msg">There
was also substantial work done towards a license "chooser" or "wizard".
However, this runs into some of the same problems - either the chooser
is opinionated (and so pisses off people, and potentially locks the
licenses in time) or is borderline-useless for newcomers (because it
still requires substantial additional research after using it).<br class="gmail_msg"></p><p class="gmail_msg"><b class="gmail_msg">Data-driven "popular" list</b><br class="gmail_msg"></p><p class="gmail_msg">With
all that in mind, I think that OSI needs a (mostly) data-driven
"popular" shortlist, based on a scan of public code + application of
(mostly?) objective rules to the outcome of that scan.<br class="gmail_msg"></p><p class="gmail_msg">To
maintain OSI's reputation as being (reasonably) neutral and
independent, OSI should probably avoid basing this on third-party
license surveys (e.g., <a href="https://www.blackducksoftware.com/top-open-source-licenses" class="gmail_msg" target="_blank">Black Duck</a>)
unless their methodologies and data sources are well-documented.
Ideally someone will write code so that the "survey" can be run by OSI
and reproduced by others.</p><p class="gmail_msg">Hard decisions on how to collect and "process" the data will include:<br class="gmail_msg"></p><ul class="gmail_msg"><li class="gmail_msg"><i class="gmail_msg">choice of data sources:</i> What data sources are drawn on? Key Linux distros? GitHub? per-language repos like maven, cpan, npm, etc? <br class="gmail_msg"></li><li class="gmail_msg"><i class="gmail_msg">what are you counting?</i><b class="gmail_msg"> </b>Projects? (May favor small, throwaway projects?) Lines of code? (May favor the largest, most complex projects?) ... ?<br class="gmail_msg"></li><li class="gmail_msg"><i class="gmail_msg">which license tools? </i>Some scanners are more aggressive in trying to identify <i class="gmail_msg">something</i>,
while others prefer accuracy over comprehensiveness. In 2013 there was
no good answer to this, but my understanding is that fossology now has
three different scanners, so for OSI's purposes it may be sufficient to
take those three and average. <br class="gmail_msg"></li><ul class="gmail_msg"><li class="gmail_msg">Could throw in Black Duck or other non-transparent surveys as a fourth, fifth, etc.?<br class="gmail_msg"></li></ul><li class="gmail_msg"><i class="gmail_msg">new versions? </i>If
a new version exists but isn't widely adopted yet, how does the list
reflect that? e.g., MPL 1.1 still shows up in Black Duck's survey;
should OSI replace 1.1 with 2.0 in the "processed" list? What about GPL
v2 v. v3? BSD/MIT v. UPL?</li><li class="gmail_msg"><i class="gmail_msg">gaps/"mistakes":</i> What happens when the board thinks the data is incorrect? :) e.g., should ISC be listed?<br class="gmail_msg"></li></ul><p class="gmail_msg">Part
of why we didn't go very far in 2013 is because there are no great
answers for these - different answers will reflect different values, and
have different engineering impact. They're all hard choices for the
board, the developers, hopefully license-discuss, and perhaps a broader
community.<br class="gmail_msg"></p><p class="gmail_msg">Hat tip: Daniel German was invaluable to me in thinking through these questions.<br class="gmail_msg"></p><p class="gmail_msg"><b class="gmail_msg">Supplementing with high-quality, value-adding options</b></p>To
encourage progress, while still avoiding proliferation, I'd suggest a
second list of licenses that are good but not (yet?) popular. "Good"
would be defined as something like:<br class="gmail_msg"><div class="gmail_msg"><ol class="gmail_msg"><li class="gmail_msg">meets the OSD<br class="gmail_msg"></li><li class="gmail_msg">isn't on the data-driven popularity list<br class="gmail_msg"></li><li class="gmail_msg">drafted
by an attorney (at minimum) or by a collaborative, public drafting
process with clear support from a sponsoring-maintaining organization
(ideal)</li><li class="gmail_msg">has a new "feature" that is firmly in
keeping with the overall goals of open source and can be concisely
explained in a few sentences (e.g., for UPL, "GPL-compatible permissive
license with explicit patent grant") <br class="gmail_msg"></li><ol class="gmail_msg"><li class="gmail_msg">but not "just for a particular community" - has to be at least plausible applicable to most open source projects</li><li class="gmail_msg">this is unavoidably subjective; suggest having it fall to the board with pre-discussion on license-review.<br class="gmail_msg"></li></ol></ol><p class="gmail_msg">#4
allows for some innovation (and OSI support of such innovation) while
#3 applies a quality filter. (Both #3 and #4 have anti-proliferation
effects.) Hopefully licenses that meet #3 and #4 would eventually move
into #2, but you could imagine placing a time limit on this list; if
you're not in the top 10 most popular within five years, then you get
retired? But not sure that's a good idea at all - just throwing it out
as one option. <br class="gmail_msg"></p><p class="gmail_msg">If a new
license meets #1, but not #3 and #4, then OSI's formal policy should be
to approve, but bury it in one of the other proliferation list groups.
(Those groups are actually quite good, and should be fairly
non-controversial — once you have a good policy for what gets in the
more "favored" groups.) I don't think a new "deprecated" group is
necessary - the proliferation categories are basically a good list of
that already.</p><p class="gmail_msg">This is still a somewhat
subjective process, and if it had been in place in '99-'06, it would
have been fairly fraught. However, I think most of the "action" in open
source organization has moved on to other areas (e.g., foundation
structure, CoCs, etc.), and the field has matured in other ways, so I
think this is now a practicable approach in ways it would not have been a
decade or even five years ago.<br class="gmail_msg"></p><p class="gmail_msg"><b class="gmail_msg">Miscellaneous notes</b></p><ul class="gmail_msg"><li class="gmail_msg">I
don't recommend merely updating the existing "popular and..." list
through a subjective or one-time process. The politics of that will be
messy, and without a documented, mostly-objective, data-driven method,
it'll again become an outdated mess.<br class="gmail_msg"></li><li class="gmail_msg">The
OSD should probably be updated. At the least this should be by
addressing things like whether a formal patent grant is required of new
licenses; more ambitiously it might follow <a href="http://opendefinition.org/od/2.1/en/" class="gmail_msg" target="_blank">Open Data Definition 2.x</a> by splitting out open licenses from open works.<br class="gmail_msg"></li><li class="gmail_msg">With
SPDX and Fedora providing more comprehensive lists of FOSS licenses, it
might make sense for OSI to link to those as "extended" resources, to
reduce pressure from obscure license authors to get their license
approved.</li><li class="gmail_msg">The biggest pressure on this process
will continue to be licenses that try to open up space for new
commercial business models (e.g., Fair Source). The more OSI can
write/document/buttress OSD #1, the better.</li><li class="gmail_msg">I
used to think a license wizard was a good idea, but I don't any more. I
thought copyleft spectrum was really the only important decision-making
factor, which made the idea plausible, but non-copyleft factors matter
much more than I once thought, and make simplifying to a "wizard" too
hard for OSI (though perhaps still plausible for a third party).<br class="gmail_msg"></li><li class="gmail_msg">Documentation of what the copyleft
spectrum <i class="gmail_msg">is</i>, what the key licenses on it are, and what other
factors might be relevant, is still a good idea, but are secondary to getting the basic lists right.</li></ul><p class="gmail_msg">HTH-</p><p class="gmail_msg">Luis<br class="gmail_msg"></p></div></div></div></div></div></div></div></div></div></div></div></blockquote></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>