[License-discuss] [License-review] Evolving the License Review process for OSI
luis at lu.is
Sat Jun 1 16:02:27 UTC 2019
On Sat, Jun 1, 2019 at 5:33 AM Pamela Chestek <pamela at chesteklegal.com>
> 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
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
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
- 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the License-discuss