[License-discuss] comprehensiveness (or not) of the OSI-approved list [was Re: [License-review] For Legacy Approval: LBNL BSD]

[Richard Fontana]

On Sat, May 18, 2019 at 4:56 PM Luis Villa <luis at lu.is> wrote:

> Saying "OSI's list isn't very useful in contracts or scanners" does carry an implicit question that I've probably also said explicitly on occasion: if people don't, by and large, refer exactly to the OSI list in their documents and scanners, then what is it for? Who is the audience? What will they use the list for? I don't actually have good answers to this question, so I'm not sure how OSI should answer it.

I guess I don't either. To me, the approval process is (at least
potentially) more important than the list itself. Through the analysis
and critique and approval or rejection of submitted licenses, what
we/the community means by "open source" (or "free software") becomes
clearer. It's an act of self-definition. It's useful to me, because I
work *within* open source, as I and others see it, and I need to
understand the appropriate boundary between open source and non-open
source for what I do to make sense. This suggests that the submitted
licenses are mostly not themselves all that important, rather they
serve as excuses to engage in some interesting philosophical
deliberations over what open source actually is. (Maybe to the
annoyance of a lot of license submitters.) However, occasionally a
submitted license *is* important because it's being submitted by an
influential person or entity,

I recognize (and have in the past called attention to) the obvious
problem with all this, that of relying on self-appointed authority
figures to determine community standards.  This is also why for all
its faults the OSI license-review list is commendable, because in no
other case is there a meaningful opportunity for *anyone* to
participate in this policymaking exercise. The alternative is to rely
on less transparent authorities (FSF, Debian, I guess Fedora should
also be included here) or to express one's views in some isolated and
less effectual manner. At least the existence of the OSI and its
approved licenses helps avoid a situation of total chaos where no one
agrees on what open source / free software means, or where the
definition gets significantly watered down.

> But it does seem likely that OSI should strive to have some lists whose goal is explicitly about utility. (This does not imply that OSI should abandon the current OSD; one can imagine many lists that are more useful and still contain only OSD-compliant licenses. But one can also imagine that an effort to create those lists might helpfully serve to help refine the edge cases of what the OSD means in 2019 - perhaps either knocking things off of, or adding to, the "main" list.)
>
> Answering this question of utility is what drove the Blue Oak list. It is not a challenge to OSI's authority, simply an actually useful thing that I can refer to in contracts and scanner policies, which I (and my clients/customers) need but OSI does not provide. We'll continue to evolve the list with that goal of utility in mind. (For example, we've had several people say they can't use it until the groupings/labels are more informative/less vague. If the list isn't pragmatically useful, it isn't fulfilling its purpose, so we'll probably make them more informative.) If OSI obsoleted this effort by providing a deliberately useful list of permissive licenses I'd be thrilled.

I guess it hadn't occurred to me that for some the main purpose of
these kinds of supposedly authoritative license lists might be use for
contracts and scanning tools (since for me those are not really
interesting or useful ways of making use of such lists).  A more
comprehensive list (like the Fedora list) can be useful if one is
actually trying to create an open source product or distribution -- at
least if one cares about accuracy and integrity in description of
software as "open source". I think there may be a lot of people who
aren't familiar with what's specifically on the OSI approved list and
assume it is similarly comprehensive, or assume that open source
software (that is, software generally and non-controversially
considered to be open source) is composed from a license standpoint
only from licenses in the OSI list.

Richard