漏洞并不是开源软件使用带来的唯一风险。 了解如何最好地降低许可风险，以确保您的团队在使用开源代码进行构建时满足所有法律要求。
随着数字化转型的加速，开源代码组件的使用正在爆炸式增长，这要归功于它们为应用程序开发团队提供的速度、灵活性、可扩展性和质量。但是，牺牲是扩大了攻击面，并带来了新的风险，例如增加了法律和知识产权风险。
开源软件天生就受知识产权保护，特别是版权法。一旦开发人员在其应用程序构建中使用开源软件，他们的组织就有义务满足相关许可中指定的任何条款或条件。这就是为什么许多在云迁移中走得更远的组织在保留人员或员工上拥有特定的开源法律资源。
那么为什么没有更多的企业密切关注他们的应用程序开发团队对开源组件的使用和风险缓解呢？让我们看一些场景。
我确信我的组织的开发团队没有广泛使用开源代码，开源许可证有什么大不了的？
嗯，简单地说，如果一个组织在没有满足许可证要求的情况下发布包含开源软件的应用程序，那么他们就是侵犯知识产权，需要承担法律责任。根据 Snyk 的说法，现在至少 80% 的给定应用程序是开源的。组织需要更加了解任何影子开源的使用。不仅版权所有者可以起诉该组织侵权，还有非营利组织，例如监控开源软件使用情况的软件自由保护协会，一旦发生侵权行为，就会提起诉讼。这些诉讼不仅会造成金钱损失，还会造成客户和公共关系的噩梦！
开源许可证只需要一个脚注确认，对吗？
了解您正在处理的内容非常重要，这样您的组织才能遵循最佳行为。有两种主要类型的开源许可证。许可许可遵循基本的版权概念，主要只需要归属于原始开发者，其他不多。而 Copyleft 许可（意为与版权相反）则回归到传统的软件自由概念，并将其构建到许可要求中以促进代码共享。
许可许可证由于其简单性和易用性而对两个业务更友好。因此，它们代表了大多数开源许可证也就不足为奇了，在 2020 年占 76%。常用的许可许可证是 MIT 许可证，通常因其简短而简单的性质而被选中。该许可证授予用户重新使用软件的完全权限，唯一的要求是在分发软件时必须包含许可证文本和版权声明。
Copyleft 许可证，通常是通用公共许可证 (GPL) 的版本，在商业软件应用程序代码库中使用时会产生风险，因为它可能会导致整个应用程序的知识产权出现问题。因此，许多组织将其系统中任何 GPL 许可证的相关风险级别预设为高。
最近，由于许多开源许可证的扩散，随着大型企业组织将开源代码作为商业服务发布，拦截开源的货币化，出现了一个新的类别。第三种类型称为可用源，尽管它类似于开源，但在技术上有所不同，因为需要增加限制以防止公司利用它。从本质上讲，它使作者能够出于协作目的公开共享他们的代码，但阻止它被用作商业服务。
当开发人员构建可能存在许可冲突的开源代码时，需要进行风险调查。然后，团队必须决定他们是否可以减轻对应用程序代码的责任，或者是否需要对其进行更改以删除此部分。然而，结果是增加了发布前的时间。出于这个原因，组织的法律团队通常有预先设定的开源许可指南。
没有许可证的开源软件怎么样，是免费的吗？
简而言之，没有。默认情况下，该软件受专有版权保护，未经许可，即使被称为开源，使用也是非法的。在满足条款之前，该许可证提供了在没有侵权风险的情况下使用、复制、分发或修改软件的许可。
定制的开源许可证
开发人员有时会编写自己的许可证或更改标准许可证的条款。尽管通常是出于好意，但它们会增加歧义。那里有一些非常疯狂的许可证，比如 Beerware 许可证，基本上说如果你喜欢这个软件，作为回报，你应该给作者买一杯啤酒，或者以他们的名义喝一杯。另一个是鸡舞许可证，它创建了标准 GPL 要求的替代方案，即通过分享你表演鸡舞的视频来分享你的代码。
另一个改变标准许可的例子是 JavaScript Object Notation 的 JSON 许可，它是一种流行的数据交换组件。它修改了标准的许可 MIT 许可证，增加了一个术语“软件应用于善，而不是恶”。绝对是出于好意，但许多公司选择不批准此许可证，因为“好”和“坏”这两个词被认为是可以解释的。
每家公司都必须自己决定他们的风险承受能力是什么，以及他们将允许什么样的许可证。但通常一个术语越模糊，从法律的角度来看就越令人担忧。因此，这些定制的许可证通常不受欢迎，或者公然禁止在公司开源政策中使用。
开发人员不应该知道他们使用的代码的规律吗？
开发人员不是因为他们的法律专业知识而被雇用的。他们的目标是创新、建设良好、快速建设。
重要的是要记住，开源代码是“免费”的误解由来已久，可以追溯到 1985 年，因此很难克服。最初，它被称为“自由软件”，来自推动理解和修改软件的自由的自由软件运动。
因此，开发人员可能会产生这种误解是可以理解的。他们只是想建造，这是他们所知道的，而不是围绕它的法律要求。此外，随着许多公司加大内部应用程序开发的力度，企业可能没有接受过现场培训或了解开源代码正在被使用。
许可证通常也不是直截了当的。以 JSON 为例——开发人员可能认为这很好，因为他们只是在构建商业软件，而不是恶意软件或任何“用于作恶”的东西，但很快就被驳回了。但是，律师将能够从术语的模糊性中识别风险，并适当地关联许可证的风险概况。为了帮助降低许可风险，许多组织确实让他们的开发人员接受了开源法律培训。
依赖项中的开源许可证悖论
以如今开发人员构建的速度，使用无数的代码资源，似乎几乎不可能跟上管理风险和责任的步伐。更不用说安全团队在开发管道中的低能见度了。伴随使用开源库而增加的困难是缺乏对间接依赖关系的可见性。当开发人员使用一个开源组件时会发生什么，该组件由来自其他开源代码的多个间接依赖项构建而成？这看起来有点像无穷大悖论效应，对吧？因为您不仅对直接依赖项的许可条款负责，而且对用于构建更大的开源组件的开源代码的任何间接依赖项负责。
开源许可会影响软件供应链的完整性
供应链攻击是许多 IT 团队的头等大事，其中一个重要的难题是确保其完整性。合规性是其中的关键部分，因此，Linux 基金会等组织寻求解决方案。 OpenChain 项目是作为软件供应链中开源许可证合规性的有效认证而创建的。它本质上所做的是加强整个链条并确保每个部分都可以信任并符合为获得认证而设定的合规标准。最新的 OpenChain 规范是 ISO/IEC 5230:2020，它“指定了质量开源许可证合规计划的关键要求，以便提供一个基准，在交换由开源软件组成的软件解决方案的组织之间建立信任。”
那么如何才能跟上并减轻法律风险呢？
有些程序具有具有预先填充的风险概况的许可证数据库。法律团队可以设置自动化，因此任何存在许可冲突的开源代码都会被标记出来。这些程序由包含数千个许可证和许可证系列的开源库数据库提供支持。这些程序还有助于跟踪您的组织正在使用的许可证，然后可以创建包含所有这些许可证的报告以包含在应用程序分发中。对开发人员进行开源软件法律培训也是一项重要的缓解措施，因为这有助于减少出现的冲突。
Trend Micro Cloud One – Open Source Security 由包含数千个开源库及其相关许可证的 Snyk 数据库提供支持。该解决方案弥合了开源的两种常见风险——漏洞和许可证——因此您可以从一个控制台控制和减轻所有开源风险。这为安全和运营团队带来了重要价值，以便通过进一步提高对开发人员管道功能代码库的可见性来管理开源软件使用的风险和责任。 Cloud One – 开源安全可帮助安全和法律团队在软件开发生命周期的早期识别风险，从而节省时间和成本高昂的修复程序，一旦应用程序发布并可供客户使用，这些修复程序可能会在以后发现。
原文：https://www.trendmicro.com/en_us/research/21/g/navigating-open-source-l…