<div dir="ltr">As a software author, and in order to best support my community, I should see security information about my own software as soon as possible. Thus, it has always been disquieting that Red Hat has an Enterprise product, the main differentiating feature of which is that they have a customer-only walled garden around security and bug fix information. We rely on their good will for these fixes to eventually reach the actual Open Source project. I have also commented on the GRSecurity product and its license strategy at <a href="https://perens.com/2017/06/28/warning-grsecurity-potential-contributory-infringement-risk-for-customers/">https://perens.com/2017/06/28/warning-grsecurity-potential-contributory-infringement-risk-for-customers/</a> , their lawsuit against me for these comments is still ongoing and I have this superscedas bond:
<a href="http://perens.com/static/OSS_Spenger_v_Perens/3_17-cv-04002-LB/doc1/pdf/100-1.pdf">http://perens.com/static/OSS_Spenger_v_Perens/3_17-cv-04002-LB/doc1/pdf/100-1.pdf</a><div><br></div><div>So, I am not so inclined to value the Insurgent test, or whatever it's called. It's fantastical in nature since such insurgents would not be restrained by copyright considerations, but by much more severe national law including consequences such as execution or imprisonment in the gulag. </div><div><br></div><div> Thanks</div><div><br></div><div> Bruce<br><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 22, 2019 at 10:19 AM VanL <<a href="mailto:van.lindberg@gmail.com">van.lindberg@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"><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" target="_blank">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>
_______________________________________________<br>
License-discuss mailing list<br>
<a href="mailto:License-discuss@lists.opensource.org" target="_blank">License-discuss@lists.opensource.org</a><br>
<a href="http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org" rel="noreferrer" target="_blank">http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Bruce Perens - Partner, <a href="http://OSS.Capital" target="_blank">OSS.Capital</a>.</div></div></div></div>