<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Luis,<br>
<br>
Thanks for the comments. Speaking entirely for myself here, I agree
with you. I hope everyone appreciates that this email was just a
first step. We are also aware that email sucks (I'm about to tear my
hair out after only a month of it, so I hear you) and will be
working on a better tooling solution. I don't expect that to happen
too soon, though. Small org, volunteers, you get it I'm sure.<br>
<br>
Speaking personally still (have I made that clear enough yet?), I am
strongly opposed to any "because we say so" standard of license
approval. As I suspect everyone understands though, there are also
new and novel questions raised in submitted licenses, the CAL
license being a good example, so sometimes the answer has to come
from fundamental policy principles. As is also well-known, the OSD
(like any law) can be gamed to do exactly the opposite of what the
goals and purposes of open source software are, so it is appropriate
that the OSI ensures that doesn't happen. My take is that is what is
meant by "software freedom," but I agree with you that parroting the
phrase is entirely unhelpful.<br>
<br>
As to rationale and recordkeeping, I expect to be providing a
rationale document about the OSI's decisions on license approval.
However, Richard Fontana has pointed out the process problem where
there is a pile-on in license-review, causing the license submitter
to withdraw the license and then no opportunity for the OSI to
provide any feedback on what the OSI itself actually thought about
the license. Should the OSI be in the business of giving "advisory
opinions," and if so, how? How about how the "Master's-Console Open
Source Definitive License," a license clearly not ready for review,
was handled? The problems were quite obvious with it, so does
anything more need to be said about it? ICYMI, I sent out an email
stating we were assuming that it was withdrawn because the submitter
moved the discussion to L-D, although never communicated to us that
it was formally withdrawn. Should this have been handled
differently?<br>
<br>
And what about a license that is approved? Every license has flaws
that people note. Should a rationale document explain why these
weren't considered problematic, or is approval good enough?<br>
<br>
Pam<br>
<br>
<div class="moz-signature">Pamela S. Chestek<br>
Chestek Legal<br>
PO Box 2492<br>
Raleigh, NC 27602<br>
+1 919-800-8033<br>
<a class="moz-txt-link-abbreviated" href="mailto:pamela@chesteklegal.com">pamela@chesteklegal.com</a><br>
<a class="moz-txt-link-abbreviated" href="http://www.chesteklegal.com">www.chesteklegal.com</a><br>
<br>
<br>
</div>
<div class="moz-cite-prefix">On 5/31/19 7:46 PM, Luis Villa wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAFjZtReB=w3cfd+KfA3F=t4x0pvLkCajLVFW=PM-4z_MyZredg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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/"
moz-do-not-send="true">collaborative summary documents</a>
is terrific, and Wikipedia has <a
href="https://en.wikipedia.org/wiki/Wikipedia:Advice_on_closing_discussions#Writing_the_close"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">pamela.chestek@opensource.org</a><br>
Elana Hashman, <a
class="gmail-m_5302422009249463333moz-txt-link-abbreviated"
href="mailto:elana.hashman@opensource.org" target="_blank"
moz-do-not-send="true">elana.hashman@opensource.org</a><br>
Chris Lamb, <a
class="gmail-m_5302422009249463333moz-txt-link-abbreviated"
href="mailto:chris.lamb@opensource.org" target="_blank"
moz-do-not-send="true">chris.lamb@opensource.org</a><br>
Simon Phipps, <a
class="gmail-m_5302422009249463333moz-txt-link-abbreviated"
href="mailto:webmink@opensource.org" target="_blank"
moz-do-not-send="true">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" moz-do-not-send="true">License-review@lists.opensource.org</a><br>
<a
href="http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
License-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:License-discuss@lists.opensource.org">License-discuss@lists.opensource.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a>
</pre>
</blockquote>
<br>
</body>
</html>