[License-discuss] Evolving the License Review process for OSI

[Richard Fontana]

On Sun, May 26, 2019 at 8:32 AM Pamela Chestek <pamela at chesteklegal.com> wrote:
[replying to Rick Moen]

> But I hope to ease your concern that I am a rigid rule follower and can
> be gamed that way. First, even if I could be gamed or I have nefarious
> intent, the License Review Committee is four people and the Board is
> eleven people. I surely can't act unilaterally. Second, I'm not a rigid
> rule follower, although I am someone who believes that decisions should
> be consistent and backed up with rationale more compelling than "because
> we say so."

I've said this before: one of the reasons why the OSI is perceived as
making unpredictable decisions or decisions without rationale is the
result of how the license approval process has worked. Of the licenses
formally and informally submitted for approval, most never make it to
a board decision. Many submitters were never very serious and quickly
end their engagement. Some other licenses are more interesting and
controversial and what has happened in a number of those cases is the
license submitter withdraws after the mailing list discussion proceeds
in a negative or hostile way (not necessarily in a way that would
raise code-of-conduct issues). Anyway, the licenses that tend to make
it to a board decision are relatively uninteresting (from a
commercial/community perspective) and non-controversial (not raising
significant software freedom policy issues or OSD interpretation). Or
at least so it seems at the time. It is possible that the only case of
a formal board rejection of a license was one that occurred fairly
recently.

For the uninteresting/noncontroversial license approvals, the OSI's
silence on rationale hasn't been such a big deal because official
rationale wouldn't tell us much that isn't already obvious. Take
BSD+Patent: the license takes noncontroversial, widely used language
from the 2-clause BSD license and adds in some language from the
widely-accepted patent license grant clauses of the Apache License 2.0
and the EPL in a fairly straightforward way. It is not surprising that
this license was approved by the OSI, and I'm not sure what the OSI
should have said about the rationale that would have been particularly
enlightening for future license submissions.

Where official rationale would be helpful from a precedent or
predictability perspective is with the more controversial licenses --
but the OSI has no opportunity to provide any because of the
withdrawal or disengagement. I accept the OSI board's view that there
is a need for policing behavior on license-review, but I am not sure
problematic behavior on license-review is causing that disengagement
(which some OSI critics have at least hinted at). Maybe the OSI should
be rendering advisory opinions on license submissions that don't make
it to a final decision. We're left with uncertainty over the
significance of the failed submissions of L0-R and SSPLv2 -- recent
license submissions that raised significant and related policy
decisions concerning the acceptable limits of copyleft and
restrictions on "freedom 0" for an open source license.

> For example, I direct your attention to (brought to my
> attention by Kyle Mitchell) the OSI-approved  Reciprocal Public
> License.[^1] This license says "Regarding deployment, under the RPL your
> changes, bug fixes, extensions, etc. must be made available to the open
> source community at large when you Deploy in any form -- either
> internally or to an outside party. Once you start running the software
> you have to start sharing the software." How do you reconcile that with
> the current position, and a supposed basis for refusing a license, that
> there must be freedom to run software? "Because we say so" works, but I
> think people would be justified in their unhappiness if there is no
> explanation (which might be "oops, that one slipped through!")

I believe one problem is that the OSI has been very reluctant
institutionally to admit that it could have made a mistake in
judgment. A less obvious issue which I think probably goes well beyond
the OSI is the difficulty seeing that what "software freedom", or a
particular provision of the OSD, means might change over time rather
than somehow being fixed, though someone could reasonably take issue
with that just as a matter of software freedom philosophy.

Another license Kyle inconveniently brings up is the Adaptive Public
License -- the approval of which is completely inconsistent not just
with the OSI's current position on open source and patents but also,
arguably, with official OSI pronouncements on patents that predate
APL's approval.

Once in a while someone here suggests the OSI adopt an official
de-listing procedure (beyond the existing limited possibility for
license steward deprecation). I'd like to propose that the OSI board
reconsider this idea, so that a *very* small number of licenses
approved earlier in the OSI's history can be reexamined, at the
initiative of any community member, to see whether they should be
removed from the approved list, whether because the license was likely
approved in error, or (and this would probably be even more unusual)
because software freedom values have evolved sufficiently to make the
past approval inappropriate today. I realize that adopting a
de-listing procedure raises its own predictability-related policy
concerns.

Richard