1842
开源代码已经深深扎根在现代软件开发之中，甚至代码拥有者通常都不知道其软件中包含哪些开源组件。如何才能获得对开源组件的可见性和安全控制？执行安全审计是行之有效的途径。
有鉴于此，开源审计的重要性日益凸显。其中，开源许可证冲突问题受到越来越多的关注。新思科技指出， 凭借开源审计，企业可以获得开源和第三方软件的完整、准确的软件物料清单 (SBOM)。这可以为开发人员提供关于许可证、漏洞和各种组件活力的信息分析依据。
新思科技Black Duck审计服务团队分析了对并购交易中涉及的商业和专有代码库的 1,700 多项审计结果，并发布了《2023年开源安全和风险分析》报告（OSSRA）。被审计的代码库中有96%含有开源代码，54%的代码库包含许可证冲突。
新思科技中国区软件应用安全技术总监付红勋指出：“除了建立全面的SBOM之外，Black Duck审计服务团队还负责识别许可证并确定组件的优先级，以进行法律审查。法律审查不用投入太多时间在常见的标准宽松开源许可证上，许可证冲突则需要优先审查。然而，许可证冲突并不是唯一需要法律审查的项目，企业还需要研究开源许可证及变体版本的细则。”
自定义开源许可证及变体版本
在新思科技审计的大约30%的代码库（以及70%的并购交易）中，发现代码具有一次性许可证、标准许可证的自定义变体或根本没有许可证。在本可以识别组件的来源——存储库或网站——但在该位置或代码中却找不到任何许可或使用条款时，这些组件将被标记为“未经许可”。
标准许可证的变体可能会很棘手，因为可能被认为是MIT或BSD许可证等。但仔细检查后，通常会发现开发人员自作主张，在标准中加入了自己的想法。
JSON 许可证
最常见的变体是JSON许可证，即MIT许可证添加上“该款软件严禁用于恶意用途，仅限用于善意用途”的注释。由于此类条款含糊不清，Apache软件基金会暂停使用JSON许可的代码。
JSON许可证甚至还有变体。在此变体中，许可证中添加了以下注释：“如果有人以书面形式通知您没有遵守行为规范，您需要在30天内采取相应行动以继续使用该许可证；否则您的许可证将被立即终止。”
Commons Clause许可证变体
Commons Clause 是一种变体，旨在修改标准开源许可证以限制软件的商业用途。摘录内容如下：“……许可证并未授予您销售软件的权利。”乍看之下，在 Apache 许可证等许可范围内的软件可能会因本条款而变得完全无法使用。
专有和商业许可证
代码库包含来自第三方商业软件公司的内容并不罕见。开源审计经常发现来自Adobe、Microsoft、Oracle和其他公司的版权。作为软件尽职调查的一部分，收购方有必要检查是否有适当的许可证并已披露。即使许可是正当的，律师仍将希望确保控制权的变更不会在未来引入任何风险。
双重许可
越来越多的公司正在使用双重许可，这是一种巧妙的商业模式。根据开源许可证向开发人员提供软件，但同时该许可证包含使其难以用于商业目的的义务。
AGPL 许可证经常出现在这种情况下：大多数公司不能在其产品中使用 AGPL 许可的代码 （还有其它许可证更明确地禁止没有商业许可证的商业使用）。如果开发人员使用根据 AGPL 许可的代码，公司需要与供应商就相同的代码签订商业许可证。
当开源审计发现双重许可软件时，工作人员会突出显示这点，以便收购方可以确保目标公司已获得适当许可。
了解代码中的内容
要全面了解代码是否已获得适当许可，需要准确且完整的材料清单，以及分析预期用途与所包含的开源许可之间可能存在的冲突。还有其它超出标准开源的许可问题，需要更深入的研究和更多的法律审查。重要的是，作为软件尽职调查的一部分，开源审计可以追踪到许可证信息，以方便专业的知识产权律师评估其客户特定情况下的风险。
