[License-review] [License-discuss] Evolving the License Review process for OSI
rfontana at redhat.com
Mon Jun 3 02:30:26 UTC 2019
On Fri, May 31, 2019 at 7:47 PM Luis Villa <luis at lu.is> wrote:
> From the updated https://opensource.org/approval:
> "the OSI determines that the license ... guarantees software freedom."
> I still have seen no coherent explanation of what software freedom means in the OSI context. Richard has asserted on Twitter that it isn't necessarily the same thing as FSF's definition, but OSI has not (as best as I can tell) proposed an alternative either, so we're left with a limbo of having some idea what FSF means, but knowing that OSI's definition is somehow, in unknown directions, different.
This isn't how I see it. "Software freedom" is a recently-popularized
(still not so popular) term, which has actually been in use for quite
a while, to describe a set of evolving community values and traditions
around the core legal and ethical underpinnings free software/open
source software, reflected in a few widely-respected and influential
definitional efforts -- the DFSG, the OSD, and the 4-part FSD, but
additionally reflected in the actual demonstrable choices and
attitudes of the main participants in free software/open source
If the OSI board agrees at all with any of that, maybe it could add
some words to that effect.
> Until more specific, less vague language is used, I remain deeply concerned that this makes the process even more deeply political by allowing the board to veto any license on virtually any grounds it feels like, as long as it can be vaguely tied to "freedom" for some person or company.
The constraint ought to be a commitment to the tying of "software
freedom" to demonstrable community values and traditions. Of course
the OSI should not be using "software freedom" to justify any
Also, frankly, hasn't it been the case in practice that the OSD is
broad, vague and in some places oddly-worded enough that it can also
be criticized as facilitating arbitrary decisionmaking? I have
recently pointed out that basically any critique of a submitted
license can be couched as an OSD 5/6 violation, because any
conceivable problematic feature of a quasi-FLOSS license is going to
be describable as a discrimination against *someone*. What has
preserved the OSI's legitimacy -- despite what I believe was the
mistaken approval of a few largely-obsolete licenses years ago -- is
not really the constraint provided by the 10-part OSD, but rather the
commitment of the OSI in practice to adhering to shared community
values and expectations about what an open source license can and
can't be -- which I believe is neatly expressed using the phrase
> It also leaves it less clear than ever what useful role, if any, OSI plays that distinguishes it from FSF. If both organizations are using essentially identical criteria, I'd again urge the two orgs to consider merging their license lists and review processes.
This is not a bad idea (though it's currently somewhat unrealistic).
But it has been a good idea for a long time, because in reality the
two organizations *have* been using the same underlying criteria, for
the OSI at least since the mid-2000s. Both organizations seek to
recognize as respective-definition-conformant licenses that can be
expected to guarantee software freedom. They just happen to use
different definitions, much as Debian and the FSF use different
definitions of "free software". That after all is why the two
organizations have few significant disagreements about the
FLOSS-legitimacy of particular licenses. If the two organizations were
really aimed at markedly different value systems we'd expect to see
major differences between the FSF's list of free software licenses and
the OSI's list of approved licenses.
More information about the License-review