[License-discuss] [License-review] Evolving the License Review process for OSI
Pamela Chestek
pamela at chesteklegal.com
Sat Jun 1 12:11:35 UTC 2019
Hi Luis,
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.
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.
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?
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?
Pam
Pamela S. Chestek
Chestek Legal
PO Box 2492
Raleigh, NC 27602
+1 919-800-8033
pamela at chesteklegal.com
www.chesteklegal.com
On 5/31/19 7:46 PM, Luis Villa 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 <mailto: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
> <mailto: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
> <mailto: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
> <mailto:pamela.chestek at opensource.org>
> Elana Hashman, elana.hashman at opensource.org
> <mailto:elana.hashman at opensource.org>
> Chris Lamb, chris.lamb at opensource.org
> <mailto:chris.lamb at opensource.org>
> Simon Phipps, webmink at opensource.org <mailto: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
> <mailto:License-review at lists.opensource.org>
> http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
>
>
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190601/861555d7/attachment-0001.html>
More information about the License-discuss
mailing list