[License-discuss] notes on a systematic approach to "popular" licenses

[Richard Fontana]

On Tue, Jan 10, 2017 at 04:07:53PM +0000, Luis Villa wrote:

> 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.
> 
> To maintain OSI's reputation as being (reasonably) neutral and independent,
> OSI should probably avoid basing this on third-party license surveys
> (e.g., Black
> Duck <https://www.blackducksoftware.com/top-open-source-licenses>) 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.

+1

> *Supplementing with high-quality, value-adding options*
> 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:
> 
>    1. meets the OSD
>    2. isn't on the data-driven popularity list
>    3. drafted by an attorney (at minimum) or by a collaborative, public
>    drafting process with clear support from a sponsoring-maintaining
>    organization (ideal)
>    4. 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")
>    1. but not "just for a particular community" - has to be at least
>       plausible applicable to most open source projects
>       2. this is unavoidably subjective; suggest having it fall to the
>       board with pre-discussion on license-review.

> #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.

I like the general idea, and I suppose it corresponds to what the OSI
was trying to do with the partial updating of the 2006 popular list. I
would rather have #3 be "must be determined to be well drafted and of
high quality" without giving specifics (despite the additional
subjectivity this would introduce). Looking at the whole history of
open source licensing, it is hard to make the case that involvement of
an attorney is a likely indicator of higher quality. :)

> 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.

I actually think we should take a fresh look at these proliferation
categories.

>    - 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.

A bigger problem is that somehow, and quite early on, the OSI came to
be seen as an organization that encouraged "experimental
licenses". (Not entirely a problem - the good part of this is that it
actively encouraged creativity and advancement in the field of open
source licensing.) One characteristic of the SPDX, Fedora, Debian [to
the extent an actual 'list' of DFSG-compatible licenses exists, which
I'm not sure of], and the FSF lists is that they deal with the actual
real world, for the most part: they consider licenses that are really
being used. 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.

SPDX and Fedora are thus not really going to reduce pressure for
obscure license authors unless those license authors actually see
their licenses in real use.

Richard