cURL开源作者怒怼“白嫖”企业：我不删库跑路，但答疑得付钱！
cURL 作者 Daniel Stenberg 在 1 月 21 日收到了一家美国《财富》500 强企业发来的电子邮件，要求 Stenberg 回答关于 cURL 是否受到 Log4Shell 漏洞影响以及如何处理等问题。随后，他将邮件内容截图发到了推特上，并写道：
如果你是一家价值数十亿美元的公司还关注 Log4j，怎么不直接给那些你从未支付过任何费用的 OSS 作者发邮件，要求他们 24 小时内免费回复你这么多问题？
这件事迅速引发了网友们的关注。
把开源当成供应商
根据公开的邮件内容，这家《财富》500 强企业（暂且称为“NNNN”）将 Daniel 团队当成了产品供应商，并要求其 24 小时内免费提供关于 Log4j 漏洞的解决方案。下面是 NNNN 要求 Stenberg 回答的问题：
- 如果您在应用程序中使用了 Java 日志库，那么正在运行的是哪些 Log4j 版本？
- 贵公司是否发生过任何已确认的安全事件？
- 如果是，哪些应用程序、产品、服务和相关版本会受到影响？
- 哪些 NNNN 产品和服务受到影响？
- NNNN 的非公开或个人信息是否会受到影响？
- 如果是，请立即向 NNNN 提供详细信息。
- 什么时候完成修复？列出每个步骤，包括每个步骤的完成日期。
- NNNN 需要采取什么行动来完成此修复？
cURL（client URL 请求库的简称）是一个命令行接口，用于检索可通过计算机网络访问资源的内容。资源由 URL 指定，并且必须是软件支持的类型。cURL 程序实现了用户界面，基于用 C 语言开发的 libcurl 软件库。
Apache Log4j 日志库被 Java/J2EE 应用开发项目和基于 Java/J2EE 的现成软件解决方案的供应商大量使用。去年 12 月 9 日，Log4j 中被发现了一个漏洞，攻击者通过该漏洞能够进行远程代码执行，具体包括通过受影响的设备或应用程序访问整个网络、运行任何代码、访问受影响设备或应用程序上的所有数据、删除或加密文件等。可以说，cURL 开源代码与 Log4j 漏洞事件毫不相干。
虽然 Stenberg 从未参与过任何 Log4j 的开发工作，也没有任何使用了 Log4j 代码的版权产品，但 Stenberg 还是回复道，“你不是我们的客户，我们也不是你的客户。”并略带调侃地表示，只要双方签了商业合同就很乐意回答所有的问题。
“发邮件”只是例行公事？
“这封电子邮件显示出来的无知和无能程度令人难以置信。”Stenberg 在博文里写道，“很奇怪他们现在才发送关于 Log4j 的查询邮件，这似乎有点晚了。”
“这很可能只是一封发送给数十或数百个其他软件供应商 / 开发人员的模板电子邮件。如果确实来自像我过去工作过的那些大型企业，他们很可能会要求各种 IT 支持和开发团队编制一份企业使用的所有软件 / 工具的列表以及每个软件 / 工具的电子邮件地址。所以，很大可能只是有人按照项目计划中的要求向供应商发送电子邮件以延缓问题，并勾选他们的方框，说明已联系该供应商 / 开发人员。”有网友猜测道。
网友“Jack0r”介绍，其所在公司规定要有一个记载依赖项的 Excel 列表，列表里大多数是开源软件，还有一些封闭源代码和付费产品。开发人员要为每个依赖项设置一个联系人，因此与某软件相关的电子邮件可能会被放入列表中。但这个列表通常非常过时，也没有人专门更新。
“我曾经被要求填写一份 3 页关于 Oracle 数据库的详细资料表，但我们从未使用过 Oracle。有的软件运行在 Postgres 上，有的运行在 MySQL 上，有的运行在 NoSQL 上，但他们说，‘MySQL 是从 Oracle 来的，不是吗?’”网友现身说法。
而当出现严重安全漏洞时，负责 Excel 工作表的人员（非开发人员，也不知道这些依赖项如何使用，甚至不知道它们是什么）必须联系每个依赖项的所有者并向他们提出相同的问题。他们这样做不是为了做有用的事情，只是为了告诉他们的客户“我们正在竭尽全力修复这个漏洞”。大多数情况下，这些甚至要被写进合同中。
Reddit 上也有网友表示，Stenberg 收到的邮件来自对计算机或开源一无所知的律师助理。他只是有一长串的名字要联系，这样就可以为公司建立防御，防止因黑客攻击而被起诉。他甚至不在乎公司是否被黑，也不在乎会不会被起诉，他只关心自己的工作，那就是做好准备，以防万一。
因此，有人庆幸道，这就是为什么开源许可证非常重要的原因。开源许可证保护了作者的权益，同时确保了治理到位是企业的责任。
“只盖房子而不关心地基”
“我认为，这可能是开源金字塔的一个很好例证，上层用户根本不考虑底层设施的维护。只盖房子而不关心地基。”Stenberg 写道。
开源金字塔的最底部是基础组件、操作系统和库，上面所有的东西都是在此基础上建立的。
越往上走，产品更多是面向终端用户，企业能赚更多的钱，同时产品迭代更快、语言要求层次更高，开放源码的份额也不断减少。在最上面，很多东西已经不是开源的了。反之，越往下走，产品使用寿命更长，语言要求不好，但 bug 的影响更大，修复需要的时间更长，因此维护比重构更重要。在最底部，几乎所有的东西都是开源的，每个组件都被无数的用户所依赖。
只要有可能在不为“公共基础设施”付出很多就能赚到很多钱，那么企业就没有什么动力去投资或支付某些东西的维护费用。但足够好的软件组件也会偶尔出现 bug，但只要这些漏洞没有真正威胁到赚钱的人，这种情况就不会改变。
Stenberg 认为，为依赖项的维护付费有助于降低未来在周末早上过早发出警报的风险。底层组件的开发者们的工作就是要让依赖其组件功能的用户相信，如果他们购买支持，就能更加放心，避免任何隐藏的陷阱。
根据 Linux 基金会和学术研究人员对 FOSS（免费和开源软件）贡献者进行的调查，开发者们花在安全问题上时间低于 3%，同时受访者并不希望增加花在安全上的时间。“安全事业是一项令人沮丧的苦差事”“安全是令人难以忍受的无聊程序障碍”。有足够的资金让工程师将时间花在代码维护上，或许可以降低严重故障的发生率。
与此同时，底层开发者与上层使用者之间的矛盾日益加深。1 月 11 日， Apache PLC4X 的创建者 Christofer Dutz 在 GitHub 发文称，由于得不到任何形式的回报，他将停止对 PLC4X 的企业用户提供免费的社区支持。若后续仍无企业愿意站出来资助项目，他将停止对 PLC4X 的维护和任何形式的支持。
有的组件可能被成千上万家公司用于一项很小而重要的任务，有的是与 Apache PLC4x 一样，可能只有一个少数组织形成的自然市场。但目前没有具体办法来衡量使用组件给企业带来的收益，更没有一个通用方案可以用来收集和分配企业对开源项目的捐款。
开源可持续性问题的解决已经迫在眉睫。
