<div dir="ltr"><div>Hi, Pam, board-</div><div><br></div><div>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.</div><div><br></div><div>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:<br></div><div><br></div><div><i>Specific to this set of changes: <br></i></div><div><br></div><div>From the updated <a href="https://opensource.org/approval">https://opensource.org/approval</a>: </div><div>"the OSI determines that the <span class="gmail-il">license</span> ... guarantees software freedom."</div><div><br></div><div>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. <br></div><div><br></div><div>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 <i>for OSI</i>, how that's different from FSF, and how it is to be evaluated.<br></div><div><br></div><div><i>One thought for the longer term:</i></div><div>These reforms seem to me to be focused on clarifying <i>the decision-making</i> <i>process</i> 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 <i>record-keeping process</i> that documents the outcomes of the decision-making process.</div><div><br></div><div><div>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 <i>explain</i> those decisions in a way that others can learn from.<br></div><div><br></div></div><div>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 <i>summarizing </i>RFCs<i> -</i> that OSI could build on. This post from a Rust leader on <a href="http://smallcultfollowing.com/babysteps/blog/2019/04/22/aic-collaborative-summary-documents/">collaborative summary documents</a> is terrific, and Wikipedia has <a href="https://en.wikipedia.org/wiki/Wikipedia:Advice_on_closing_discussions#Writing_the_close">a wealth of institutional knowledge on closing and summarizing RFCs</a>. I'm sure there are others from other communities as well.<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Sincerely-<br></div><div>Luis<br></div><div><br></div><div>[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'".</div><div>[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.<br></div><div>[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.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 24, 2019 at 7:51 AM Pamela Chestek <<a href="mailto:pamela.chestek@opensource.org">pamela.chestek@opensource.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<u>Summary</u><br>
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.<br>
<br>
<u>Proposal</u><br>
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.<br>
<br>
<u>Channels</u><br>
License review vs. License discuss lists<br>
<br>
<a class="gmail-m_5302422009249463333moz-txt-link-abbreviated" href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a> is the email address for
submitting a license for which you seek OSI approval following the
process at <a class="gmail-m_5302422009249463333moz-txt-link-freetext" href="https://opensource.org/approval" target="_blank">https://opensource.org/approval</a>. 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. <br>
<br>
<a class="gmail-m_5302422009249463333moz-txt-link-abbreviated" href="mailto:License-discuss@lists.opensource.org" target="_blank">License-discuss@lists.opensource.org</a> 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.<br>
<br>
<u>Moderation</u><br>
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:<br>
<br>
<ul>
<li>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.</li>
<li>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.</li>
<li>We will assure observance of the Code of Conduct for the
mailing lists, available at:
<a class="gmail-m_5302422009249463333moz-txt-link-freetext" href="https://opensource.org/codeofconduct/licensing" target="_blank">https://opensource.org/codeofconduct/licensing</a>.</li>
</ul>
<br>
<u>Changes to the Website</u><br>
We have also made a minor change to the language describing the
license review process on <a class="gmail-m_5302422009249463333moz-txt-link-freetext" href="https://opensource.org/approval" target="_blank">https://opensource.org/approval</a>. 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.”<br>
<br>
We have also clarified the timing of the review decision.<br>
<br>
<u>License Review Committee</u><br>
The License Review Committee is an OSI Board committee made up of
the following board members, as of May 2019:<br>
<br>
Pamela Chestek, chair, <a class="gmail-m_5302422009249463333moz-txt-link-abbreviated" href="mailto:pamela.chestek@opensource.org" target="_blank">pamela.chestek@opensource.org</a><br>
Elana Hashman, <a class="gmail-m_5302422009249463333moz-txt-link-abbreviated" href="mailto:elana.hashman@opensource.org" target="_blank">elana.hashman@opensource.org</a><br>
Chris Lamb, <a class="gmail-m_5302422009249463333moz-txt-link-abbreviated" href="mailto:chris.lamb@opensource.org" target="_blank">chris.lamb@opensource.org</a><br>
Simon Phipps, <a class="gmail-m_5302422009249463333moz-txt-link-abbreviated" href="mailto:webmink@opensource.org" target="_blank">webmink@opensource.org</a><br>
<br>
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.<br>
<br>
<u>What We’re Asking</u><br>
Let us know what you think of these changes. <br>
<br>
Pam<br>
<pre class="gmail-m_5302422009249463333moz-signature" cols="72">--
Pamela Chestek
Chair, License Review Committee
Open Source Initiative</pre>
</div>
_______________________________________________<br>
License-review mailing list<br>
<a href="mailto:License-review@lists.opensource.org" target="_blank">License-review@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote></div>