<div dir="ltr"><div dir="ltr">On Sat, Jun 1, 2019 at 5:33 AM Pamela Chestek <<a href="mailto:pamela@chesteklegal.com" target="_blank">pamela@chesteklegal.com</a>> wrote:<br></div><div class="gmail_quote"><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">
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></div></blockquote><div><br></div><div>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 <a href="http://smallcultfollowing.com/babysteps/blog/2019/04/22/aic-collaborative-summary-documents/" target="_blank">collaborative summary document</a> 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.)<br></div><div> </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">
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? </div></blockquote><div><br></div><div>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. <br></div><div><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">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? </div></blockquote><div><br></div><div>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.<br></div><div> </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">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></div></blockquote><div><br></div><div>I thought that was a good first step! One could imagine, after a suitable waiting period, adding a link to that email to <a href="http://opensource.org/rejected-licenses">opensource.org/rejected-licenses</a> so as to memorialize it and make it easy to find later?<br></div><div> </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">
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></div></blockquote><div><br></div><div>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:<br></div><div><ul><li>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)<br></li><li>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)</li><li>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)</li><li>encourage broader non-board participation (these summary documents are a good way to lower the barrier to participation in a variety of ways)</li></ul><div>Hope that helps.</div><div>Luis<br></div></div><div> </div></div></div>