<div dir="ltr"><div>Hi all -</div><div><br></div><div>Lots of great discussion here. Responding to a bunch of different messages:</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 15, 2019 at 3:37 PM Bruce Perens <<a href="mailto:bruce@perens.com">bruce@perens.com</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 dir="ltr">On Fri, Mar 15, 2019 at 12:26 PM Ben Hilburn <<a href="mailto:bhilburn@gmail.com" target="_blank">bhilburn@gmail.com</a>> wrote:<br><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 dir="ltr"><div dir="ltr">it's
 important and good to say, "the process is open and anyone can 
contribute," but that doesn't mean that everyone actually feels welcome 
to do so, or that their opinions would be valued.<br></div></div></blockquote><div><br></div><div>So, this is why I 
don't contribute technically to your organization, GNU Radio. I don't 
know as much about signal processing as Michelle Thompson, and would be 
more of a drag than an asset.</div><div><br></div><div>License review is
 really complicated and my views have continued to evolve after 21 years
 of participation. <snip> So, IMO there really is a hump that people have to get 
over to be good contributors, and it is a significant one.</div></div></div></blockquote><div><br></div><div>Thanks, Bruce. To clarify, I didn't mean to imply to that I think *everyone* could meaningfully contribute to L-R. As you point out, in much the same way that the vast majority of the world can't meaningfully contribute to GNU Radio, I don't disagree that the same holds for L-R.</div><div><br></div><div>What I was trying to communicate, rather, is that there are people who *could* make valuable contributions to the discussions on L-R and L-D, but don't feel comfortable doing so because of aspects unrelated to whether or not they have relevant knowledge, thoughts, and opinions to add to the conversation.</div><div><br></div><div>Due in part to what you point out above, actually, GNU Radio tends towards Cathedral. We work *really* hard to make it possible for anyone that can contribute to not only jump in, but feel comfortable and welcomed to do so. It's not an easy problem, and in my experience, really takes a conscious and dedicated effort to do well.<br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 15, 2019 at 5:27 PM Richard Fontana <<a href="mailto:richard.fontana@opensource.org">richard.fontana@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"><snip><br><div>
That might suggest that if there's a loud voices problem, it is not<br>
about undue influence on *OSI*, but undue influence on the license<br>
submitter (i.e., the reaction to the license is so overwhelmingly<br>
negative that the license submitter informally or formally withdraws<br>
from the process). <br></div></blockquote><div><br></div><div>I think this is an important distinction, Richard, and your point about how most licenses that don't get approved are actually pulled from consideration before being rejected by the board is an interesting point.</div><div><br></div><div>The one thing I would add, I think, is that based on what I've seen, if there is a "loud voices" problem, then it's impacting not just the submitter, but the discussion & debate process itself. As you (I think? maybe it was someone else) pointed out in a previous thread, disagreement is a natural and expected part of this process. I submit, though, that L-R's process and rules should protect the submitter and the debate itself from some of the potential negative effects being discussed here.<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>This view implies that the OSI ought to be<br>
approving more licenses than it has been. Yet for a long time the OSI<br>
struggled to accommodate the view that it had erred in the past by too<br>
easily approving too many licenses (most of which were submitted by<br>
business interests, it should be noted), and there is still a<br>
viewpoint out there that the OSI should withdraw entirely from license<br>
approval because we have all the licenses we could possibly need. And<br>
there has also been much criticism of what some pejoratively call<br>
"crayon licenses" (I more charitably call them thought experiments)<br>
which characterize a lot of the license submissions.<br></div></blockquote><div><br></div><div>Hm, I'm not sure I agree, here, that this view implies more licenses should be getting approved. I'm in general agreement that license proliferation is a bad thing, actually, and also think so-called "vanity" and "crayon" licenses should be rejected. One of my principle points, though, is that *especially* for licenses where L-R recommends rejection, our process and debate really needs to be completely trusted.</div><div><br></div><div><div dir="ltr" class="gmail_attr">On Sat, Mar 16, 2019 at 2:28 AM VanL <<a href="mailto:van.lindberg@gmail.com">van.lindberg@gmail.com</a>> wrote:</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 dir="ltr" class="gmail_attr">On Fri, Mar 15, 2019 at 8:54 PM Chris Jerdonek <<a href="mailto:chris.jerdonek@gmail.com">chris.jerdonek@gmail.com</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 dir="ltr"><div dir="ltr"><div dir="ltr">On Fri, Mar 15, 2019 at 4:00 PM John Sullivan <<a href="mailto:johns@fsf.org" target="_blank">johns@fsf.org</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">I think some of this can be done without changing tools. Just as an idea<br>
from someone who can't volunteer the time to help with it, each license<br>
application could be assigned to a caretaker responsible for maintaining<br>
a dossier/brief for the application, listing points raised in<br>
discussion, posted regularly to the list (more regularly than monthly,<br>
and with a tagged subject heading). The dossier becomes a collaborative<br>
document that people in the discussion can be asked to refer<br>
specifically to when making their arguments.</blockquote></div></div></div></blockquote></blockquote><div><br></div><div>I think looking at PEP is a great idea. One of the things I really liked about McCoy's original suggestion about looking at how F/OSS projects handle code merging was the premise that we might benefit from being more like a F/OSS project (sorry, McCoy, I meant to say this in my original response). <br></div><div><br></div><div>For what it's worth, we adapted the PEP process for GNU Radio, and have had great success with it.</div><div><br></div><div>Cheers,</div><div>Ben<br></div></div></div></div></div><div><br></div></div></div></div>