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

[Bruce Perens]

Van,

I don't necessarily object to your disclosure provision. I am commenting on
Debian's reasons for not liking the AGPL.

    Thanks

    Bruce

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

> Hi Bruce,
>
> Thanks for sharing your perspective, and I can sympathize with your desire
> to get security-related information as quickly as possible. But I don't
> really understand your comments about the "Insurgent test" or the other
> items you mentioned. I didn't use that term, so I am not sure what you mean.
>
> I *think* you are saying that you would argue against allowing a delayed
> disclosure on a policy basis, because you would prefer that there be no
> opening for a vendor to delay disclosure to you. Is that right? I would
> like to hear you explain more.
>
> Thanks,
> Van
>
>
> On Thu, Aug 22, 2019 at 12:36 PM Bruce Perens via License-discuss <
> license-discuss at lists.opensource.org> wrote:
>
>> 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.
>> _______________________________________________
>> 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/f68176ab/attachment-0001.html>