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

[Luis Villa]

On Sat, Jun 1, 2019 at 5:33 AM Pamela Chestek <pamela at chesteklegal.com>
wrote:

> 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.
>

Yes, absolutely! Like I said, I greatly appreciate this as a first step,
and will help as best I can. (I'd be happy to participate in a collaborative
summary document
<http://smallcultfollowing.com/babysteps/blog/2019/04/22/aic-collaborative-summary-documents/>
of the CAL in a modern collaboration tool like Dropbox Paper or Google
Docs, for example; and might even be moved to volunteer as a moderator for
a Discourse instance.)


> 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?
>

Where there's been a substantial point made, I think the answer is probably
yes - a concise and board-endorsed summary of the CC0 withdrawal, for
example, would have been repeatedly useful to be able to point at over the
years.

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?
>

I agree that in trivial/obvious cases like that one, a full opinion need
not be issued. It might still be worth keeping a list of "trivially
rejected licenses" by general category ("obviously discriminatory",
"incoherently written", "explicit patent non-grant", "ICE/996-style", etc.)
as a reference.


> 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?
>

I thought that was a good first step! One could imagine, after a suitable
waiting period, adding a link to that email to
opensource.org/rejected-licenses so as to memorialize it and make it easy
to find later?


> 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?
>

By analogy to the Rust and Wikipedia RFC summary processes I mentioned in
my first email, I think probably for all serious license proposals the
board should have before it a community-reviewed (ideally
community-drafted!) list of pros/cons/substantive issues raised/issued
resolved, which it could either approve as-is (in obvious/easy cases) or
add its own color/flavor to (in more complex cases where an actual decision
is necessary). Some positive effects we might expect to see from this:

   - documentation that supplements institutional memory (why did we
   approve some of those old licenses? unclear! a summary document might help
   us understand, and either fix the problems or apply consistent reasoning
   going forward)
   - encourage participation from the whole board, not just the
   license-review committee (good for the institutional legitimacy of the org;
   consistent with the move towards a broadly elected board)
   - sharpen/clarify key points of disagreement (speaking with my Wikipedia
   hat on, the summaries are really helpful for this; seems the Rust folks
   have had the same experience)
   - encourage broader non-board participation (these summary documents are
   a good way to lower the barrier to participation in a variety of ways)

Hope that helps.
Luis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190601/db60a89e/attachment.html>