Today I received this response from Zoom Video Communications, Inc., regarding
my inquiry about ascertaining the (F/LOSS) contents of the zoom binary packages
and programs there-in, after discovering their existing solution was not
working.
I am writing with the hope that this message reaches interested parties, who
are more suited to addressing the situation and seeing things resolved, and
those that wish to comment and provide insight. I am in a position where I
must concern about this routinely, and am only really suited to working to
better that routine, rather than supporting the license of the relevant free
software codes, though I would like to.
I am happy to share the entire conversation, but this last message is what
caught my attention. Find it in-lined here, attached to this mail, and also
via https://desmas.net/zoom-oss.txt
> Hi Nathan,
>
> I am coming back to you regarding your request about the open source software
> source code page, that were containing invalid links.
> All links in the page should now be working correctly
> (https://explore.zoom.us/en/opensource/source/).
>
> Regarding your comment, please find the following explanations that I have
> received from our Dev team:
>
> "We provide our OSS attribution in this manner intentionally, which is to
> say, it’s legally permissible (as per OSS licensing requirements) and more
> secure to be vague about the OSS contents of a given Zoom client/version… if
> a critical CVE is discovered at some point after we release, it’s best not to
> publish which specific Zoom client version contains the vulnerability, as
> that essentially gives a roadmap to exploitation for hackers. That said, we
> can provide more specific lists by request, but do not publish them by
> default.
>
> Also, I’m happy to talk to any customers with specific needs… a quick review
> of our policies/processes might alleviate the need to provide one-off lists.
> And the reality is that most of our clients are comprised of a number of
> shared projects, so most share a common core of OSS libraries, which is to
> say, most of our client OSS reports will look pretty similar except for a few
> environment-specific entries."
>
> I hope the above answers your query. Please let me know if you have any
> questions.
>
> Best regards,
>
> Arnaud
Some specific thoughts in question form:
- Is the stated legal assertion accurate?
- Does an open-ended request suffice; may one simply request: I wish for this
information about "all versions ever released", or perhaps specifying explicit
version ranges matching the existing patterns?
- Must references be made (more) concretely, and if so ... how?
Thank you.
Hi Nathan,
I am coming back to you regarding your request about the open source software
source code page, that were containing invalid links.
All links in the page should now be working correctly
(https://explore.zoom.us/en/opensource/source/).
Regarding your comment, please find the following explanations that I have
received from our Dev team:
"We provide our OSS attribution in this manner intentionally, which is to say,
itâs legally permissible (as per OSS licensing requirements) and more secure
to be vague about the OSS contents of a given Zoom client/version⦠if a
critical CVE is discovered at some point after we release, itâs best not to
publish which specific Zoom client version contains the vulnerability, as that
essentially gives a roadmap to exploitation for hackers. That said, we can
provide more specific lists by request, but do not publish them by default.
Also, Iâm happy to talk to any customers with specific needs⦠a quick
review of our policies/processes might alleviate the need to provide one-off
lists. And the reality is that most of our clients are comprised of a number of
shared projects, so most share a common core of OSS libraries, which is to say,
most of our client OSS reports will look pretty similar except for a few
environment-specific entries."
I hope the above answers your query. Please let me know if you have any
questions.
Best regards,
Arnaud
