<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 22, 2019 at 11:35 AM Thorsten Glaser <<a href="mailto:tg@mirbsd.de">tg@mirbsd.de</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"><br>
It might address the topic, but I have a really hard time wrapping<br>
my head around all the restrictions and terms used.<br></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">You mention that it must be necessary for people to get the patch. That is this part:<br></div><div class="gmail_quote"><br>> You may delay providing the Source Code corresponding to a particular modification to the Work for up to ninety (90) days (the “Embargo Period”) if...<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">This is permissive. It does not *prevent* people from sharing the patch, it just adjusts the timing. So there would be no problem with providing the patch to a user, nor that user putting the patch into production during the embargo period.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Now, most of the language is about avoiding gaming of the provision:<br></div><div class="gmail_quote"><br>> a) the modification is intended to address a newly-identified vulnerability or a security flaw in the Work, <br></div><div class="gmail_quote"><br></div><div class="gmail_quote">This must be a *new* security issue. You can't withhold non-sensitive patches, and you can't withhold patches for old issues.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">> b) disclosure of the vulnerability or security flaw before the end of the Embargo Period would put the data, identity, or autonomy of one or more Recipients of the Work at significant risk,</div><div class="gmail_quote"><br></div><div class="gmail_quote">The security issue must be significant enough to put people at risk. Not every patch, nor even every vulnerability, would suffice.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"> > c) You are participating in a coordinated disclosure of the vulnerability or security flaw with one or more additional Licensees, and <br></div><div class="gmail_quote"><br></div><div class="gmail_quote">The focus of this is allowing coordination of operator-users. It doesn't allow unilateral withholding of the source by a single operator-user. If there is only one operator user, they can just roll out the fix! No need to coordinate.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">> d) the Source Code pertaining to the modification is provided to all Recipients at the end of the Embargo Period.</div><div class="gmail_quote"><br></div><div class="gmail_quote">This doesn't change the requirement to provide source code, it just temporarily modifies the timing.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Thanks,<br></div><div class="gmail_quote">Van<br></div><div class="gmail_quote"><br><br> </div></div>