[License-discuss] Coordinated release of security vulnerability information.

[Bruce Perens]

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
https://perens.com/2017/06/28/warning-grsecurity-potential-contributory-infringement-risk-for-customers/
,
their lawsuit against me for these comments is still ongoing and I have
this superscedas bond:
http://perens.com/static/OSS_Spenger_v_Perens/3_17-cv-04002-LB/doc1/pdf/100-1.pdf

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.

    Thanks

    Bruce


On Thu, Aug 22, 2019 at 10:19 AM VanL <van.lindberg at gmail.com> wrote:

>
>
> On Thu, Aug 22, 2019 at 11:35 AM Thorsten Glaser <tg at mirbsd.de> wrote:
>
>>
>> It might address the topic, but I have a really hard time wrapping
>> my head around all the restrictions and terms used.
>>
>
> You mention that it must be necessary for people to get the patch. That is
> this part:
>
> > 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...
>
> 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.
>
> Now, most of the language is about avoiding gaming of the provision:
>
> > a) the modification is intended to address a newly-identified
> vulnerability or a security flaw in the Work,
>
> This must be a *new* security issue. You can't withhold non-sensitive
> patches, and you can't withhold patches for old issues.
>
> > 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,
>
> The security issue must be significant enough to put people at risk. Not
> every patch, nor even every vulnerability, would suffice.
>
> > c) You are participating in a coordinated disclosure of the
> vulnerability or security flaw with one or more additional Licensees, and
>
> 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.
>
> > d) the Source Code pertaining to the modification is provided to all
> Recipients at the end of the Embargo Period.
>
> This doesn't change the requirement to provide source code, it just
> temporarily modifies the timing.
>
> Thanks,
> Van
>
>
>
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>


-- 
Bruce Perens - Partner, OSS.Capital.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190822/fc287948/attachment.html>