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

Sat Jun 1 00:40:15 UTC 2019

+1 on all of this. The purpose of "guarantees software freedom" is either
(1) to reserve to OSI unfettered discretion, which removes all transparency
from the approval process, or (2) to articulate some kind of meaningful
condition, in which case it fails due to vagueness. If (1), please be
candid that the standards are arbitrary and allow the community to judge
the legitimacy of OSI's authority on that basis.  If (2), please fix it.

Also +1 on appreciation of the attempts to improve the process, but the
best process in the world will not avail when criteria for approval are
arbitrary.

On Fri, May 31, 2019 at 4:47 PM Luis Villa <luis at lu.is> wrote:

> Hi, Pam, board-
>
> Thanks for taking the time to write this down - I fully support the
> overall direction of these changes, fully endorse almost all of these
> specific changes, and greatly appreciate the effort it must have taken to
> put even this modest proposal together.
>
> One specific concern about this set of changes, and one thought for the
> longer-term, neither terribly new but trying to put them together concisely
> here:
>
>
> *Specific to this set of changes: *
>
> 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.
>
> 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. 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. If there's some
> substantive difference, I'd urge the board to retract this change until it
> can offer a coherent explanation of what software freedom means *for OSI*,
> how that's different from FSF, and how it is to be evaluated.
>
> *One thought for the longer term:*
> These reforms seem to me to be focused on clarifying *the decision-making*
> *process* of OSI. Which is worthy! But much of this effort will go to
> waste if there is not a matching set of improvements to the *record-keeping
> process* that documents the outcomes of the decision-making process.
>
> Imagine trying to understand US constitutional law if all you had were
> clerk's notes of the US Supreme Court's lunch discussions - that's roughly
> what being told "you can understand the OSD by reading the mailing list
> archives" is.[1] A set of rules that is literally incomprehensible, because
> the associated record-keeping is terrible, is hardly worth being called a
> set of rules.[2] But that's our situation - whether the formal record is
> the mailing list archives or the skimpy board meeting minutes, neither is
> well-suited to the "constitutional court" role of the OSI, which must not
> only decide but *explain* those decisions in a way that others can learn
> from.
>
> The next step in the long run should be to figure out how to create
> authoritative summaries of license proposal discussions, so that newcomers
> and non-experts can reasonably and transparently understand OSI and OSD.
> There are many process models for running RFCs - and more critically *summarizing
> *RFCs* -* that OSI could build on. This post from a Rust leader on collaborative
> summary documents
> <http://smallcultfollowing.com/babysteps/blog/2019/04/22/aic-collaborative-summary-documents/>
> is terrific, and Wikipedia has a wealth of institutional knowledge on
> closing and summarizing RFCs
> <https://en.wikipedia.org/wiki/Wikipedia:Advice_on_closing_discussions#Writing_the_close>.
> I'm sure there are others from other communities as well.
>
> This need not involve moving away from mailing lists altogether[3] but it
> definitely means that they should be replaced as the long-term repository
> of institutional knowledge.
>
> Again, I can't stress enough how pleased I am that the current board
> appears to take seriously the need to revise and improve OSI's procedures.
> I hope these comments are taken in that spirit.
>
> Sincerely-
> Luis
>
> [1] Or, as an experienced person in this space told me more bluntly
> yesterday, "'read the archives' is OSI's way of saying 'fuck you'".
> [2] I speculate, though of course I can't prove, that much of the 'the
> rules are too gameable!' problem the "software freedom" bandaid is
> attempting to fix would not be a problem at all if OSI had kept clear,
> detailed, referenceable records of past decisions made.
> [3] Though, as I just posted on l-d, I'm increasingly convinced that's a
> good idea if we want OSI to be the locus of a thriving, healthy community.
>
>
> On Fri, May 24, 2019 at 7:51 AM Pamela Chestek <
> pamela.chestek at opensource.org> wrote:
>
>> *Summary*
>> The directors of the board of the Open Source Initiative recognize the
>> process for discussion and review of new licenses proposed for approval by
>> the organization can use improvement and would benefit from evolution. In
>> particular, it does not appear as though all points of view on open source
>> licensing are represented in the discussion here. To address this situation
>> we have created a Board Committee for license approval to evaluate
>> responses on-list, appointed more moderators, and will devise a new
>> moderation strategy.
>>
>> *Proposal*
>> We anticipate that the effort to improve the quality of discussion on the
>> license lists will be an iterative process. This email describes our first
>> step, which is to approach the community and elicit feedback on this
>> approach. We anticipate further steps including a review of tools, but
>> we’re not yet at that stage.
>>
>> *Channels*
>> License review vs. License discuss lists
>>
>> License-review at lists.opensource.org is the email address for submitting
>> a license for which you seek OSI approval following the process at
>> https://opensource.org/approval. The list is open to the public, so
>> anyone can give their opinion about a license. The OSI License Committee
>> considers the viewpoints expressed on the license-review list in making its
>> license approval recommendation to the OSI Board. Since the purpose of the
>> list is to inform the Committee and the Board, discussion of substantive
>> issues off-list is not recommended. If a license submitter elects to
>> respond to a substantive question submitted to them off-list, the submitter
>> is encouraged to copy the license-review list also on their response after
>> redacting the identity of the person sending the communication.
>>
>> License-discuss at lists.opensource.org is for general questions about open
>> source licenses and for licenses in early stage development. The list is
>> open to the public and anyone can give feedback. A moderator may decide
>> that a license submitted to license-review isn’t sufficiently developed and
>> will move it to license-discuss for additional work. We recommend that you
>> carry out your license development process on a publicly viewable venue
>> (preferably one where collaboration is also possible) and regularly seek
>> views on license-discuss. Note that agreement on license-discuss does not
>> guarantee agreement on license-review, as the audiences differ.
>>
>> *Moderation*
>> The board recognizes that the license-review mailing list would benefit
>> from further, more concerted moderation, both to ensure appropriate
>> conversation and to maintain the pace of discussions. This more concerted
>> process will evolve in the following steps:
>>
>>
>>    - We will develop rules to encourage wider participation. We perceive
>>    that some are discouraged from participating because of offensive tone,
>>    frequency, or repetitiveness of messages. We will develop moderation
>>    standards to address these hurdles.
>>    - A moderator will also advance the conversation, by following up
>>    with the license steward on unanswered questions and ensuring that all
>>    topics of interest have been fully fleshed out.
>>    - We will assure observance of the Code of Conduct for the mailing
>>    lists, available at: https://opensource.org/codeofconduct/licensing.
>>
>>
>> *Changes to the Website*
>> We have also made a minor change to the language describing the license
>> review process on https://opensource.org/approval. The page formerly
>> said “Approve, if (a) there is sufficient consensus emerging from community
>> discussion that approval is justified, and (b) the OSI determines that the
>> license conforms to the Open Source Definition and guarantees software
>> freedom." The page now says “Approve if, after taking into consideration
>> community discussion, the OSI determines that the license conforms to the
>> Open Source Definition and guarantees software freedom.”
>>
>> We have also clarified the timing of the review decision.
>>
>> *License Review Committee*
>> The License Review Committee is an OSI Board committee made up of the
>> following board members, as of May 2019:
>>
>> Pamela Chestek, chair, pamela.chestek at opensource.org
>> Elana Hashman, elana.hashman at opensource.org
>> Chris Lamb, chris.lamb at opensource.org
>> Simon Phipps, webmink at opensource.org
>>
>> The License Review Committee will summarize and report the license-review
>> discussions to the Board for the Board’s approval or disapproval of a
>> proposed license. Members of the Committee also serve as moderators for the
>> two mailing lists.
>>
>> *What We’re Asking*
>> Let us know what you think of these changes.
>>
>> Pam
>>
>> --
>> Pamela Chestek
>> Chair, License Review Committee
>> Open Source Initiative
>>
>> _______________________________________________
>> License-review mailing list
>> License-review at lists.opensource.org
>>
>> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>>
> _______________________________________________
> License-review mailing list
> License-review at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190531/aa45260e/attachment.html>