Security, CVEs, negligence, lawsuits and the ALv2 section 8

[Sean Owen <sr...@apache.org>]

legal-discuss,

An interesting question came up on the Spark PMC list. When is the threat
of a lawsuit against the ASF or a contributor for a security flaw a real
risk?

This arose in the context of deciding whether or not to treat a change as a
vulnerability requiring a CVE. (NB: It will be handled as a CVE.) It was
suggested the issue would cause a private company to worry about a lawsuit,
but then, was suggested that the Apache License 2.0 protects the
ASF/contributors from lawsuits -- so the decision shouldn't be affected by
that particular consideration. We had a board member then send a
strongly-worded message that it's quite wrong to think a lawsuit isn't a
risk.


The Apache License 2.0 text includes:

8. Limitation of Liability. In no event and under no legal theory, whether
in tort (including negligence), contract, or otherwise, unless required by
applicable law (such as deliberate and grossly negligent acts) or agreed to
in writing, shall any Contributor be liable to You for damages, including
any direct, indirect, special, incidental, or consequential damages of any
character arising as a result of this License or out of the use or
inability to use the Work (including but not limited to damages for loss of
goodwill, work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor has been
advised of the possibility of such damages.


Nothing stops anyone from initiating a lawsuit for anything they like; I
think the question is what may constitute a real colorable claim that PMCs
should worry about.

The liability disclaimer can't disclaim gross negligence. Would a PMC that
evaluated a security risk but decided to not act, or not issue a CVE,
possibly be found grossly negligent? I had understood gross negligence to
require a willful disregard for common care, and the scenario doesn't seem
to pass that test.

Could this same situation constitute negligence, etc.? If so, does Section
8 above not effectively disclaim liability for negligence and sink any such
lawsuit, or is it thought to be effective in practice?

Are the answers above different from individual contributors vs. the ASF
itself?


Obviously, nobody thinks it's OK to make mistakes, to take security issues
anything other than seriously. The spectre of lawsuits that was raised
abruptly here caused me to request clarification.

Re: Security, CVEs, negligence, lawsuits and the ALv2 section 8

[Mark Thomas <ma...@apache.org>]

On 09/08/18 04:36, Sean R. Owen wrote:
> There are more details on the Spark PMC list, though I think the general question suffices to start. If good-faith handling of CVEs isn't negligence in general, it isn't negligence in this particular case.
> 
> Totally agree, we should do our best to make good secure software and not be motivated by threats of lawsuits. The claim was that there isn't such a threat if following ASF processes. We had a board member that disagreed strongly. I'm following up to figure out where that comes from.
There is huge difference between "might get sued" and "is likely to lose
a lawsuit".

Generally, as long as projects follow [1] I'm not overly concerned about
the level of risk.

To add to the complexity in this particular area, there are also wildly
different opinions on what is and is not a security threat.

Some of this is pure stupidity. I've lost count of the number of reports
the security team has received that the ASF has a critical vulnerability
because our e-mail and/or source code and/or issue tracker is publicly
accessible. Clearly such reports are nonsense.

Some reports are clear vulnerabilities. e.g. Remote Code Execution
caused by Java code deserializing objects from untrusted data.

Others are genuinely debatable. Is a system exposing version information
a security risk. Personally, I'd argue not. Others disagree.

Projects do need to be careful around the debatable issues. I have
noticed, both in myself and in other projects, a tendency to try and
argue against things being CVEs as that somehow reflects badly on the
project. Projects need to aware of this and try and assess each report
as objectively as possible. Even if something isn't a CVE, there might
well be a hardening opportunity.

Mark



[1] http://www.apache.org/security/committers.html
[2] https://wiki.apache.org/tomcat/FAQ/Password

> 
> On 2018/08/07 06:39:29, Hen <ba...@apache.org> wrote: 
>> That's a very broad/hypothetical set of questions. Not really the sort of
>> questions that I imagine can receive much legal advice outside of a
>> classroom. Maybe one of the lawyers on the list will offer up thoughts, but
>> I assume it's the kind of question that makes a lawyer immediately want
>> specifics and not generalities. (I'm a non-lawyer though, what do I
>> know...).
>>
>> I also don't think it (liability disclaimers, comparisons to private
>> companies) is a question that needs focus. Our mission is to develop
>> software for the public good. We should focus on that mission when making a
>> decision.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

