On Sun, May 26, 2019 at 8:32 AM Pamela Chestek <pam...@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 _______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
