On Tue, Jan 4, 2022 at 11:07 AM Joe Brockmeier <[email protected]> wrote: > > Hi all, > > Taking a look at this now. (Meant to yesterday but the weather and > Duke Energy had different plans for me.) > > I'm wondering if some of these stats are going to have the opposite > effect than intended. > > What's the story we want to tell and what do we want to have come out > of this meeting / what outcomes are we trying to prevent?
Let me set the context. We've been invited to a meeting, by Anne Neuberger[1] a person with a title of "Deputy National Security Advisor, Cyber & Emerging Tech at National Security Council, The White House". According to Bloomberg, the same person made the following statements: * She stated the White House will meet with expertise corporations quickly to deal with issues with open-source software. * the affected software is broadly used however is nonetheless “hard for us to know at the first moment where that code is”. * described open-source software as “a witch’s brew” that’s “built by volunteers, broadly used, and not managed”. We don't know much more than that. But the combination of White House, deal with, not knowing, not managed is, to put it mildly, concerning. To be clear: the problem is real, and needs to be addressed. We need to do our best to ensure that solutions proposed actually address the problem, or at a minimum don't make things worse. And we need to be prepared for whatever impact those solutions may have on other aspects of how we operate. > We're emphasizing our independence and size with these stats which may > be seen as impressive in many contexts but might be seen differently > by folks who (and this is the assumption) aren't familiar with open > source development or the ASF. 227m lines of code and 630K > contributors may be seen as a mountain of problems rather than an > impressive achievement. > > I'd also reverse the order - let's start with security handling + so > forth and close with "About the ASF" for folks who are interested. > > (I snipped a sentence about "without the end user being aware" because > it may be seen as alarming, but also it contradicts the section later > that notes that distributors are required to notify end users due to > section 4a of the Apache License.) More context. We had a vulnerability in log4j. We can tell with precision when the vulnerability was introduced and which releases of our code are affected. We have no way of knowing what commercial and open source products incorporate log4j. We have no way of knowing what downstream users may be using those products, and which versions of our software they may have been provided with. Yes, our license requires our license to be communicated to end users, but that's not enough information to determine who is affected. Things we need to communicate: * Yes, contributions are voluntary, but contributions in general, and contributions to log4j in specific, are made and vetted by seasoned professionals. * Yes, we manage our software, and do so transparently in a way that can readily be audited, but only to the point of release. - Sam Ruby [1] https://www.linkedin.com/in/anne-neuberger-13b4491b [2] https://mywinet.com/some-federal-systems-affected-by-software-flaw-us-official-says/ --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