Re: Security, CVEs, negligence, lawsuits and the ALv2 section 8

["Sean R. Owen" <sr...@apache.org>]

There are more details on the Spark PMC list, though I think the general question suffices to start. If good-faith handling of CVEs isn't negligence in general, it isn't negligence in this particular case.

Totally agree, we should do our best to make good secure software and not be motivated by threats of lawsuits. The claim was that there isn't such a threat if following ASF processes. We had a board member that disagreed strongly. I'm following up to figure out where that comes from.

On 2018/08/07 06:39:29, Hen <ba...@apache.org> wrote: 
> That's a very broad/hypothetical set of questions. Not really the sort of
> questions that I imagine can receive much legal advice outside of a
> classroom. Maybe one of the lawyers on the list will offer up thoughts, but
> I assume it's the kind of question that makes a lawyer immediately want
> specifics and not generalities. (I'm a non-lawyer though, what do I
> know...).
> 
> I also don't think it (liability disclaimers, comparisons to private
> companies) is a question that needs focus. Our mission is to develop
> software for the public good. We should focus on that mission when making a
> decision.


---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

Re: Security, CVEs, negligence, lawsuits and the ALv2 section 8

[Hen <ba...@apache.org>]

That's a very broad/hypothetical set of questions. Not really the sort of
questions that I imagine can receive much legal advice outside of a
classroom. Maybe one of the lawyers on the list will offer up thoughts, but
I assume it's the kind of question that makes a lawyer immediately want
specifics and not generalities. (I'm a non-lawyer though, what do I
know...).

I also don't think it (liability disclaimers, comparisons to private
companies) is a question that needs focus. Our mission is to develop
software for the public good. We should focus on that mission when making a
decision.

Hen

On Mon, Aug 6, 2018 at 3:21 PM, Sean Owen <sr...@apache.org> wrote:

> legal-discuss,
>
> An interesting question came up on the Spark PMC list. When is the threat
> of a lawsuit against the ASF or a contributor for a security flaw a real
> risk?
>
> This arose in the context of deciding whether or not to treat a change as
> a vulnerability requiring a CVE. (NB: It will be handled as a CVE.) It was
> suggested the issue would cause a private company to worry about a lawsuit,
> but then, was suggested that the Apache License 2.0 protects the
> ASF/contributors from lawsuits -- so the decision shouldn't be affected by
> that particular consideration. We had a board member then send a
> strongly-worded message that it's quite wrong to think a lawsuit isn't a
> risk.
>
>
> The Apache License 2.0 text includes:
>
> 8. Limitation of Liability. In no event and under no legal theory, whether
> in tort (including negligence), contract, or otherwise, unless required by
> applicable law (such as deliberate and grossly negligent acts) or agreed to
> in writing, shall any Contributor be liable to You for damages, including
> any direct, indirect, special, incidental, or consequential damages of any
> character arising as a result of this License or out of the use or
> inability to use the Work (including but not limited to damages for loss of
> goodwill, work stoppage, computer failure or malfunction, or any and all
> other commercial damages or losses), even if such Contributor has been
> advised of the possibility of such damages.
>
>
> Nothing stops anyone from initiating a lawsuit for anything they like; I
> think the question is what may constitute a real colorable claim that PMCs
> should worry about.
>
> The liability disclaimer can't disclaim gross negligence. Would a PMC that
> evaluated a security risk but decided to not act, or not issue a CVE,
> possibly be found grossly negligent? I had understood gross negligence to
> require a willful disregard for common care, and the scenario doesn't seem
> to pass that test.
>
> Could this same situation constitute negligence, etc.? If so, does Section
> 8 above not effectively disclaim liability for negligence and sink any such
> lawsuit, or is it thought to be effective in practice?
>
> Are the answers above different from individual contributors vs. the ASF
> itself?
>
>
> Obviously, nobody thinks it's OK to make mistakes, to take security issues
> anything other than seriously. The spectre of lawsuits that was raised
> abruptly here caused me to request clarification.
>
>