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

Luis Villa luis at lu.is
Fri May 31 23:46:12 UTC 2019


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20190531/3e64d6f7/attachment-0001.html>


More information about the License-review mailing list